Hvilken IPv6-kilde en VPN-forespørsel velger, og hvorfor det spiller en rolle

Du la inn en VPN-adresse og regnet med at forespørselen skulle bruke den, men tjeneren førte fortsatt det gamle prefikset i loggen. Ingenting sviktet i tunnelen; maskinen valgte kildeadresse før den i det hele tatt konsulterte ruten du så på. Valget av IPv6-kilde er en separat, ordnet konkurranse mellom maskinens kandidatadresser, og det lengste treffende prefikset er bare én regel mot slutten av denne konkurransen. For å oppnå resultatet du ønsker, må du vite hvilken regel som allerede har vunnet. Reglene selv er kjedelige og nøyaktige, og nettopp derfor bør de leses i rekkefølge.

To oppslag, ikke ett

Valget av destinasjon bestemmer neste hopp og grensesnittet ut. Deretter bestemmer kildevalget hvilken av maskinens adresser som dukker opp i headeren, og de to spørsmålene besvares av forskjellige mekanismer selv om begge bruker prefikser. En maskin med fysisk adresse, midlertidig adresse og VPN-adresse har tre kandidater for en hvilken som helst destinasjon, og ruten mot VPN utpeker ikke den tredje automatisk.

Derfor kan en korrekt rute og en gal kilde leve så lett side om side, og derfor kan samme forespørsel oppføre seg forskjellig fra en nettleser og fra en tvungen binding. Behandle de to oppslagene som adskilte til du har bevis som binder dem sammen.

Les reglene som en ordnet konkurranse

RFC 6724 lister reglene i rekkefølge, og hver av dem bryter bare en uavgjort situasjon som de forrige har etterlatt. Preferansen for utgående grensesnitt og etikettsamsvar dukker opp lenge før prefikssammenligningen, så en adresse på grensesnittet ruten bruker har allerede oppnådd en fordel som et bedre prefikstreff ikke kan slette. Utfasing og omfang er også med, og derfor hender det at en utdatert adresse slutter å bli valgt uten at noen endrer politikken.

Den praktiske lesemåten er at du ikke kan resonnere om vinneren bare ut fra destinasjonen. List opp kandidatene, gå gjennom reglene i rekkefølge og se hvor beslutningen faktisk ble tatt.

Legg merke til at dette er kildehalvdelen av problemet. Å blande de to prefikssammenligningene gir forklaringer som klinger strengt og forutsier feil adresse. Si hvilken sammenligning du mener hver gang du bruker ordet prefiks i en sak.

En binding fra programmet endrer spørsmålet

Et program kan be om en bestemt kildeadresse, og et gyldig eksplisitt valg flytter spørsmålet fra «hvilken adresse ville maskinen foretrekke» til «kan den adressen nå destinasjonen og komme tilbake». Verktøy som binder seg til en kilde, eller som ber om tilleggsdata om den valgte adressen, avdekker dette direkte, og de er den raskeste veien til å bevise hvilken adresse en forbindelse faktisk brukte. Det eksperimentet slår det å lese rutetabellen for tredje gang, fordi det rapporterer hva kjernen bestemte i stedet for hva du konfigurerte. Gjenta det etter endringen og sammenlign de to svarene.

Dermed blir kildebinding både et diagnoseverktøy og en midlertidig løsning: bind VPN-adressen og se om forespørselen lykkes. Hvis den gjør det, er veien i orden og valget var problemet. Hvis ikke, var returveien eller politikken hos motparten problemet hele tiden.

Kontroller at motparten godtar den kilden

Uansett hva maskinen velger, må det passe inn i VPN-ens beskyttede omfang og i returruten og tilgangsreglene i den fjerne enden. En kilde utenfor selektorene kan reise inn i tunnelen og bli forkastet i den fjerne enden, noe som ser ut som en ensidig feil og blir lagt på rutingen. Sammenlign den valgte indre kilden med beskyttelsesomfanget før du berører krypteringsinnstillingene, fordi modusbytte ikke velger mellom kandidatadresser.

Hold også adressen til det ytre endepunktet adskilt i resonnementet ditt. Den identifiserer transporten mellom VPN-deltakerne og er ikke kilden til programpakken innenfor.

Avgjør med fire observasjoner

Noter destinasjonen som ble brukt, de kvalifiserte lokale kildene, kilden som faktisk ble valgt og den effektive utgående veien. Fire linjer er nok til å forklare nesten ethvert tilfelle, og de kan sammenlignes mellom en fungerende og en feilende maskin uten å gjenåpne teoridebatten. For valgtrinnet bør du bruke operativsystemets egen støttede visning i stedet for et navn fra standarden, fordi implementasjoner legger til egne lokale preferanser.

Når svaret fortsatt overrasker deg, gjør rekkefølgen noe som den mentale modellen din ikke gjør, og botemidlet er å endre inndataene i stedet for å krangle med algoritmen. Skriv de fire observasjonene i saken, og neste leser kan gjenskape konklusjonen din.