Tjek din NAT-type med det samme

Dette er den offentlige IPv4-adresse, der blev rapporteret under testen. En router eller internetudbyder kan oversætte en privat adresse, før trafikken når internettet. Derfor kan flere enheder eller abonnenter dele en offentlig adresse.

En adresse alene bekræfter ikke CGNAT eller dobbelt NAT. En VPN kan også ændre den offentlige adresse, som testen ser.

Hvis en port er tilgængelig, er tallet efter kolon i IPv4-resultatet en UDP-port, der blev observeret i denne browsertest. For eksempel viser 203.0.113.10:62000 en adresse og den rapporterede port 62000.

Det er ikke en spilport, en regel for portvideresendelse eller bevis for, at en tjeneste kan nås på adressen. Tilknytninger kan ændre sig mellem tests eller destinationer, især ved symmetrisk NAT.

Dette beskriver den IPv4 UDP-adfærd, der blev observeret på den testede sti. NAT 1 er Full Cone, NAT 2 er begrænset NAT, NAT 3 er portbegrænset NAT, og NAT 4 er symmetrisk NAT. Åbent internet er et separat resultat for en sti, hvor der ikke blev observeret NAT.

Det er NAT Checkers betegnelser for kategorierne i RFC 3489. PlayStation, Xbox og andre platforme bruger deres egne betegnelser og tests. NAT-typen måler ikke downloadhastighed og garanterer ikke, at alle spil kan forbinde til alle andre spillere. Vælg »Sådan klassificerer vi NAT« for at se beslutningslogikken.

Dette er en global IPv6-adresse, som din browser har gjort tilgængelig under IPv6-kontrollen. Adresser, der kun kan bruges lokalt, udelades. IPv6-adressesøgningen kører separat fra IPv4 NAT-testen.

En adresse alene beviser ikke ekstern forbindelse. »IPv6 ikke fundet« betyder, at testen ikke fandt nogen global IPv6-adresse; det viser ikke, at din udbyder eller enhed ikke kan understøtte IPv6.

»Ekstern forbindelse bekræftet« betyder, at vores IPv6-testtjeneste rapporterede en vellykket WebRTC/UDP-forbindelse på denne teststi. Det er ikke tilstrækkeligt blot at finde en IPv6-adresse.

»Kunne ikke bekræfte ekstern forbindelse« betyder, at forbindelsen på denne sti ikke lykkedes. Firewallregler, VPN, browserbegrænsninger eller netværksforhold kan påvirke kontrollen. Almindelig browsing via IPv6 kan stadig fungere, fordi den bruger andre forbindelser og protokoller. En timeout eller tjenestefejl betyder, at kontrollen ikke blev gennemført.

Blokeret er et resultat, som NAT-testserveren returnerer, når denne UDP-teststi ikke kan etableres. Det identificerer ikke den enhed eller indstilling, der forårsagede fejlen.

Timeout betyder, at der ikke kom nogen endelig klassifikation inden for testens tidsramme. En fejl eller besked om, at tjenesten ikke er tilgængelig, betyder, at testen ikke kunne gennemføres. Disse resultater er ikke bekræftede NAT 1–4-klassifikationer. Prøv igen, og kontrollér derefter browserbegrænsninger, VPN og firewallindstillinger, før du antager, at fejlen ligger i routeren eller hos udbyderen.

RFC 3489 skelner mellem NAT-typer ved at sammenligne offentlige IP- og porttilknytninger og undersøge, hvilke svarkilder der kan nå den samme lokale UDP-socket. At ændre svarets kilde og at ændre anmodningens destination tester forskellige former for adfærd.

1. Test I: send en almindelig STUN Binding Request. Svaret indeholder MAPPED-ADDRESS: den offentlige IP-adresse og UDP-port, som serveren observerer. Sammenlign begge med den lokale sockets adresse og port for at afgøre, om der er sket oversættelse.
2. Test II: bed om et svar fra en anden server-IP-adresse og port. Hvis det modtages, kan en ekstern afsender, som klienten ikke har kontaktet, nå tilknytningen.
3. Test I til en alternativ destination: send en almindelig anmodning fra den samme lokale socket til det alternative serverendepunkt i CHANGED-ADDRESS. Sammenlign den nye offentlige IP-adresse og port med den første tilknytning for at opdage destinationsafhængig tilknytning.
4. Test III: bed om et svar fra den oprindelige server-IP-adresse, men fra en anden port. Dette skelner mellem et indgående filter, der kun kræver et match på IP-adressen, og et filter, der kræver både IP-adressen og porten.

Dette er RFC’ens klassifikationskontroller. Vores browsertest indsamler den offentlige tilknytning med STUN og bruger serverassisterede WebRTC-forbindelsestests til at returnere den tilsvarende adfærdskategori.

