Reading time: 2 – 3 minutes
El servidor STUN ha de publicar la seva IP (3478TCP/UPD o 5349TLS) a un gateway que tingui una IP interna i una externa (privada i pública). La comuniació comença quan el client que esta a la xarxa enmascarada llença una serie de requests contra la IP pública del servidor STUN. El servidor STUN contestarà al client informant dels parells de ports usats a l’exterior del NAT, amb això el client aprent de quin tipus de NAT disposa i quin és el TTL dels bindings que es fan a l’exterior per re-enviar les seves peticions.
Una aplicació client per tal de saber qui és el seu servidor STUN el que fa és buscar al seu domini DNS la resolució del nom _stun_.domini_exemple.com o _stun._udp.domini_exemple.com pels tipus de registre SRV. Després de saber qui és el seu servidor STUN el que fa l’aplicació és buscar l’adreça pública del servidor STUN. Per tal de descobrir quin haurà de ser l’origen dels seus paquets a internet. Així quan construeixi els paquets amb les dades d’aplicació podrà advertir quina és l’adreça pública del seu servidor STUN.
Arribats a aquest punt sovint en tenim prou com per començar la comunicació amb el destí final del nostre enllaç, ja que aquest l’únic que haurà de fer és contestar els paquets pels mateixos ports que el gateway esta fent binding en aquell moment. Aquí és on el STUN server fa la seva feina mantenint els ports oberts. Un dels problemes amb els que ens podem trobar és que el node destí no pugui atacar aquells ports per alguna restricció del seu firewall o similar. Cosa que complica la possibilitat de fer l’enllaç. Si els dos hosts que volem comunicar estan tots dos darrera del NAT-masquerade la cosa és fa molt difícil i sovint fa falta un proxy entre els dos servidors STUN per tal de que la cosa funcioni, o sigui, que es complica moltíssim.
Diagrama de fluxe del protocol:
3 thoughts on “NAT traversal: Com funciona STUN?”
Oriol he llegit i rellegit el teu post i la info de la wikipedia, hi ha un dubte que no aconsegueixo aclarir : en casos de restricted cone i port restricted cone diuen que només funciona si els dos host inicien les transmisions al mateix moment ? Saps que cony vol dir això, perque jo no veig solució si no es amb full conne !!!
També hauria sgiut bo que en le protocol de stun s’utilitzecin les paruales source i destination !! m’he fet un lio que thi cagues 😉
Em sap greu respondre amb una altre pregunta, però no veig on diu que han de començar les connexions al mateix moment…
Bàsicament perquè l’enllaç funcioni amb restricted cone i port restricted el que cal és usar aquests petits rangs permesos i el que cal és aprofitar el rang de temps que queda quan es fa binding en el NAT per passar els paquets de forma que mai es compleixi el TTL i sempre quedin oberts els ports al NAT. No sé si m’he explicat.
En parlem el dissabte despres del partit de tenis 😉
Comments are closed.