Varför adapterordningen inte avgör labbets VPN-rutt

Att adapter 1 står först i hypervisorns lista är bara en visningsordning, och gästens routingtabell läser den inte. Det som avgör vägen är prefixet, metriken och varje policyregel som gäller före båda. Därför kan det att lägga till en bryggadapter på en labb-VM skapa en andra standardväg medan det gamla NAT-gränssnittet fortfarande visas som närvarande och numrerat som nummer två. Resultatet är en VM som ibland använder tunneln och ibland inte, utan någon konfigurationsändring som förklarar det.

Tre villkor avgör vägen

De tre villkoren är vilket prefix som är mer specifikt, vad metrikerna gör när prefixen är lika, och vilka regler gästen tillämpade efter maskinvaruändringen. Var och en kan besvaras med ett enda kommando, och ingen av dem handlar om hypervisorns numrering.

Just den sista punkten är beslutet: om du inte kan säga vilket prefix som vinner för VPN-slutpunktens egen adress har du ingen routingpolicy, du har en topologi som råkar fungera i dag.

Villkor ett: vilket prefix vinner

En rutt till 10.8.0.0/24 slår en standardrutt för en adress inom den, oavsett metriker och oavsett adapterordning. Därför fortsätter en VPN-klient som installerar en specifik rutt att fungera även när en andra adapter dyker upp med lägre metrik: specificitet vinner innan kostnaden beaktas. Kontrollera med ip route show tabellen du tror används, och med ip route get 203.0.113.9 svaret som kärnan faktiskt skulle ge för en bestämd destination.

Slutpunktens egen adress är det test som betyder mest. Om VPN-serverns adress löses upp via en nyligen tillagd bryggadapter kan tunneln aldrig upprättas, eller så upprättas den och förlorar sedan sin egen transportväg. Fråga specifikt efter den adressen i stället för att anta att tunnelgränssnittet är svaret.

Villkor två: vad metriken gör och inte gör

Dess roll är snävare än de flesta väntar sig. Metriker avgör oavgjort mellan rutter till samma prefix; de låter inte en bredare rutt slå en mer specifik. Vid oavgjort föredras det lägre talet, och olika operativsystem räknar i motsatta riktningar, vilket är anledningen till att råd som kopieras mellan Linux och Windows ofta motsäger sig själva.

I gästen skriver ip route show ut metriken bredvid varje rutt, och Get-NetRoute i Windows skriver ut en InterfaceMetric plus en ruttmetrik. Läs båda, eftersom den effektiva preferensen kan vara en summa och inte ett enda fält. Om det finns två standardrutter är det fyndet: gästen har två vägar ut, och vilken som vinner är en funktion av tal som en maskinvaruändring kan ändra.

Villkor tre: vad gästen faktiskt har tillämpat

Konfiguration är inte samma sak som tillämpat tillstånd. Gränssnittsnamn är inte stabila genom maskinvaruändringar på alla plattformar, och en konfiguration som passade på ett namn gäller kanske inte för något nu.

Kontrollera det tillämpade tillståndet i stället för det avsedda. ip -br link visar gränssnitten som finns nu, och på en värd med NetworkManager visar nmcli connection show vilken profil som är bunden till vilken enhet. En profil som inte kunde bindas lämnar gränssnittet uppe utan adressering, vilket ser ut som ett routingproblem och är ett namnproblem. Återställda ögonblicksbilder förvärrar detta, eftersom gästens sparade tillstånd kan referera till adapteridentiteter som den nya hårdvaran inte längre tillhandahåller.

Håll labbets topologi reproducerbar

Spara de avsedda virtuella nätverksanslutningarna tillsammans med gästens konfiguration, så att mappningen från roll till adapter är nedskriven och inte härledd från en listposition.

Vanligtvis räcker fyra roller att namnge: privat länk, hantering, yttre transport och tunnel. Var och en bör i en fil motsvara en bestämd adapter och ett bestämt gästgränssnitt.

Testa sedan den faktiska applikationen efter en maskinvaruändring, en omstart eller en återställd ögonblicksbild, och ta med rutten till VPN-slutpunkten i det testet. Om en gateway-VM ska vara den enda utgången måste du kontrollera att test-VM:en inte har en oavsiktlig andra standardväg, eftersom en bryggadapter lägger till just en andra standardväg. Testa från gästen, inte från hypervisorns konsol, eftersom de två kan vara oense om vilket gränssnitt som är vilket.

VirtualBox nätverksdokumentation beskriver adapterlägena och vad var och en ansluts till, och det är den delen som är värd att läsa innan man lägger till en andra. Ett labb som identifierar vilken adapter som tjänar varje roll gör en ruttändring förklarabar. Ett labb som förlitar sig på hypervisorns numrering gör varje ändring till ett experiment.