20220320 wireguard documentation

[Paraphraser]

Adds -t (allocate pseudo tty) flag to docker exec call to run tcpdump inside the WireGuard container. This speeds up delivery of packet-capture output to the terminal.

Adds a note to the test for checking the router's public port to explain that routers often return misleading information as a security feature, meaning the test will not be definitive.

Signed-off-by: Phill Kelley 34226495+Paraphraser@users.noreply.github.com

[ukkopahis]

I tried merging both this and #537, and the resulting conflict is:

diff --cc docs/Containers/WireGuard.md
index a1f7401,316b486..0000000
--- a/docs/Containers/WireGuard.md
+++ b/docs/Containers/WireGuard.md
@@@ -569,11 -557,7 +557,15 @@@ There will be a short delay. The expect
  * `«public»/udp open|filtered unknown` = router is listening
  * `«public»/udp closed unknown` = router is not listening

++<<<<<<< HEAD
 +Note:
 +
 +* Some routers always return the same answer irrespective of whether the router is or isn't listening to the port being checked. This stops malicious users from working out which ports might be open. This test will not be useful if your router behaves like that. You will have to rely on `tcpdump` telling you whether your router is forwarding traffic to your Raspberry Pi.
 +
 +## The read-only flag
++=======
+ ## <a name="readOnlyFlag"></a>The read-only flag
++>>>>>>> pr-537

  The `:ro` at the end of the following line in WireGuard's service definition means "read only":

I suggest you combine both Wireguard pull requests into one.

E.g. by cherry picking (=copying) the other pr's commit into this pull-request:

git checkout 20220320-wireguard-master
git cherry-pick b4f35cf0617d515a8f181fafc08ffb44ed44a182
# resolve conflict in editor
git add docs/Containers/WireGuard.md
git commit -C b4f35cf0617d515a8f181fafc08ffb44ed44a182
git push

And then closing #537

[Paraphraser]

I keep saying I don't have a deep understanding of Git. Your recommended set of commands is probably "plain English" for native Git-o-philes but it gives me the utter heebies because I don't actually know what it's going to do and I live in fear of breaking something.

My approach was just to do a side-by-side of the two WireGuard.md files to see which merge (A-into-B vs B-into-A) involved the least changes. The answer was changing PR537, which implies closing PR519, which I am about to do.

[ukkopahis]

Conflict resolved, good job.

Just tried to show the "easiest" way, is all. The hours I've spent reading git man pages feel like time well spent, but I know it isn't for everybody.

When merging using git, then both A-to-B and B-to-A will result in the same conflict-set that has to be manually resolved. But in this instance, doing the merge 'manually' wasn't too hard as one of the changes was very small.

To safely try it out git-stuff with zero risk, you can create a throwaway clone:

cd /tmp
git clone https://github.com/Paraphraser/IOTstack.git throwaway
cd throwaway/
# create and checkout a branch for this pull request
git checkout 20220320-wireguard-master
# safely try cherry-pick or whatever else...
git cherry-pick b4f35cf0617d515a8f181fafc08ffb44ed44a182

And when you're done testing, just nuke it:

rm -rf /tmp/throwaway

Might not be useful today, but it's here if you ever need it.