Copiar el /32 del túnel no encamina la subxarxa de l’oficina
L’adreça que la VPN dona a l’adaptador descriu l’enllaç, no la destinació. Afegeix el prefix del recurs al perfil i deixa la ruta per defecte tranquil·la.
La VPN es connecta, la interfície mostra una adreça amb una màscara de trenta-dos bits i el servidor de l’oficina continua inabastable. El següent moviment sol ser reutilitzar aquesta màscara en una ruta, amb la teoria que la interfície descriu què pot assolir el túnel. No ho fa. Aquesta adreça descriu l’extrem local d’un enllaç punt a punt, i la destinació que t’importa viu en un prefix diferent a l’altre costat.
S’estan confonent dues coses diferents: l’adreça que et va donar el túnel i la xarxa a la qual vols arribar-hi.
Dues adreces, dues feines
En un túnel punt a punt, l’adreça del client sol ser una única adreça d’amfitrió perquè hi ha exactament un igual a l’altre extrem de l’enllaç. No hi ha segment compartit ni ARP, així que una màscara que semblaria absurda a Ethernet aquí és del tot normal.
El prefix de destinació és un fet sobre la xarxa de l’oficina, no sobre el túnel. Si necessites un servidor, la ruta és una ruta d’amfitrió per a aquest servidor. Si necessites tota la subxarxa de l’oficina, la ruta és la subxarxa. Cap de les dues respostes no es pot llegir de la interfície, i triar-ne una perquè va aparèixer al costat de l’adreça del túnel és com es trenca una configuració que funcionava.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Aquesta tercera fila és on l’optimisme es converteix en una caiguda. Encaminar tot un rang privat cap a un túnel que només serveix un lloc empeny trànsit no relacionat cap a un camí que no el pot lliurar, i les fallades resultants semblen una VPN trencada més que una ruta massa àmplia.
Tria el prefix a partir del requisit
Escriu el requisit com una frase abans de tocar cap perfil: quins amfitrions han de ser abastables i quin és el prefix més estret que els cobreix? Un sol servidor és una ruta d’amfitrió. Una subxarxa és una ruta de subxarxa. Un rang de subxarxes és un resum, i un resum és una promesa que tota adreça que hi ha a dins és abastable, cosa que poques vegades és certa.
Després comprova el número contra el que l’oficina fa servir de debò. Copiar un prefix d’un missatge de xat sense confirmar-lo amb el pla d’adreçament del lloc és com una ruta acaba apuntant a una subxarxa que ningú posseeix.
Recorda també que una ruta és un camí, no un permís. La passarel·la continua decidint si el teu client pot fer servir la destinació, i un servei encara et pot refusar. Instal·lar la ruta correctament hi fa arribar el paquet i no respon res sobre l’autorització.
Afegeix al perfil, no el substitueixis mai
Les rutes d’un perfil de NetworkManager són una propietat de diversos valors, i la diferència entre establir i afegir és un caràcter. Fes servir la forma amb plus per afegir una entrada i conservar tot el que ja està desat.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Sense el plus, l’assignació substitueix tota la llista. En un perfil que ja porta diversos prefixos, això esborra en silenci els que funcionaven, i el símptoma arriba més tard com un servei que abans era abastable des d’aquest portàtil.
Fes servir l’UUID en lloc del nom. Els noms es dupliquen després de les restauracions, i la connexió que edites pot no ser la que porta el teu trànsit. Comprova primer si ja hi ha una entrada idèntica, perquè afegir un duplicat és descurat fins i tot quan és inofensiu.
La referència de propietats de ruta documenta la destinació, el següent salt opcional, la mètrica i la sintaxi d’atributs per a la versió instal·lada. Llegeix-la abans d’afegir un següent salt, perquè si cal o no depèn de la integració i de la topologia, i endevinar-ho a partir de la primera adreça d’un llistat d’interfícies no és un mètode.
La ruta per defecte i el DNS són decisions separades
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Les rutes automàtiques són l’altra cosa que no s’ha de destorbar a la lleugera. Suprimir-les per resoldre una entrada que falta pot eliminar-ne diverses que funcionaven, i qui ho va suggerir normalment mirava un altre perfil amb altres push.
El DNS té el seu propi camí i les seves pròpies fallades. Un nom que es resol a l’adreça correcta a través del resolutor equivocat, o un resolutor que no pot respondre per a la zona privada, semblarà un problema d’encaminament mentre la ruta és perfecta. Prova l’adreça i el nom per separat i després decideix quina capa ha fallat de debò.
Verifica què s’ha aplicat
Una modificació desada no és una modificació aplicada. Torna a connectar-te pel cicle de vida suportat del gestor, i després mira la ruta real per a la destinació prevista i les regles de política que decideixen quina taula es consulta.
Si el prefix hi és i la connexió encara falla, has passat a un altre problema: selecció d’adreça d’origen, una ruta de retorn a l’extrem llunyà o un servei que refusa el teu client. Cadascun d’aquests és un lloc millor on mirar que el perfil que ja has corregit.