Ett nätverk med bara IPv6 bryter VPN:en innan tunneln startar

Laptopen ansluter till ett konferens-Wi-Fi som bara delar ut IPv6, VPN-klienten snurrar och misslyckas, och samma profil fungerade på ett hotell en timme tidigare. Ingenting i inloggningsuppgifterna har ändrats. Det som har ändrats är att klienten nu måste nå ett IPv4-mål genom ett nätverk som bara bär IPv6, och inte alla klienter vet hur man gör det.

Gå samma fem steg som paketen går.

Steg 1: titta på namnsökningen

Om profilen använder ett värdnamn är den första frågan vad resolvern returnerar. dig AAAA vpn.example.com på nätverket med bara IPv6 returnerar en riktig AAAA-post, en syntetiserad från DNS64 eller ingenting alls. Ett syntetiserat svar kodar IPv4-målet inne i ett översättningsprefix, och först då kan en klient utan IPv6-mål nå det. En profil med en hårdkodad IPv4-adress kommer aldrig så långt, eftersom det inte finns något namn att syntetisera.

Den enda skillnaden förklarar de flesta «fungerar där, misslyckas här»-rapporter, och det krävs ett enda kommando för att se den.

Steg 2: se vilken familj klienten anropade

Titta på socketen i stället för förloppsindikatorn. En klient som öppnar en IPv4-socket mot en IPv4-adress på en länk med bara IPv6 har ingenstans att skicka den, och felet visar sig som en timeout i stället för ett namnfelsfel. ss -tanp medan klienten ansluter visar fjärradressen och den familj den försökte. Jämför det med ip -6 route för att bekräfta att standardvägen är ett riktigt IPv6-nästa hopp.

Adressfamiljen i sockettabellen är faktumet. Förloppsindikatorn är en sammanfattning som någon annan skrev.

Steg 3: skilj översättningen från tunneln

NAT64 och DNS64 är hur åtkomstnätverket når IPv4-mål, och de gör ingenting för tunneln när den väl är uppe. En tunnel som upprättats över en översatt väg förhandlar fortfarande om sin egen interna adressering, och den interna IPv4- eller IPv6-täckningen är en separat policyfråga. Om klienten ansluter och sedan inte når något, har du passerat översättningen och är inne i routingen, vilket är en annan utredning med andra bevis.

Översättning som misslyckas ser ut som att man aldrig ansluter. Intern täckning som misslyckas ser ut som att man ansluter och inte når något.

Steg 4: testa samma profil på ett annat nätverk

Ta med samma profil, klientversion och inloggningsuppgifter till ett dubbelt staplat nätverk och upprepa. Om det fungerar där och misslyckas på vägen med bara IPv6 är variabeln åtkomstnätverket och inte profilen. Anteckna klientversionen och nätverkets tillstånd i ärendet, eftersom den slutliga lösningen är en klientuppdatering eller ett annat mål.

En rapport som säger att VPN:en är trasig går inte att agera på. En rapport som säger att den bara misslyckas vid åtkomst med bara IPv6 är en felrapport.

Steg 5: reparera vägen, inte säkerhetsinställningarna

De frestande reparationerna gör allt värre. Att stänga av IPv6 tar bort den enda väg nätverket erbjuder. Att peka klienten mot en offentlig resolver bryter DNS64-syntesen, eftersom den syntesen måste komma från resolvern bakom översättaren. Att stänga av certifikatverifieringen ger dig en anslutning till något du inte kan identifiera. Ingen av dem är en reparation, och två av dem är säkerhetsregressioner som kommer att överleva incidenten.

De verkliga alternativen är en klient som stöder nätverksöversättningsmodellen, eller ett mål med en nåbar IPv6-adress. Be om ett av dem.