Hvorfor adapterrækkefølgen ikke afgør din lab-VPN-rute

At adapter 1 står først på hypervisorens liste er en visningsrækkefølge, og gæstens rutetabel læser den ikke. Det, der afgør ruten, er præfikset, metrikken og enhver politikregel, der gælder før begge. Derfor kan tilføjelsen af en brodapter til en lab-VM skabe en anden standardrute, mens det gamle NAT-interface stadig vises som til stede og nummereret som nummer to. Resultatet er en VM, der nogle gange bruger tunnelen og nogle gange ikke, uden nogen konfigurationsændring, der forklarer det.

Tre betingelser afgør ruten

De tre betingelser er, hvilket præfiks der er mere specifikt, hvad metrikkerne gør, når præfikserne er ens, og hvilke regler gæsten anvendte efter hardwareændringen. Hver af dem kan besvares med én kommando, og ingen af dem involverer hypervisorens nummerering.

Det sidste punkt er beslutningen: hvis du ikke kan sige, hvilket præfiks der vinder for VPN-endepunktets egen adresse, har du ikke en rutepolitik, du har en topologi, der tilfældigvis virker i dag.

Betingelse et: hvilket præfiks vinder

En rute til 10.8.0.0/24 slår en standardrute for en adresse inden for den, uanset metrikker og uanset adapterrækkefølge. Derfor bliver en VPN-klient, der installerer en specifik rute, ved med at virke, selv når en anden adapter dukker op med en lavere metrik: specificitet vinder, før omkostningen overvejes. Kontroller med ip route show den tabel, du tror er i brug, og med ip route get 203.0.113.9 det svar, kernen faktisk ville give for en bestemt destination.

Endepunktets egen adresse er den test, der betyder mest. Hvis VPN-serverens adresse opløses gennem en nyligt tilføjet brodapter, bliver tunnelen måske aldrig etableret, eller den etableres og mister derefter sin egen transportvej. Spørg specifikt til den adresse i stedet for at antage, at tunnelinterfacet er svaret.

Betingelse to: hvad metrikken gør, og hvad den ikke gør

Dens rolle er snævrere, end de fleste forventer. Metrikker afgør uafgjorte forhold mellem ruter til samme præfiks; de lader ikke en bredere rute slå en mere specifik. Et lavere tal foretrækkes ved uafgjort, og forskellige styresystemer tæller i modsatte retninger, hvilket er grunden til, at råd kopieret mellem Linux og Windows ofte modsiger sig selv.

I gæsten udskriver ip route show metrikken ved siden af hver rute, og Get-NetRoute i Windows udskriver en InterfaceMetric plus en rutemetrik. Læs begge, fordi den effektive præference kan være en sum og ikke et enkelt felt. Hvis der findes to standardruter, er det fundet: gæsten har to veje ud, og hvilken der vinder, er en funktion af tal, som en hardwareændring kan ændre.

Betingelse tre: hvad gæsten faktisk har anvendt

Konfiguration er ikke det samme som anvendt tilstand. Interface-navne er ikke stabile på tværs af hardwareændringer på alle platforme, og en konfiguration, der passede på et navn, gælder måske nu ikke for noget.

Kontroller den anvendte tilstand i stedet for den tilsigtede. ip -br link viser de interfaces, der findes nu, og på en NetworkManager-vært viser nmcli connection show, hvilken profil der er bundet til hvilken enhed. En profil, der ikke kunne bindes, efterlader interfacet oppe uden adressering, hvilket ligner et rute problem og er et navneproblem. Gendannede snapshots gør det værre, fordi gæstens gemte tilstand kan referere til adapteridentiteter, som det nye hardware ikke længere leverer.

Hold lab-topologien reproducerbar

Gem de tilsigtede virtuelle netværkstilknytninger sammen med gæstens konfiguration, så mappingen fra rolle til adapter er skrevet ned i stedet for udledt af en listeposition.

Fire roller er normalt nok at navngive: privat forbindelse, styring, ekstern transport og tunnel. Hver bør i en fil knyttes til en bestemt adapter og et bestemt gæste-interface.

Test derefter den faktiske applikation efter en hardwareændring, en genstart eller et gendannet snapshot, og inkluder ruten til VPN-endepunktet i den test. Hvis en gateway-VM skal være den eneste udgang, skal du kontrollere, at test-VM’en ikke har en utilsigtet anden standardrute, fordi en brodapter tilføjer netop en anden standardrute. Test fra gæsten, ikke fra hypervisor-konsollen, da de to kan være uenige om, hvilket interface der er hvilket.

VirtualBox’ netværksdokumentation beskriver adaptertilstandene og hvad hver af dem tilsluttes, hvilket er den del, der er værd at læse, før man tilføjer en anden. Et lab, der identificerer, hvilken adapter der tjener hvilken rolle, gør en ruteændring forklarlig. Et lab, der stoler på hypervisorens nummerering, gør enhver ændring til et eksperiment.