testing: add integration testing that asserts STUN/NAT hole punching is working properly

[backkem]

Investigate ways to simulate and test traversal of different NAT types and combinations of NAT types.

Related:

• NAT Traversal testing libp2p/go-libp2p#111

[enobufs]

If one NAT type is ok, then we can do it using docker containers. The idea is to have multiple layers of dockers (docker-in-docker technique), where outer most docker represents a WAN (we can run STUN/TURN/signaling server there), second layer is to set up an IP masquerade, and innermost container will be the NATted application. As far as I know, Ubuntu's IP masquerade (based on iptables) exhibits "Port-restricted cone NAT". You can emulate more than one virtual "NATted" subnets inside a docker, so we can simulate App-->NAT-->WAN-->NAT-->App. Let me know if this could help.

[backkem]

Eventually it would be nice to test using a variety of NAT types but for now it would already help a lot to automate one test. That would mean we no longer have to manually test NAT traversal.

[enobufs]

I just put my demo code together...
https://github.com/enobufs/nat-traversal-test-using-docker

[Sean-Der]

@enobufs you ok with me closing this as a dupe of your vnet work? I think everything will be covered when that rolls out.

We can simulate all NAT types between peers (and that we get the expected behavior) so I think that covers everything!

[enobufs]

Yes, I'd agree. Let me close this issue.
See: pion/webrtc#712