Difference between revisions of "Talk:WireGuard"

From ArchWiki
Jump to navigation Jump to search
(Sounds Like an Ad: new section)
(Move `Endpoint with changing IP` to `Tips & Tricks`)
 
(27 intermediate revisions by 8 users not shown)
Line 1: Line 1:
== client/server ==
+
== systemd-networkd-wait-online.service needed? ==
  
I'm not sure that we should named both peers as "client" "server" as the documentation will mainly talk about "peer"
+
{{ic|wq-quick@.service}} already contains {{ic|1=After=network-online.target}}. Enabling the wait online service causes the whole boot process to pause while waiting for a network connection and can dramatically increase boot times.
 +
{{Unsigned|03:54, 3 May 2018‎ (UTC)|Smasher816}}
  
[[User:Bobsaintcool|Bobsaintcool]] ([[User talk:Bobsaintcool|talk]]) 17:36, 29 December 2017 (UTC) bobsaintcool
+
: I suspect the long network wait times might be caused by a lack of entropy rather than the target unit.  Recommend [[rng-tools]] or [[haveged]]. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 12:09, 17 November 2018 (UTC)
  
:That sounds sane. It was mostly what made sense to me when learning wireguard.
+
:: [[systemd-networkd]] has a timeout of 2 minutes for {{ic|systemd-networkd-wait-online}}. See this GitHub issue: https://github.com/systemd/systemd/issues/6441 (especially [https://github.com/systemd/systemd/issues/6441#issuecomment-418592758 this comment]). I've had to explicitly tell [[systemd-networkd]] to ignore all links on one of my systems (with {{ic|1=RequireForOnline=no}}), because it seems to wait for ''all'' devices to be online, not ''one'' of them. [[User:Aude|Aude]] ([[User talk:Aude|talk]]) 17:40, 17 November 2018 (UTC)
:[[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 18:23, 29 December 2017 (UTC)
 
  
::I've done some modication in that way
+
::: Just a guess based on some delays with a headless box.  For some other use cases (wpa_supplicant on a raspberry pi), I needed to use an override as well. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:33, 17 November 2018 (UTC).
::[[User:Bobsaintcool|Bobsaintcool]] ([[User talk:Bobsaintcool|talk]]) 19:34, 29 December 2017 (UTC)bobsaintcool
+
{{hc|/etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf|2=
 +
[Service]
 +
ExecStart=
 +
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --ignore eth0
 +
}}
  
== Suggest adding advice about IP forwarding ==
+
:::: Yeah, that makes sense. I did an error and made the reply to your comment [[User:Graysky|Graysky]], but it was supposed to be a reply to the original poster. Sorry for the confusion. [[User:Aude|Aude]] ([[User talk:Aude|talk]]) 22:05, 17 November 2018 (UTC)
  
When I set up wireguard it took me a little time to realize I had to enable IP forwarding in the kernel. Once I knew, all I had to do was:
+
== DNS troubleshoot ==
# sysctl net.ipv4.ip_forward=1
 
So I think that would be good to add to the troubleshooting section or the tips and tricks section. The iptables forwarding rules suggested here won't work with that turned off.
 
  
[[User:Buffalo|Buffalo]] ([[User talk:Buffalo|talk]]) 23:28, 3 February 2018 (UTC)
+
Until a proper NM plugin is released, weird interactions are going to occur between Wireguard and NM. Typically, if you create a tunnel and NM touches DNS for whatever reason (lease timeout, reconnection, etc.) I loose my connection.
  
== Sounds Like an Ad ==
+
I specifically focused on {{ic|systemd-resolved}} because I find the approach much saner than the resolvconf mess. It is also supported by NM and not really "broadly" documented elsewhere.
 +
{{Unsigned|10:52, 15 September 2018‎ (UTC)|Gdonval}}
  
Being a blurb from the project's authors is no excuse.  The following, unsubstantiated claim sounds like an advertisement:
+
== Move `Endpoint with changing IP` to `Tips & Tricks` ==
  
:... it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.
+
I can't justify it being under `Raw usage` as it's only a problem if you reference the server with a domain. I think it can be moved to the tips and tricks section.
 +
[[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 13:13, 16 December 2018 (UTC)
 +
 
 +
: No objections. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 14:07, 16 December 2018 (UTC)
 +
 
 +
: Hey, thank you for your feedback. When I contributed this section I was unsure where I should put it, but I figured its critical enough to include it under the "Usage" section. Why can't you justify this being under "Usage", I think "server with a domain" is a pretty trivial configuration? systemd-networkd examples aren't exactly "Raw usage" either. Also I have just noted that VPN-Server [https://wiki.archlinux.org/index.php/WireGuard#Client_config Wireguard#Client_config] has exactly the described issue my section covers. Note: I'm happy to move it to "Tips & Tricks", I'm just fairly new to archwiki and I'm trying to get a better understanding of common practices here. -- [[User:Insecuriy|Insecuriy]] ([[User talk:Insecuriy|talk]]) 15:12, 16 December 2018 (UTC)
 +
 
 +
:: The configuration describes a configuration and/or decision choice. Not something that is inherent to the configuration of wireguard. Arguably not even a common problem. If it was a "trivial configuration" the section wouldn't be needed. The systemd and config parts are examples and not explained with a lot of text and thus fits quite nicely within the "Usage" section. "Tips and tricks" also fits better for opinionated solutions or configurations tips.
 +
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 15:19, 16 December 2018 (UTC)
 +
 
 +
::: I think this is a common problem, judging by seeing that "even this page" got it wrong under the "VPN Server Client Confing", maybe its a better fit under "VPN Server"? -- [[User:Insecuriy|Insecuriy]] ([[User talk:Insecuriy|talk]]) 15:26, 16 December 2018 (UTC)
 +
 
 +
:::: It is a possible problem for both sections. Listing it under "VPN Server" would not really illustrate that very well. The usage section should be concise and to the point. Trying to fit every problem into that section would not really work in the long run.
 +
:::: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 15:31, 16 December 2018 (UTC)

Latest revision as of 15:31, 16 December 2018

systemd-networkd-wait-online.service needed?

wq-quick@.service already contains After=network-online.target. Enabling the wait online service causes the whole boot process to pause while waiting for a network connection and can dramatically increase boot times. —This unsigned comment is by Smasher816 (talk) 03:54, 3 May 2018‎ (UTC). Please sign your posts with ~~~~!

I suspect the long network wait times might be caused by a lack of entropy rather than the target unit. Recommend rng-tools or haveged. Graysky (talk) 12:09, 17 November 2018 (UTC)
systemd-networkd has a timeout of 2 minutes for systemd-networkd-wait-online. See this GitHub issue: https://github.com/systemd/systemd/issues/6441 (especially this comment). I've had to explicitly tell systemd-networkd to ignore all links on one of my systems (with RequireForOnline=no), because it seems to wait for all devices to be online, not one of them. Aude (talk) 17:40, 17 November 2018 (UTC)
Just a guess based on some delays with a headless box. For some other use cases (wpa_supplicant on a raspberry pi), I needed to use an override as well. Graysky (talk) 19:33, 17 November 2018 (UTC).
/etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --ignore eth0
Yeah, that makes sense. I did an error and made the reply to your comment Graysky, but it was supposed to be a reply to the original poster. Sorry for the confusion. Aude (talk) 22:05, 17 November 2018 (UTC)

DNS troubleshoot

Until a proper NM plugin is released, weird interactions are going to occur between Wireguard and NM. Typically, if you create a tunnel and NM touches DNS for whatever reason (lease timeout, reconnection, etc.) I loose my connection.

I specifically focused on systemd-resolved because I find the approach much saner than the resolvconf mess. It is also supported by NM and not really "broadly" documented elsewhere. —This unsigned comment is by Gdonval (talk) 10:52, 15 September 2018‎ (UTC). Please sign your posts with ~~~~!

Move `Endpoint with changing IP` to `Tips & Tricks`

I can't justify it being under `Raw usage` as it's only a problem if you reference the server with a domain. I think it can be moved to the tips and tricks section. Foxboron (talk) 13:13, 16 December 2018 (UTC)

No objections. Graysky (talk) 14:07, 16 December 2018 (UTC)
Hey, thank you for your feedback. When I contributed this section I was unsure where I should put it, but I figured its critical enough to include it under the "Usage" section. Why can't you justify this being under "Usage", I think "server with a domain" is a pretty trivial configuration? systemd-networkd examples aren't exactly "Raw usage" either. Also I have just noted that VPN-Server Wireguard#Client_config has exactly the described issue my section covers. Note: I'm happy to move it to "Tips & Tricks", I'm just fairly new to archwiki and I'm trying to get a better understanding of common practices here. -- Insecuriy (talk) 15:12, 16 December 2018 (UTC)
The configuration describes a configuration and/or decision choice. Not something that is inherent to the configuration of wireguard. Arguably not even a common problem. If it was a "trivial configuration" the section wouldn't be needed. The systemd and config parts are examples and not explained with a lot of text and thus fits quite nicely within the "Usage" section. "Tips and tricks" also fits better for opinionated solutions or configurations tips.
Foxboron (talk) 15:19, 16 December 2018 (UTC)
I think this is a common problem, judging by seeing that "even this page" got it wrong under the "VPN Server Client Confing", maybe its a better fit under "VPN Server"? -- Insecuriy (talk) 15:26, 16 December 2018 (UTC)
It is a possible problem for both sections. Listing it under "VPN Server" would not really illustrate that very well. The usage section should be concise and to the point. Trying to fit every problem into that section would not really work in the long run.
Foxboron (talk) 15:31, 16 December 2018 (UTC)