VPN al convidat i VPN a l’amfitrió: quina ruta guanya realment
Dos clients, dues rutes per defecte i un símptoma desconcertant. Anoteu l’adjunció del convidat, seguiu-ne el punt final cap enfora i canvieu després una variable alhora.
Dos clients funcionen alhora, cadascun convençut que posseeix la ruta per defecte, i el símptoma arriba com una cosa estranya: una aplicació del convidat funciona, una altra es resol al lloc equivocat. Un VPN dins del convidat i un VPN a l’amfitrió poden coexistir, però només quan el camí exterior i la política interior coincideixen sobre qui porta què. Engegar tots dos no crea cap cadena per si sol. Anoteu primer l’adjunció i canvieu després una cosa alhora.
Anoteu primer l’adjunció del convidat
El convidat arriba al seu servidor VPN pel camí que li va donar l’hipervisor: NAT darrere de l’amfitrió, un pont cap al segment físic o una xarxa només per a l’amfitrió amb encaminament afegit a sobre. Cada adjunció canvia què pot veure el convidat i què pot fer l’amfitrió amb el seu trànsit. Sota NAT els paquets del convidat semblen venir de l’amfitrió, així que el túnel propi de l’amfitrió pot portar-los sense que el convidat en sàpiga res. Sota un pont el convidat té presència pròpia al segment i la seva pròpia porta d’enllaç per defecte.
Anoteu l’adjunció abans de tocar cap configuració, juntament amb quin client ha de portar quina aplicació. Aquesta frase resol la majoria d’aquests tiquets, perquè els dos clients solen estar construïts sobre supòsits diferents. Un convidat que ha d’usar el túnel de l’amfitrió no ha de tenir també una ruta per defecte competidora pròpia.
Seguiu el punt final del convidat cap enfora
Un VPN del convidat necessita un camí utilitzable cap al seu servidor abans que res més pugui funcionar. Quan el túnel de l’amfitrió està actiu i el convidat seu darrere de NAT, l’intercanvi del convidat surt pel túnel de l’amfitrió, que és o el disseny o un accident que ningú no va documentar. Quan el túnel de l’amfitrió cau i el convidat en depenia, el convidat perd la connectivitat sense ni un sol canvi a la seva banda. Seguir el punt final cap enfora us diu quin d’aquests dos casos teniu realment.
Una ruta àmplia en qualsevol dels dos contextos captura trànsit que l’altre client esperava. Una ruta 0.0.0.0/0 dins del convidat i un client d’amfitrió amb túnel complet reclamen tots dos tot, i guanya el que s’apliqui més tard. Les superposicions entre les xarxes virtuals del convidat, la LAN local i les xarxes remotes produeixen el mateix efecte per a prefixos privats, amb fallades que semblen problemes d’autenticació; el comportament de traducció d’adreces és el mateix que es descriu per a l’enxarxament de contenidors.
Compareu un registre d’abans i de després
Preneu una línia base amb el túnel de l’amfitrió apagat, o en qualsevol estat controlat que la vostra política permeti, i anoteu la ruta i el resolutor del convidat. Apliqueu després la configuració combinada i compareu els dos registres, mantenint intactes els requisits de privadesa. Si una línia base directa no és adequada, escriviu aquesta limitació al registre en lloc d’ometre la comparació.
ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12
La consulta de ruta anomena la interfície i l’adreça d’origen que portarien una destinació concreta, i és la línia més útil d’aquesta investigació. El llistat de regles mostra si l’encaminament per política envia algunes destinacions per una segona taula. La sortida del resolutor mostra si el DNS va seguir el túnel del convidat o es va quedar al camí de l’amfitrió. Executeu les mateixes tres ordres abans i després del canvi, i el delta nomena el culpable.
Manteniu la propietat clara entre reinicis
La restricció d’accés local d’un client d’amfitrió pot bloquejar el trànsit cap a un NAT virtual o un pont, i aquesta restricció es confon habitualment amb un problema de credencials del convidat. Llegiu el comportament documentat del client en lloc de desactivar la restricció per fer passar una prova. Després d’una correcció suportada, torneu a provar l’aplicació del convidat i la política de fallada que exigiu. Un amfitrió que es reconnecta amb èxit no demostra res sobre la ruta o el resolutor del convidat.
Decidiu quina banda posseeix la ruta per defecte i escriviu-ho al manual d’operacions. Un reinici del convidat o un canvi de xarxa a l’amfitrió que inverteixi la propietat en silenci produeix un informe d’error sobre un VPN que mai no va tenir culpa. L’arranjament hauria de sobreviure a un reinici sense que ningú recordi per què funcionava.