Vlákno názorů k článku
DNS-SD objevování a přímé propojení účastníků za NATem Wireguard tunelem od mprasil - Nejak mi uchadza pointa toho celeho. Namiesto toho...

Nejak mi uchadza pointa toho celeho. Namiesto toho aby pouzili STUN server ako prostrednika, tak pouziju DNS server ako prostrednika s tym ze este musia navyse riesit mechanizmus akym vytvoria (a aktualizuju) ten DNS zaznam? Aku to ma konkretne vyhodu?

Přímo z článku:

As previously pointed out, STUN is not a complete solution. STUN provides a mechanism for an application to understand its external IP:port when behind a NAT, but STUN does not provide a method for signaling this to interested parties. If we were writing an application from the ground up that required NAT traversal capabilities, STUN is a component we should consider. We are not writing Wireguard, it already exists, and its not something we can modify (see goal about leaving its source untouched). So where does that leave us? We can certainly take some concepts from STUN and use them to achieve our goal. We clearly need an external, statically addressed host for discovering UDP holes that we can punch through.

Očividně se touto otázkou autor zabýval.

22. 5. 2020, 21:52 editováno autorem komentáře

Aha, tak to uz chapem. Cize nejde ani tak o to tunelovanie NATu, ako skor o ten discovery mechanizmus. To dava zmysel. Vo vela aplikaciach je ten kontakt uz beztak naviazany, ale je pravda ze sa najdu pripady kedy by bolo super proste zadat "adresu" (domenu?) a ono by to nejak fungovalo. Zaujimava idea.