Hvorfor adapterrekkefølgen ikke avgjør VPN-ruten i labben din

At adapter 1 står først på listen til hypervisoren, er bare en visningsrekkefølge, og rutingtabellen til gjesten leser den ikke. Det som avgjør ruten, er prefikset, metrikken og enhver policyregel som gjelder før begge. Derfor kan det å legge til en broadapter på en lab-VM skape en andre standardrute mens det gamle NAT-grensesnittet fortsatt vises som til stede og nummerert som nummer to. Resultatet er en VM som noen ganger bruker tunnelen og noen ganger ikke, uten noen konfigurasjonsendring som forklarer det.

Tre betingelser avgjør ruten

De tre betingelsene er hvilket prefiks som er mer spesifikt, hva metrikkene gjør når prefiksene er like, og hvilke regler gjesten brukte etter maskinvareendringen. Hver av dem kan besvares med én kommando, og ingen av dem involverer nummereringen til hypervisoren.

Nettopp det siste punktet er beslutningen: hvis du ikke kan si hvilket prefiks som vinner for selve adressen til VPN-endepunktet, har du ingen rutingpolicy, du har en topologi som tilfeldigvis fungerer i dag.

Betingelse én: hvilket prefiks vinner

En rute til 10.8.0.0/24 slår en standardrute for en adresse innenfor, uansett metrikker og uansett adapterrekkefølge. Derfor fortsetter en VPN-klient som installerer en spesifikk rute å virke selv når en andre adapter dukker opp med lavere metrikk: spesifisitet vinner før kostnaden vurderes. Sjekk med ip route show tabellen du tror er i bruk, og med ip route get 203.0.113.9 svaret kjernen faktisk ville gi for en bestemt destinasjon.

Endepunktets egen adresse er testen som betyr mest. Hvis adressen til VPN-serveren løses opp gjennom en nylig tilføyd broadapter, etableres kanskje tunnelen aldri, eller den etableres og mister deretter sin egen transportvei. Spør spesifikt om den adressen i stedet for å anta at tunnelgrensesnittet er svaret.

Betingelse to: hva metrikken gjør og ikke gjør

Rollen er smalere enn de fleste forventer. Metrikker avgjør uavgjort mellom ruter til samme prefiks; de lar ikke en bredere rute slå en mer spesifikk. Ved uavgjort foretrekkes det lavere tallet, og ulike operativsystemer teller i motsatte retninger, og derfor motsier råd som kopieres mellom Linux og Windows ofte seg selv.

I gjesten skriver ip route show ut metrikken ved siden av hver rute, og Get-NetRoute i Windows skriver ut en InterfaceMetric pluss en rutemetrikk. Les begge, fordi den effektive preferansen kan være en sum og ikke ett felt. Hvis det finnes to standardruter, er det funnet: gjesten har to veier ut, og hvilken som vinner er en funksjon av tall som en maskinvareendring kan endre.

Betingelse tre: hva gjesten faktisk har brukt

Konfigurasjon er ikke det samme som anvendt tilstand. Grensesnittnavn er ikke stabile gjennom maskinvareendringer på alle plattformer, og en konfigurasjon som passet på et navn gjelder kanskje ikke for noe nå.

Sjekk den anvendte tilstanden i stedet for den tiltenkte. ip -br link viser grensesnittene som finnes nå, og på en vert med NetworkManager viser nmcli connection show hvilken profil som er bundet til hvilken enhet. En profil som ikke ble bundet, lar grensesnittet stå oppe uten adressering, noe som ser ut som et ruteproblem og er et navneproblem. Gjenopprettede øyeblikksbilder gjør dette verre, fordi gjestens lagrede tilstand kan referere til adapteridentiteter som det nye maskinvaren ikke lenger tilbyr.

Hold labtopologien reproduserbar

Lagre de tiltenkte virtuelle nettverkstilkoblingene sammen med konfigurasjonen til gjesten, slik at koblingen fra rolle til adapter er skrevet ned og ikke utledet fra en posisjon på en liste.

Normalt er fire roller nok å navngi: privat lenke, administrasjon, ytre transport og tunnel. Hver bør i en fil knyttes til en bestemt adapter og et bestemt gjestegrensesnitt.

Test deretter den faktiske applikasjonen etter en maskinvareendring, en omstart eller et gjenopprettet øyeblikksbilde, og ta med ruten til VPN-endepunktet i den testen. Hvis en gateway-VM skal være den eneste utgangen, må du kontrollere at test-VM-en ikke har en utilsiktet andre standardrute, fordi en broadapter legger til nettopp en andre standardrute. Test fra gjesten, ikke fra hypervisor-konsollen, siden de to kan være uenige om hvilket grensesnitt som er hvilket.

VirtualBox’ nettverksdokumentasjon beskriver adaptermodiene og hva hvert av dem kobles til, og det er den delen som er verdt å lese før man legger til en andre. En lab som identifiserer hvilken adapter som tjener hvilken rolle, gjør en ruteendring forklarlig. En lab som stoler på nummereringen til hypervisoren, gjør hver endring til et eksperiment.