Slik tester du IPv6 gjennom en VPN med din egen ressurs

En offentlig IP-kontrollside svarer på ett spørsmål, og vanligvis ikke det du stilte. Den forteller deg utgangsadressen siden observerte; den forteller ikke om IPv6-ruten gjennom tunnelen virker, om verten foretrakk IPv6 eller falt tilbake, eller om en utelatt applikasjon tok en annen vei. En autorisert ressurs du kontrollerer svarer ordentlig på det snevrere spørsmålet, fordi du ser begge ender. Veiledningen nedenfor handler om å komme til en konklusjon du kan forsvare, ikke om å få et grønt resultat.

Trinn 1: si hvilken IPv6-vei du tester

Si det i én setning. En forespørsel til tunnelserverens egen IPv6-adresse tester tunnelen; en forespørsel til en vert utenfor utgangen tester utgangens IPv6-utgang; en forespørsel til en privat IPv6-adresse tester en intern rute.

Det er tre forskjellige påstander, og én vellykket forespørsel kan ikke understøtte alle. Velg den som betyr noe for beslutningen foran deg, og skriv den ned før du kjører noe. Hvis bekymringen er om IPv6 lekker rundt tunnelen, handler spørsmålet om vertens rutevalg, ikke om utgangens tilgjengelighet. Hvis bekymringen er om den fjerne siden kan nå en intern tjeneste, er utgangen irrelevant.

Trinn 2: bekreft at verten velger den ruten

ip -6 route get 2001:db8:1::10 skriver ut ruten, kildeadressen og grensesnittet kjernen ville brukt, og det er faktumet resten av testen avhenger av.

At et grensesnitt finnes er ikke det samme som at det velges. Verter med to stakker har en prioritetstabell, og /etc/gai.conf på Linux kan endre hvilken familie som vinner for et navn som løses til begge.

Trinn 3: bruk en legitim destinasjon og et legitimt navn

Hvis du tester HTTPS, bruk vertsnavnet sertifikatet ble utstedt til, og hold verifiseringen på; å bytte til en litteral adresse for å få testen til å bestå slår av nettopp kontrollen som beviser at du nådde den tiltenkte verten. En diagnostisk tjeneste du kontrollerer, som svarer på et kjent navn med et gyldig sertifikat, er det reneste målet. Den gir deg også en logglinje på serversiden å korrelere mot, noe en tredjepartskontrollør aldri vil gi.

Kjør forespørselen i en form som viser adressen den brukte: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. -6 tvinger familien, og det er slik du skiller IPv6 virker ikke fra IPv6 ble ikke foretrukket.

For en ren tilgjengelighetstest der ICMPv6 er tillatt, er ping -6 -c 3 2001:db8:1::10 nok. Den beviser veien og ingenting over den.

Trinn 4: korreler begge ender

Når du har tilgang til begge ender, kjør tcpdump -ni any ip6 and host 2001:db8:1::10 på klienten og det tilsvarende på ressursen, med tidsstempler, og bekreft at den samme strømmen vises på begge. Det er dette som gjør et plausibelt resultat til bevis: klientens syn alene kan ikke skille et svar fra ressursen fra et svar fra noe imellom. Hold opptaket snevert til den ene destinasjonen, slik at utdataene forblir lesbare og ingens urelaterte økt havner i filen.

Gjenta testen etter en gjenoppkobling hvis bekymringen er om policy overlever en omstart. Rute- og brannmurstatus brukt én gang ved tilkobling kan avvike fra status som brukes på nytt, og forskjellen viser seg først ved den andre tilkoblingen.

Test feiltilfellet separat hvis du trenger det. En tunnel som blokkerer IPv6 når den faller, og en som lekker det, er forskjellige design, og bare én av dem kan verifiseres med en vellykket forespørsel.

Trinn 5: skriv ned hva testen ikke beviste

Trinn fem er å skrive ned hva testen ikke beviste, og det er den delen som blir utelatt. En vellykket test mot et privat endepunkt beviser ikke offentlig IPv6-utgang, beviser ikke DNS-atferd og dekker ikke applikasjoner du utelukket fra tunnelen. Hver av disse trenger sin egen destinasjon og sin egen observasjon. Et notat som sier at IPv6 virker etter én forespørsel til én vert, er ikke et funn; det er en gjetning med tidsstempel.

Oppføringen som er verdt å beholde er kort: destinasjonen, navnet, kildeadressen verten valgte, den observerte fjernadressen og tidspunktet. RFC 7359 drøfter hvordan man tester at en relevant IPv6-vei faktisk er brukbar, og det er standarden denne veiledningen nærmer seg med enklere verktøy. Hvis konklusjonen trenger en offentlig kontrollør for å være sann, var testen ikke spesifikk nok.