1. Test I modtager et svar, og den tilknyttede offentlige IP-adresse eller port er forskellig fra det lokale socketendepunkt. Der er derfor NAT.
2. Test II modtager et svar fra en anden server-IP og port, selv om klienten ikke har sendt trafik til svarets kilde.
3. I beslutningstræet i RFC 3489 er dette Full Cone NAT, som vi kalder NAT 1.

Når en UDP-tilknytning findes, kan andre eksterne afsendere nå den uden forudgående kontakt. Det gør typisk direkte forbindelser mellem brugere lettere; det betyder ikke, at alle porte er åbne.

1. Der er NAT, men Test II får intet svar fra den ændrede IP-adresse og port.
2. En ny Test I til den alternative destination returnerer samme offentlige IP-adresse og port som den første anmodning. Tilknytningen ændres ikke med denne destination.
3. Test III modtager et svar fra den oprindelige server-IP på en anden port. Tidligere kontakt med denne IP er tilstrækkelig; kontakt med svarets præcise port er ikke nødvendig.

Dette er Restricted Cone NAT, som vi kalder NAT 2 eller begrænset NAT. Indgående UDP-trafik tillades fra eksterne IP-adresser, som klienten allerede har kontaktet.

1. Der er NAT, og Test II får intet svar fra den ændrede IP-adresse og port.
2. Test I til den alternative destination returnerer samme offentlige IP-adresse og port. Destinationsafhængig tilknytning udelukkes dermed i denne sammenligning.
3. Test III får heller intet svar, når kun serverens kildeport ændres. I RFC-modellen skal indgående trafik matche en IP-adresse og port, som klienten allerede har kontaktet.

Dette er Port-Restricted Cone NAT, som vi kalder NAT 3 eller portbegrænset NAT. Tilknytningen er den samme i sammenligningen, men det indgående filter er strengere end ved NAT 2.

1. Der er NAT, og Test II får intet svar fra den ændrede IP-adresse og port.
2. Gentag Test I fra den samme lokale UDP-socket til det alternative serverendepunkt.
3. Hvis den tilknyttede offentlige IP-adresse eller port afviger fra den første tilknytning, identificerer RFC’ens beslutningstræ symmetrisk NAT, som vi kalder NAT 4.

For eksempel kan én destination se 203.0.113.10:62000 og en anden 203.0.113.10:62001. En portændring er nok; den offentlige IP-adresse behøver ikke også at ændre sig. Et endepunkt fundet via én server kan derfor være uegnet til en anden peer, og nogle apps kan have brug for en relayserver.

Hvis Test I ikke får svar, rapporterer registreringsforløbet i RFC 3489 blokeret UDP. I en browsertest kan en mislykket eller ufuldstændig UDP-sti også påvirkes af browserindstillinger, VPN, firewall, tjenestens tilgængelighed eller pakketab. Det lokaliserer ikke i sig selv årsagen.

Hvis Test I lykkes, og både den tilknyttede IP-adresse og port svarer til det lokale socketendepunkt, observeres der ingen NAT. Hvis Test II så lykkes, identificeres åbent internet. Hvis Test II fejler på denne sti uden NAT, kalder RFC’en det en Symmetric UDP Firewall. Det er filtrering uden adresseoversættelse, ikke symmetrisk NAT, og må ikke forveksles med NAT 4.

Vores resultatbetegnelser har ikke en separat kategori for Symmetric UDP Firewall. En ufuldstændig test eller tjenestefejl er også noget andet end en bekræftet NAT-kategori.

STUN, beskrevet i RFC 8489, lader browseren finde en offentlig adresse og UDP-port, som observeres uden for lokalnetværket. ICE, beskrevet i RFC 8445, bruger forbindelsestests til at etablere en sti mellem endepunkter.

RFC 3489 definerer kategorierne Full Cone, Restricted Cone, Port-Restricted Cone og Symmetric samt de tilknytnings- og svartests, der skelner mellem dem. Vi bruger denne klassifikationslogik med vores browser og testservere. IPv6-adressesøgning og ekstern forbindelse er separate kontroller.

Resultatet beskriver denne browsers testede UDP-sti. VPN, firewall og browserbegrænsninger kan påvirke den. Et faktisk netværk kan kombinere tilknytnings- og filtreringsadfærd, som historiske NAT-betegnelser ikke beskriver fuldt ud.

Testen bekræfter ikke CGNAT eller dobbelt NAT, kontrollerer ikke alle appporte og garanterer ikke konsollens NAT-betegnelse eller alle peer-forbindelser. En offentlig IPv6-adresse er ikke bevis for ekstern UDP-forbindelse.

RFC 3489 påpeger også, at gentagen registrering med samme lokale socket kan genbruge tidligere NAT-bindinger og forvrænge resultatet. En ny registrering bruger et nyt lokalt endepunkt eller venter, til gamle bindinger udløber. Resultaterne beskriver netværket på kontroltidspunktet.