Waarom de adaptervolgorde uw lab-VPN-route niet bepaalt

Dat adapter 1 bovenaan de lijst van de hypervisor staat, is alleen een weergavevolgorde, en de routingtabel van de gast leest die niet. Wat het pad bepaalt, zijn het prefix, de metriek en elke beleidsregel die vóór beide geldt. Daarom kan het toevoegen van een bridge-adapter aan een lab-VM een tweede standaardpad opleveren, terwijl de oude NAT-interface nog steeds als aanwezig en als tweede genummerd verschijnt. Het resultaat is een VM die soms de tunnel gebruikt en soms niet, zonder enige configuratiewijziging die dat verklaart.

Drie voorwaarden bepalen het pad

De drie voorwaarden zijn welk prefix specifieker is, wat de metrieken doen wanneer prefixen gelijk zijn, en welke regels de gast na de hardwarewijziging heeft toegepast. Elk is met één commando te beantwoorden, en geen ervan betreft de nummering van de hypervisor.

Juist dat laatste punt is de beslissing: als u niet kunt zeggen welk prefix wint voor het eigen adres van het VPN-eindpunt, hebt u geen routingbeleid, maar een topologie die vandaag toevallig werkt.

Voorwaarde één: welk prefix wint

Een route naar 10.8.0.0/24 verslaat een standaardroute voor een adres daarbinnen, ongeacht metrieken en ongeacht de adaptervolgorde. Daarom blijft een VPN-client die een specifieke route installeert werken, zelfs wanneer een tweede adapter met een lagere metriek verschijnt: specificiteit wint voordat kosten worden overwogen. Controleer met ip route show de tabel die u in gebruik denkt, en met ip route get 203.0.113.9 het antwoord dat de kernel werkelijk zou geven voor een bepaald doel.

Het eigen adres van het eindpunt is de test die het meest telt. Als het adres van de VPN-server via een nieuw toegevoegde bridge-adapter wordt opgelost, komt de tunnel mogelijk nooit tot stand, of komt hij tot stand en verliest daarna zijn eigen transportpad. Vraag specifiek naar dat adres in plaats van aan te nemen dat de tunnelinterface het antwoord is.

Voorwaarde twee: wat de metriek doet en niet doet

Die rol is smaller dan de meeste mensen verwachten. Metrieken beslechten gelijke standen tussen routes naar hetzelfde prefix; ze laten een bredere route niet een specifiekere verslaan. Bij een gelijke stand krijgt het lagere getal de voorkeur, en verschillende besturingssystemen tellen in tegengestelde richtingen, waardoor adviezen die tussen Linux en Windows worden gekopieerd elkaar vaak tegenspreken.

In de gast drukt ip route show de metriek naast elke route af, en Get-NetRoute onder Windows drukt een InterfaceMetric plus een routemetriek af. Lees beide, want de effectieve voorkeur kan een som zijn en niet één veld. Bestaan er twee standaardroutes, dan is dat de bevinding: de gast heeft twee uitgangen, en welke wint is een functie van getallen die een hardwarewijziging kan veranderen.

Voorwaarde drie: wat de gast werkelijk heeft toegepast

Configuratie is niet hetzelfde als toegepaste toestand. Interfacenamen zijn bij hardwarewijzigingen niet op elk platform stabiel, en een configuratie die op een naam paste, geldt nu misschien voor niets.

Controleer de toegepaste toestand in plaats van de bedoelde. ip -br link toont de interfaces die er nu zijn, en op een host met NetworkManager toont nmcli connection show welk profiel aan welk apparaat is gebonden. Een profiel dat niet kon worden gebonden laat de interface omhoog zonder adressering, wat op een routingprobleem lijkt en een naamprobleem is. Herstelde snapshots maken dit erger, omdat de opgeslagen toestand van de gast kan verwijzen naar adapteridentiteiten die de nieuwe hardware niet meer levert.

Houd de labtopologie reproduceerbaar

Bewaar de bedoelde virtuele netwerkaansluitingen naast de configuratie van de gast, zodat de toewijzing van rol aan adapter is opgeschreven in plaats van afgeleid uit een lijstpositie.

Vier rollen zijn meestal genoeg om te benoemen: privékoppeling, beheer, buitentransport en tunnel. Elk moet in een bestand aan een bepaalde adapter en een bepaalde gastinterface worden gekoppeld.

Test daarna de werkelijke toepassing na een hardwarewijziging, een herstart of een hersteld snapshot, en neem de route naar het VPN-eindpunt in die test op. Als een gateway-VM de enige uitgang moet zijn, controleer dan dat de test-VM geen onbedoeld tweede standaardpad heeft, want een bridge-adapter voegt precies een tweede standaardpad toe. Test vanuit de gast, niet vanaf de hypervisorconsole, omdat beide het oneens kunnen zijn over welke interface welke is.

De VirtualBox-netwerkdocumentatie beschrijft de adaptermodi en waaraan elk ervan wordt gekoppeld, en dat is het deel dat de moeite waard is om te lezen voordat u een tweede toevoegt. Een lab dat vastlegt welke adapter welke rol dient, maakt een routewijziging verklaarbaar. Een lab dat op de nummering van de hypervisor vertrouwt, maakt elke wijziging tot een experiment.