Per què l’ordre dels adaptadors no decideix la ruta VPN del laboratori

Que l’adaptador 1 sigui el primer de la llista de l’hipervisor és només un ordre de visualització, i la taula d’encaminament del convidat no el llegeix. El que decideix el camí és el prefix, la mètrica i qualsevol regla de política que s’apliqui abans de totes dues. Per això, afegir un adaptador pont a una VM de laboratori pot crear un segon camí per defecte mentre la interfície NAT antiga encara apareix com a present i numerada segona. El resultat és una VM que de vegades fa servir el túnel i de vegades no, sense cap canvi de configuració que ho expliqui.

Tres condicions decideixen el camí

Les tres condicions són quin prefix és més específic, què fan les mètriques quan els prefixos empaten i quines regles ha aplicat el convidat després del canvi de maquinari. Cadascuna es pot respondre amb una ordre, i cap no depèn de la numeració de l’hipervisor.

Aquest últim punt és la decisió: si no podeu dir quin prefix guanya per a l’adreça pròpia del punt final VPN, no teniu una política d’encaminament, teniu una topologia que avui funciona per casualitat.

Primera condició: quin prefix guanya

Una ruta cap a 10.8.0.0/24 supera una ruta per defecte per a una adreça dins seu, independentment de les mètriques i de l’ordre dels adaptadors. És per això que un client VPN que instal·la una ruta específica continua funcionant fins i tot quan apareix un segon adaptador amb una mètrica més baixa: l’especificitat guanya abans que es consideri el cost. Comproveu amb ip route show la taula que creieu en ús, i amb ip route get 203.0.113.9 la resposta que el nucli donaria realment per a una destinació concreta.

L’adreça pròpia del punt final és la prova que més importa. Si l’adreça del servidor VPN es resol per un adaptador pont acabat d’afegir, el túnel pot no establir-se mai, o bé establir-se i després perdre el seu propi camí de transport. Consulteu aquesta adreça específicament en lloc de suposar que la interfície del túnel és la resposta.

Segona condició: què fa la mètrica i què no fa

El seu paper és més estret del que la majoria espera. Les mètriques desfan empats entre rutes cap al mateix prefix; no deixen que una ruta més àmplia superi una de més específica. Un nombre més baix es prefereix dins d’un empat, i sistemes operatius diferents compten en direccions oposades, per això els consells copiats entre Linux i Windows sovint es contradiuen.

Al convidat, ip route show imprimeix la mètrica al costat de cada ruta, i Get-NetRoute a Windows imprimeix una InterfaceMetric més una mètrica de ruta. Llegiu-les totes dues, perquè la preferència efectiva pot ser una suma i no un sol camp. Si existeixen dues rutes per defecte, aquesta és la troballa: el convidat té dues sortides, i quina guanya és funció de nombres que un canvi de maquinari pot alterar.

Tercera condició: què ha aplicat realment el convidat

La configuració no és el mateix que l’estat aplicat. Els noms d’interfície no són estables entre canvis de maquinari a totes les plataformes, i una configuració que coincidia per nom pot ara no aplicar-se a res.

Comproveu l’estat aplicat i no el previst. ip -br link mostra les interfícies que existeixen ara, i en un amfitrió amb NetworkManager nmcli connection show mostra quin perfil està vinculat a quin dispositiu. Un perfil que no s’ha pogut vincular deixa la interfície aixecada sense adreçament, cosa que sembla un problema d’encaminament i és un problema de noms. Les instantànies restaurades ho empitjoren, perquè l’estat desat del convidat pot referenciar identitats d’adaptador que el nou maquinari ja no proporciona.

Manteniu reproduïble la topologia del laboratori

Deseu els adjunts de xarxa virtual previstos al costat de la configuració del convidat, perquè la correspondència de rol a adaptador quedi escrita en lloc d’inferida d’una posició a la llista.

Normalment n’hi ha prou amb quatre rols per anomenar: enllaç privat, gestió, transport exterior i túnel. Cadascun hauria de correspondre a un adaptador concret i a una interfície de convidat concreta, en un fitxer.

Després proveu l’aplicació real després d’un canvi de maquinari, un reinici o una instantània restaurada, i incloeu la ruta cap al punt final VPN en aquesta prova. Si una VM de passarel·la ha de ser l’única sortida, verifiqueu que la VM de prova no tingui un segon camí per defecte no desitjat, perquè un segon camí per defecte és exactament el que afegeix un adaptador pont. Proveu des del convidat, no des de la consola de l’hipervisor, ja que tots dos poden no coincidir sobre quina interfície és quina.

La documentació de xarxes de VirtualBox descriu els modes d’adaptador i a què s’adjunta cadascun, que és la part que val la pena llegir abans d’afegir-ne un segon. Un laboratori que identifica quin adaptador serveix cada rol fa explicable un canvi de ruta. Un laboratori que depèn de la numeració de l’hipervisor converteix cada canvi en un experiment.