Sådan tester du IPv6 gennem en VPN med din egen ressource

En offentlig IP-kontrolside svarer på ét spørgsmål og som regel ikke det, du stillede. Den fortæller dig den udgangsadresse, siden observerede; den fortæller ikke, om IPv6-ruten gennem tunnelen virker, om værten foretrak IPv6 eller faldt tilbage, eller om en udeladt applikation tog en anden vej. En autoriseret ressource, du kontrollerer, svarer ordentligt på det snævrere spørgsmål, fordi du kan se begge ender. Vejledningen nedenfor handler om at nå en konklusion, du kan forsvare, ikke om at få et grønt resultat.

Trin 1: sig, hvilken IPv6-vej du tester

Sig det i én sætning. En anmodning til tunnelserverens egen IPv6-adresse tester tunnelen; en anmodning til en vært ud over udgangen tester udgangens IPv6-udgang; en anmodning til en privat IPv6-adresse tester en intern rute.

Det er tre forskellige påstande, og én vellykket anmodning kan ikke understøtte dem alle. Vælg den, der betyder noget for beslutningen foran dig, og skriv den ned, før du kører noget. Hvis bekymringen er, om IPv6 lækker rundt om tunnelen, handler spørgsmålet om værtens rutevalg, ikke om udgangens tilgængelighed. Hvis bekymringen er, om den fjerne side kan nå en intern tjeneste, er udgangen irrelevant.

Trin 2: bekræft, at værten vælger den rute

ip -6 route get 2001:db8:1::10 udskriver ruten, kildeadressen og det interface, kernen ville bruge, og det er det faktum, resten af testen afhænger af.

At et interface findes er ikke det samme som, at det vælges. Værter med to stakke har en prioritetstabel, og /etc/gai.conf på Linux kan ændre, hvilken familie der vinder for et navn, der opløses til begge.

Trin 3: brug en legitim destination og et legitimt navn

Hvis du tester HTTPS, brug det værtsnavn, certifikatet blev udstedt til, og hold verifikationen slået til; at skifte til en litteral adresse for at få testen til at bestå slår netop den kontrol fra, der beviser, at du nåede den tilsigtede vært. En diagnostisk tjeneste, du kontrollerer, som svarer på et kendt navn med et gyldigt certifikat, er det reneste mål. Den giver dig også en loglinje på serversiden at korrelere imod, hvilket en tredjepartskontrollør aldrig vil gøre.

Kør anmodningen i en form, der viser den adresse, den brugte: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. -6 tvinger familien, og det er sådan, du skiller IPv6 virker ikke fra IPv6 blev ikke foretrukket.

For en ren tilgængelighedstest, hvor ICMPv6 er tilladt, er ping -6 -c 3 2001:db8:1::10 nok. Den beviser vejen og intet over den.

Trin 4: korrelér begge ender

Når du har adgang til begge ender, kør tcpdump -ni any ip6 and host 2001:db8:1::10 på klienten og det tilsvarende på ressourcen, med tidsstempler, og bekræft, at den samme strøm optræder på begge. Det er det, der gør et plausibelt resultat til bevis: klientens syn alene kan ikke skelne et svar fra ressourcen fra et svar fra noget ind imellem. Hold optagelsen snæver til den ene destination, så outputtet forbliver læsbart, og ingens urelaterede session ender i filen.

Gentag testen efter en genopkobling, hvis bekymringen er, om politik overlever en genstart. Rute- og firewalltilstand anvendt én gang ved forbindelsen kan afvige fra tilstand, der anvendes igen, og forskellen viser sig først ved den anden forbindelse.

Test fejltilfældet separat, hvis du har brug for det. En tunnel, der blokerer IPv6, når den falder, og en, der lækker det, er forskellige design, og kun én af dem kan verificeres med en vellykket anmodning.

Trin 5: skriv ned, hvad testen ikke beviste

Trin fem er at skrive ned, hvad testen ikke beviste, og det er den del, der bliver droppet. En vellykket test mod et privat endepunkt beviser ikke offentlig IPv6-udgang, beviser ikke DNS-adfærd og dækker ikke applikationer, du udelukkede fra tunnelen. Hver af disse kræver sin egen destination og sin egen observation. Et notat, der siger, at IPv6 virker efter én anmodning til én vært, er ikke en konstatering; det er et gæt med et tidsstempel.

Den registrering, der er værd at beholde, er kort: destinationen, navnet, kildeadressen værten valgte, den observerede fjernadresse og tidspunktet. RFC 7359 drøfter, hvordan man tester, at en relevant IPv6-vej faktisk er brugbar, og det er den standard, denne vejledning nærmer sig med enklere værktøjer. Hvis konklusionen kræver en offentlig kontrollør for at være sand, var testen ikke specifik nok.