|
Yes, it relies on two servers, both of which I run. All connections use the "mailbox server", to exchange short messages, which are used to do the cryptographic negotiation, and then trade instructions like "I want to send you a file, please tell me what IP addresses to try". Then, to send the bulk data, if the two sides can't establish a direct connection, they fall back to the "transit relay helper" server. You only need that one if both sides are behind NAT. The client has addresses for both servers baked in, so everything works out-of-the-box, but you can override either one with CLI args or environment variables. Both sides must use the same mailbox server. But they can use different transit relay helpers, since the helper's address just gets included in the "I want to send you a file" conversation. If I use `--transit-helper tcp:helperA.example.com:1234` and use use `--transit-helper tcp:helperB.example.com:1234`, then we'll both try all of: * my public IP addresses
* your public IP addresses
* helperA (after a short delay)
* helperB (after a short delay) and the first one to negotiate successfully will get used. > since otherwise you just scp or rsync or sftp if you don't have the dual barrier True, but wormhole also means you don't have to set up pubkey ahead of time. |
I would have thought NAT hole punching was a basic requirement for something like this...