Slik testar du IPv6 gjennom ein VPN med din eigen ressurs

Ei offentleg IP-kontrollside svarar på eitt spørsmål, og vanlegvis ikkje det du stilte. Ho fortel deg utgangsadressa sida observerte; ho fortel ikkje om IPv6-ruta gjennom tunnelen verkar, om verten føretrekte IPv6 eller fall tilbake, eller om ein utelaten applikasjon tok ein annan veg. Ein autorisert ressurs du kontrollerer svarar ordentleg på det snævrare spørsmålet, fordi du ser begge endar. Retteleiinga nedanfor handlar om å kome til ei konklusjon du kan forsvare, ikkje om å få eit grønt resultat.

Trinn 1: sei kva IPv6-veg du testar

Sei det i éi setning. Ein førespurnad til tunnelserveren si eiga IPv6-adresse testar tunnelen; ein førespurnad til ein vert utanfor utgangen testar IPv6-utgangen til utgangen; ein førespurnad til ei privat IPv6-adresse testar ei intern rute.

Det er tre ulike påstandar, og éin vellukka førespurnad kan ikkje støtte alle. Vel den som betyr noko for avgjerda framfor deg, og skriv han ned før du køyrer noko. Om uroa er om IPv6 lek rundt tunnelen, handlar spørsmålet om rutetilvalet til verten, ikkje om tilgjengelegheita til utgangen. Om uroa er om den fjerne sida kan nå ein intern teneste, er utgangen irrelevant.

Trinn 2: stadfest at verten vel den ruta

ip -6 route get 2001:db8:1::10 skriv ut ruta, kjeldeadressa og grensesnittet kjernen ville bruke, og det er faktumet resten av testen er avhengig av.

At eit grensesnitt finst er ikkje det same som at det blir valt. Vertar med to stakkar har ein prioritetstabell, og /etc/gai.conf på Linux kan endre kva familie som vinn for eit namn som blir løyst til båe.

Trinn 3: bruk ein legitim destinasjon og eit legitimt namn

Om du testar HTTPS, bruk vertsnamnet sertifikatet vart utstedt til, og hald verifiseringa på; å byte til ei litteral adresse for å få testen til å gå gjennom slår av nettopp kontrollen som provar at du nådde den tiltenkte verten. Ein diagnostisk teneste du kontrollerer, som svarar på eit kjent namn med eit gyldig sertifikat, er det reinaste målet. Ho gir deg også ei logglinje på serversida å korrelere mot, noko ein tredjepartskontrollør aldri vil gi.

Køyr førespurnaden i ei form som viser adressa han brukte: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. -6 tvingar familien, og det er slik du skil IPv6 verkar ikkje frå IPv6 vart ikkje føretrekt.

For ein rein tilgjengelegheitstest der ICMPv6 er tillate, er ping -6 -c 3 2001:db8:1::10 nok. Han provar vegen og ingenting over han.

Trinn 4: korreler båe endar

Når du har tilgang til båe endar, køyr tcpdump -ni any ip6 and host 2001:db8:1::10 på klienten og det tilsvarande på ressursen, med tidsstempel, og stadfest at den same straumen viser seg på båe. Det er dette som gjer eit plausibelt resultat til prov: klienten sitt syn åleine kan ikkje skilje eit svar frå ressursen frå eit svar frå noko imellom. Hald opptaket smalt til den eine destinasjonen, slik at utdata blir leselege og ingens urelaterte økt hamnar i fila.

Gjenta testen etter ei gjenoppkopling om uroa er om policy overlever ein omstart. Rute- og brannmurstatus brukt éin gong ved tilkopling kan avvike frå status som blir brukt på nytt, og skillnaden viser seg først ved den andre tilkoplinga.

Test feiltilfellet separat om du treng det. Ein tunnel som blokkerer IPv6 når han fell, og ein som lek det, er ulike design, og berre éin av dei kan verifiserast med ein vellukka førespurnad.

Trinn 5: skriv ned kva testen ikkje prova

Trinn fem er å skrive ned kva testen ikkje prova, og det er den delen som blir utelaten. Ein vellukka test mot eit privat endepunkt provar ikkje offentleg IPv6-utgang, provar ikkje DNS-åtferd og dekkjer ikkje applikasjonar du utelukka frå tunnelen. Kvar av desse treng sin eigen destinasjon og si eiga observasjon. Eit notat som seier at IPv6 verkar etter éin førespurnad til éin vert, er ikkje eit funn; det er ei gjetting med tidsstempel.

Oppføringa som er verdt å halde på er kort: destinasjonen, namnet, kjeldeadressa verten valde, den observerte fjernadressa og tidspunktet. RFC 7359 drøftar korleis ein testar at ein relevant IPv6-veg faktisk er brukbar, og det er standarden denne retteleiinga nærmar seg med enklare verktøy. Om konklusjonen treng ein offentleg kontrollør for å vere sann, var testen ikkje spesifikk nok.