NAT Traversal

NAT traversal er det sæt af teknikker, der lader to enheder bag separate NAT'er etablere direkte forbindelser. Uden det afhænger peer-to-peer-protokoller fuldstændigt af relæservere, hvilket tilføjer omkostninger og latens. Med den kan to telefoner bag hjemmeroutere tale direkte over internettet i det meste af forbindelsens levetid.

Det grundlæggende problem

NAT (se vores NAT-artikel) oversætter udgående forbindelser fra private IP'er til en delt offentlig IP. Indgående forbindelser uden en eksisterende kortlægning har ingen destination - NAT'en ved ikke, hvilken intern enhed den skal videresende til. To NAT-enheder kan ikke starte forbindelser til hinanden; begge skal være ophavsmanden.

STUN: "hvordan ser min offentlige IP ud?"

STUN (Session Traversal Utilities for NAT), RFC 5389, er en simpel protokol, der lader en enhed opdage sin offentlige IP/port-mapping. Enheden sender en STUN-anmodning til en offentlig STUN-server; serveren svarer med den kildeadresse, den observerede (som er NAT'ens eksterne kortlægning).

STUN-servere er statsløse og gratis at køre. Google driver stun.l.google.com:19302; mange andre findes. Omkostningerne ved at køre en er ubetydelige, fordi protokoludvekslingen er lille.

Det enkleste NAT-gennemløbsmønster

For to enheder A og B bag NAT'er:

1. A-forespørgsler STUN, lærer, at dets offentlige kortlægning er X.PLZ2726B, dens offentlige mapping mapping er Y.
2. A og B udveksler disse adresser via en signaleringskanal (out-of-band, som en websocket gennem appens server).
3. A begynder at sende pakker til Y; B begynder at sende til X.
4. Begge NAT'er ser udgående pakker til den andens adresse, opretter de nødvendige tilknytninger, og fra da af videresendes indgående pakker til disse tilknytninger internt.
5. Den direkte A-til-B-sti fungerer nu. stansning. Det virker, når begge NAT'er er rimeligt tilladelige (fuld-kegle eller begrænset-kegle).

   NAT-typer og deres hulning

   • Fuld-kegle NAT. Den mest tilladelige — enhver ekstern vært kan sende til den tilknyttede IP/port. Hulning fungerer nemt.
   • Restricted-cone NAT. Kun tidligere kontaktede eksterne værter kan sende. Hulning fungerer efter at begge sider har sendt mindst én pakke.
   • Port-restricted-cone NAT. Begrænset af vært OG port. Hulning fungerer stadig, men kræver, at begge sider sender til den nøjagtige port.
   • Symmetrisk NAT. Mest restriktive — den eksterne port er forskellig for hver destination, så kortlægningen, der ses af STUN, forudsiger ikke kortlægningen for direkte peer-trafik. Hulning mislykkes normalt.

   Symmetriske NAT'er er almindelige i NAT-udrulninger i carrier-grade og nogle virksomhedsfirewalls. Peers bag symmetriske NAT'er kan ofte ikke forbinde direkte; de har brug for et relæ.

   TURN: når hulning fejler

   TURN (Traversal ved hjælp af relæer omkring NAT), RFC 5766, er tilbagefaldet. Når direkte forbindelse ikke er mulig, forbinder begge peers til en TURN-server, som videresender trafik mellem dem. TURN-servere ser al medietrafikken - betydeligt flere båndbreddeomkostninger end STUN.

   For videoopkaldstjenester (Zoom, Google Meet) er det en stor driftsudgift at køre TURN-servere. Estimater tyder på, at 15-30 % af opkaldene bruger TURN-relæer på trods af bestræbelser på at maksimere direkte forbindelser.

   ICE: kombinerer alt

   ICE (Interactive Connectivity Establishment), RFC 8445, er rammen, der sammen bruger og STUN forbinder. Processen:

   1. Hver peer samler alle kandidatadresser - lokale grænseflader, STUN-opdagede offentlige kortlægninger, TURN-relæreservationer.
   2. Peer udveksler komplette kandidatlister via signalering.
   3. Per-kombinationer af fjernforbindelser til alle peer-forsøg kandidater.
   4. Den første arbejdskombination bliver den aktive forbindelse. Direkte foretrækkes frem for relæet; lavere latency over højere.
   5. Forbindelsen kan revurderes midt i opkaldet, hvis forholdene ændrer sig.

   WebRTC bruger ICE til peer-to-peer browserforbindelser. Se vores WebRTC artikel. De fleste moderne P2P-protokoller bruger ICE eller noget lignende.

   UDP hulning vs TCP hulning

   UDP hulning er ligetil (og standard for de fleste tilfælde af NAT-gennemgang). TCP-huller er meget sværere, fordi TCP kræver synkroniseret håndtryk; begge sider skal initiere forbindelser til hinanden samtidigt, og NAT'erne skal tillade den resulterende tilstand. Nogle NAT'er understøtter det; mange gør ikke. Det meste af P2P-trafik, der har brug for pålidelig transport, bruger UDP-baserede protokoller (QUIC, tilpassede UDP-over-pålidelighedslag) i stedet for TCP.

   NAT64 og IPv6

   IPv6 behøver ikke NAT – hver enhed har en globalt routbar adresse. Teoretisk set eliminerer IPv6 NAT-traversal. I praksis betyder delvis IPv6-implementering, at nogle endepunkter kun er IPv4 bag NAT, andre er IPv6 tilgængelige direkte, og NAT64/DNS64 oversætter mellem dem. Resultatet er mere komplekse routingbeslutninger, men generelt nemmere direkte forbindelser til IPv6-kompatible slutpunkter.

   Hvad det betyder for brugerne

   Du tænker generelt ikke på NAT-gennemgang – apps håndterer det. De synlige effekter:

   • Videoopkald fungerer fint på hjemmenetværk (normalt direkte eller næsten-direkte)
   • Opkald bag virksomhedens firewalls forringes nogle gange, fordi trafikken går gennem TURN
   • Mobilnetværksopkald har nogle gange problemer, fordi operatøren NAT7XPLZX1XPLZX ofte har problemer, fordi operatøren P2P-matchmaking er mere pålidelig på nogle netværk end andre

   For brugere, der kører deres egne tjenester: Bevægelsen mod IPv6 og den gradvise reduktion i symmetrisk NAT-implementering har gjort NAT-gennemgangen mindre smertefuld i løbet af det sidste årti.