Inleiding
Dit document beschrijft de behoefte aan Session Traversal Utilities voor NAT (STUN) servers, de typen NAT-instellingen (Network Address Translation) met betrekking tot STUN-servers, hoe NAT een probleem bij deze installatie en de oplossing veroorzaakt.
Achtergrondinformatie
Het primaire doel van NAT-apparaten is om apparaten met privaat IP-adressen in een LAN-netwerk (Local Area Network) te laten communiceren met apparaten in openbare adresruimten, zoals het internet. Hoewel NAT-apparaten bedoeld zijn om interne hosts verbinding te laten maken met de openbare ruimte, biedt NAT problemen met het opzetten van die UDP-verbindingen wanneer het gaat om Point-to-Point (P2P)-toepassingen zoals VoIP, gaming, WebRTC en het delen van bestanden, waarbij de eindgebruikers als client en server moeten optreden om 2-voudige end-to-end communicatie te behouden. NAT-traversale technieken zijn doorgaans vereist om deze toepassingen te laten werken.
Behoefte aan NAT-transversale switch
Realtime spraak- en videocommunicatie op het internet zijn vandaag de dag mainstream met verschillende populaire instant messengers (IM's) die VoIP-gesprekken ondersteunen. Een grote hindernis in de eerste toepassing van VoIP was het feit dat de meeste pc's of andere apparaten achter firewalls zitten en privé IP-adressen gebruiken. Meervoudige privé-adressen (IP-adres en poort) in het netwerk worden via een firewall met NAT toegewezen aan één openbaar adres. Maar het eindapparaat is zich niet bewust van zijn openbare adres, en kan daarom geen spraakverkeer van de verre partij op het privé adres ontvangen het in zijn communicatie van VoIP adverteert.
Unilateral Self-Address Fixing (UNSAF) processen zijn processen waarbij een voortkomend eindpunt probeert om het adres (en de poort) te bepalen of vast te leggen waarmee het bekend is bij een ander eindpunt, bijvoorbeeld om adresgegevens te kunnen gebruiken in de protocoluitwisseling of om een openbaar adres te adverteren waarvan het verbindingen ontvangt.
De onderhavige P2P-verbindingen zijn dus UNSAF-processen. Een veel voorkomende manier waarop P2P applicaties peering sessies opzetten en NAT-vriendelijk blijven is wanneer ze een publiekelijk adresseerbare rendez-vous server gebruiken voor registratie en peer discovery doeleinden.
Session Traversal Utilities voor NAT
Zoals per RFC 5389, biedt STUN een tool dat NAT's behandelt. Het voorziet in een middel voor een eindpunt om het IP adres en de haven te bepalen die door een NAT apparaat wordt toegewezen dat aan zijn privé IP adres en haven beantwoordt. Het verstrekt ook een manier voor een eindpunt om een NAT band levend te houden.
Typen NAT-implementaties
Er is vastgesteld dat de NAT-behandeling van UDP van implementatie tot uitvoering verschilt. De vier behandelingen die bij implementaties zijn waargenomen zijn:
Full Cone: Een full cone NAT is een waar alle verzoeken van hetzelfde interne IP adres en poort worden toegewezen aan hetzelfde externe IP adres en poort. Voorts kan om het even welke externe gastheer een pakket naar de interne gastheer verzenden, en het verzendt een pakket naar het in kaart gebrachte externe adres.
Restricted Cone: Een beperkte kegel NAT is een waarin alle verzoeken van hetzelfde interne IP-adres en dezelfde poort worden toegewezen aan hetzelfde externe IP-adres en dezelfde poort. In tegenstelling tot een volledige kegel NAT, kan een externe host (met IP-adres X) een pakket naar de interne host alleen sturen als de interne host eerder een pakket naar IP-adres X had verzonden.
Port Restricted Cone: Een port-limited cone NAT is als een beperkte kegel NAT, maar de beperking omvat poortnummers. Met name kan een externe host een pakket, met het IP-bronadres X en de bronpoort P, alleen naar de interne host sturen als de interne host eerder een pakket naar IP-adres X en poort P had verzonden.
Symmetrisch: Een symmetrische NAT is een NAT waarbij alle verzoeken van hetzelfde interne IP-adres en dezelfde poort naar een specifiek IP-adres en dezelfde poort naar hetzelfde externe IP-adres en dezelfde poort worden toegewezen. Als de zelfde gastheer een pakket met het zelfde bronadres en de haven, maar naar een verschillende bestemming verzendt, wordt een verschillende afbeelding gebruikt. Bovendien kan alleen de externe host die een pakket ontvangt een UDP-pakket terugsturen naar de interne host.
Overweeg een topologie waar de bron (A, Pa) (waar A het IP-adres is, en Pa de bronpoort is) communiceert met de bestemming (B, Pb) en (C, PC) via een NAT-apparaat.
| Type NAT-implementatie |
Publieke bron indien bestemd voor (B, Pb) |
Publieke bron indien bestemd voor (C, PC) |
Kan bestemming (bijvoorbeeld (B, Pb) ) verkeer naar (A, Pa) sturen? |
| Volle steen |
(X1,PX1) |
(X1,PX1) |
Ja |
| Restricted Zone |
(X1,PX1) |
(X1,PX1) |
Alleen als (A, Pa) eerst het verkeer naar B heeft verzonden |
| Poortbeperkt bereik |
(X1,PX1) |
(X1,PX1) |
Alleen als (A, Pa) eerst het verkeer naar (B, Pb) had gestuurd |
| symmetrisch |
(X1,PX1) |
(X2,PX2) |
Alleen als (A, Pa) eerst het verkeer naar (B, Pb) had gestuurd |
Problemen met NAT dwars- en symmetrische NAT
STUN-servers reageren op STUN-bindende verzoeken die door STUN-clients worden verzonden en bieden de openbare IP/poort van de klant. Nu, wordt deze adres/poortcombinatie gebruikt door de STUN-client in zijn peer-to-peer communicatie signalering. Echter, nu de endhost hetzelfde privéadres/poort gebruikt (laten we aannemen dat gebonden is aan de openbare IP/poort die in de STUN-respons wordt verstrekt) vertaalt het NAT-apparaat het naar dezelfde IP maar een andere poort als symmetrische NAT-implementatie wordt gebruikt. Dit doorbreekt de UDP-communicatie omdat de signalering de verbinding tot stand had gebracht op basis van de vorige poort.
De NAT-implementatie van Cisco IOS®routers bij het uitvoeren van PAT is standaard symmetrisch. Daarom wordt er verwacht dat u UDP-verbindingsproblemen ziet met deze routers die NAT uitvoeren.
De NAT-implementatie van de Cisco IOS-XE routers bij het uitvoeren van PAT is echter niet symmetrisch. Wanneer u twee verschillende stromen met dezelfde bron IP en poort maar naar verschillende bestemmingen verstuurt, wordt de bron genatineerd naar hetzelfde binnen globale IP en poort.
De oplossing voor het probleem
Vanuit deze beschrijving is het duidelijk dat het probleem kan worden opgelost als u Endpoint-Independent mapping uitvoert.
Zoals in RCFC 4787: Met Endpoint-Independent Mapping (EIM) hergebruikt de NAT de poorttoewijzing voor verdere pakketten die vanaf hetzelfde interne IP-adres en dezelfde poort (X:x) naar een extern IP-adres en -poort worden verzonden.
Van een client, wanneer de endhost de opdrachten nc -p 23456 10.0.0.4 40000 en nc -p 23456 10.0.0.5 50000, op twee verschillende terminalvensters uitvoert, zijn hier de resultaten van de NAT-vertalingen als u EIM gebruikt:
Pro Inside global Inside local Outside local Outside global
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.4:40000 10.0.0.4:40000
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.5:50000 10.0.0.5:50000
Hier kunt u zien dat verschillende verkeersstromen met hetzelfde bronadres en dezelfde poort worden vertaald naar hetzelfde adres/poort, ongeacht de bestemmingshaven/het adres.
Op Cisco IOS-routers kunt u Endpoint Agnostic Port Allocation inschakelen met de inschakelt-systeempoort van de opdrachtregel IP NAT-service.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/iadnat-fpg-port-alloc.html
Samenvatting
Cisco IOS NAT-implementatie is standaard symmetrisch wanneer u poortadresomzetting (PAT) gebruikt en deze kan problemen opleveren bij het passeren van P2P UDP-verkeer waarvoor servers zoals STUN voor NAT-routing nodig zijn. U moet EIM op het NAT-apparaat expliciet configureren om dit te laten werken.
Feedback