Et nettverk med bare IPv6 bryter VPN-en før tunnelen starter
Et nettverk med bare IPv6 når et IPv4-mål bare via den støttede veien. Sjekk navneoppslaget og socket-familien før du endrer noe.
Laptopen kobler seg til et konferanse-Wi-Fi som bare deler ut IPv6, VPN-klienten spinner og feiler, og samme profil fungerte på et hotell en time tidligere. Ingenting i påloggingsinformasjonen er endret. Det som er endret, er at klienten nå må nå et IPv4-mål gjennom et nettverk som bare bærer IPv6, og ikke alle klienter vet hvordan de skal gjøre det.
Gå de samme fem trinnene som pakkene går.
Trinn 1: se på navneoppslaget
Hvis profilen bruker et vertsnavn, er det første spørsmålet hva resolveren returnerer. dig AAAA vpn.example.com på nettverket med bare IPv6 returnerer en ekte AAAA-post, en syntetisert fra DNS64 eller ingenting i det hele tatt. Et syntetisert svar koder IPv4-målet inne i et oversettelsesprefiks, og først da kan en klient uten IPv6-mål nå det. En profil med en hardkodet IPv4-adresse kommer aldri så langt, fordi det ikke er noe navn å syntetisere.
Den ene forskjellen forklarer de fleste «virker der, feiler her»-rapportene, og det kreves én kommando for å se det.
Trinn 2: se hvilken familie klienten kalte på
Se på socketen i stedet for fremdriftslinjen. En klient som åpner en IPv4-socket til en IPv4-adresse på en lenke med bare IPv6, har ingen steder å sende den, og feilen viser seg som en tidsavbrudd i stedet for en navnefeil. ss -tanp mens klienten kobler til viser fjernadressen og familien den forsøkte. Sammenlign det med ip -6 route for å bekrefte at standardruten er en ekte IPv6-nestehopp.
Adressefamilien i socket-tabellen er faktumet. Fremdriftslinjen er et sammendrag som noen andre har skrevet.
Trinn 3: skill oversettelsen fra tunnelen
NAT64 og DNS64 er måten aksessnettverket når IPv4-mål på, og de gjør ingenting for tunnelen når den først er oppe. En tunnel som er satt opp over en oversatt vei, forhandler fortsatt sin egen interne adressering, og den interne IPv4- eller IPv6-dekningen er et eget policyspørsmål. Hvis klienten kobler til og deretter ikke når noe, er du forbi oversettelsen og inne i rutingen, som er en annen undersøkelse med andre bevis.
Oversettelse som feiler ser ut som at man aldri kobler til. Intern dekning som feiler ser ut som at man kobler til og ikke når noe.
Trinn 4: test den samme profilen på et annet nettverk
Ta med den samme profilen, klientversjonen og påloggingsinformasjonen til et dobbeltstakket nettverk og gjenta. Hvis det virker der og feiler på veien med bare IPv6, er variabelen aksessnettverket og ikke profilen. Noter klientversjonen og nettverkstilstanden i saken, fordi den endelige løsningen er en klientoppdatering eller et annet mål.
En rapport som sier at VPN-en er ødelagt, er ikke handlingsbar. En rapport som sier at den bare feiler på aksess med bare IPv6, er en feilrapport.
Trinn 5: reparer veien, ikke sikkerhetsinnstillingene
De fristende reparasjonene gjør alt verre. Å slå av IPv6 fjerner den eneste veien nettverket tilbyr. Å peke klienten mot en offentlig resolver ødelegger DNS64-syntesen, fordi den syntesen må komme fra resolveren bak oversetteren. Å slå av sertifikatverifisering gir deg en forbindelse til noe du ikke kan identifisere. Ingen av dem er en reparasjon, og to av dem er sikkerhetsregresjoner som vil overleve hendelsen.
De reelle alternativene er en klient som støtter nettverksoversettelsesmodellen, eller et mål med en tilgjengelig IPv6-adresse. Be om ett av dem.