Kvifor adapterrekkjefølgja ikkje avgjer VPN-ruta i labben din

At adapter 1 står øvst på lista til hypervisoren, er berre ein visingsrekkjefølgje, og rutetabellen til gjesten les han ikkje. Det som avgjer ruta, er prefikset, metrikken og kvar policyregel som gjeld før begge. Difor kan det å leggje til ein bruadapter på ein lab-VM skape ei andre standardrute medan det gamle NAT-grensesnittet framleis blir vist som til stades og nummerert som nummer to. Resultatet er ein VM som stundom brukar tunnelen og stundom ikkje, utan noka konfigurasjonsendring som forklarer det.

Tre vilkår avgjer ruta

Dei tre vilkåra er kva prefiks som er meir spesifikt, kva metrikkane gjer når prefiksa er like, og kva reglar gjesten brukte etter maskinvareendringa. Kvart av dei kan svarast med éin kommando, og ingen av dei involverer nummereringa til hypervisoren.

Nettopp det siste punktet er avgjerda: om du ikkje kan seie kva prefiks som vinn for sjølve adressa til VPN-endepunktet, har du ingen rutepolicy, du har ein topologi som tilfeldigvis fungerer i dag.

Vilkår ein: kva prefiks vinn

Ei rute til 10.8.0.0/24 slår ei standardrute for ei adresse innanfor, uansett metrikkar og uansett adapterrekkjefølgje. Difor held ein VPN-klient som installerer ei spesifikk rute fram med å verke sjølv når ein andre adapter dukkar opp med lågare metrikk: spesifisitet vinn før kostnaden blir vurdert. Sjekk med ip route show tabellen du trur er i bruk, og med ip route get 203.0.113.9 svaret kjernen faktisk ville gjeve for ein bestemd destinasjon.

Den eigne adressa til endepunktet er testen som tyder mest. Om adressa til VPN-tenaren blir løyst gjennom ein nyleg tilføydd bruadapter, blir tunnelen kanskje aldri etablert, eller han blir etablert og mister då sin eigen transportveg. Spør spesifikt om den adressa i staden for å gå ut frå at tunnegrensesnittet er svaret.

Vilkår to: kva metrikken gjer og ikkje gjer

Rolla hans er smalare enn dei fleste ventar. Metrikkar avgjer uavgjort mellom ruter til same prefiks; dei lèt ikkje ei breiare rute slå ei meir spesifikk. Ved uavgjort blir det lågare talet føretrekt, og ulike operativsystem tel i motsette retningar, og difor motseier råd som blir kopierte mellom Linux og Windows ofte seg sjølve.

I gjesten skriv ip route show ut metrikken ved sida av kvar rute, og Get-NetRoute i Windows skriv ut ein InterfaceMetric pluss ein rutemetrikk. Les begge, fordi den effektive preferansen kan vere ein sum og ikkje eitt felt. Om det finst to standardruter, er det funnet: gjesten har to vegar ut, og kva som vinn er ein funksjon av tal som ei maskinvareendring kan endre.

Vilkår tre: kva gjesten faktisk har brukt

Konfigurasjon er ikkje det same som brukt tilstand. Grensesnittnamn er ikkje stabile gjennom maskinvareendringar på alle plattformer, og ein konfigurasjon som passa på eit namn gjeld kanskje ikkje for noko no.

Sjekk den brukte tilstanden i staden for den tiltenkte. ip -br link viser grensesnitta som finst no, og på ein vert med NetworkManager viser nmcli connection show kva profil som er bunden til kva eining. Ein profil som ikkje vart bunden, lèt grensesnittet stå oppe utan adressering, noko som ser ut som eit ruteproblem og er eit namnepproblem. Gjenoppretta augeblinksbilete gjer dette verre, fordi den lagra tilstanden til gjesten kan vise til adapteridentitetar som det nye maskinvaren ikkje lenger tilbyr.

Hald labtopologien reproduserbar

Lagre dei tiltenkte virtuelle nettverkstilkoplingane saman med konfigurasjonen til gjesten, slik at koplinga frå rolle til adapter er skriven ned og ikkje utleidd frå ein posisjon på ei liste.

Vanlegvis er fire roller nok å namngje: privat lenkje, administrasjon, ytre transport og tunnel. Kvar bør i ei fil knytast til ein bestemd adapter og eit bestemd gjestegrensesnitt.

Test deretter den faktiske applikasjonen etter ei maskinvareendring, ein omstart eller eit gjenoppretta augeblinksbilete, og ta med ruta til VPN-endepunktet i den testen. Om ein gateway-VM skal vere den einaste utgangen, må du kontrollere at test-VM-en ikkje har ei utilsikta andre standardrute, fordi ein bruadapter legg til nettopp ei andre standardrute. Test frå gjesten, ikkje frå hypervisorkonsollen, sidan dei to kan vere usamde om kva grensesnitt som er kva.

Nettverksdokumentasjonen til VirtualBox skildrar adaptermodia og kva kvart av dei blir knytt til, og det er den delen som er verdt å lese før ein legg til ein andre. Ein lab som identifiserer kva adapter som tener kva rolle, gjer ei ruteendring forklarleg. Ein lab som stolar på nummereringa til hypervisoren, gjer kvar endring til eit eksperiment.