Següent salt en una ruta VPN: per què la passarel·la ha de ser abastable localment

Una ruta cap a una xarxa VPN porta dues adreces que és fàcil confondre: el prefix de destinació que el paquet intenta assolir i el següent salt que el mourà un pas més a prop. En un equip LAN, aquest següent salt ha de ser un encaminador al qual realment pugueu arribar en el mateix enllaç. L’adreça VPN remota no és un següent salt, per molt bé que encaixi amb la destinació que teniu al cap.

Aquest manual cobreix el cas habitual: un portàtil a 192.168.20.0/24, una passarel·la VPN amb una adreça LAN de 192.168.20.5 i una xarxa remota 10.70.0.0/24 darrere d’aquesta passarel·la. Totes les ordres següents assumeixen que sou al portàtil tret que es digui el contrari.

Dues adreces, una ruta

L’entrada prevista és 10.70.0.0/24 via 192.168.20.5. El prefix diu on va el paquet; l’adreça via diu qui el porta allà. El nucli es nega a instal·lar una ruta la passarel·la de la qual no pot assolir per la interfície que anomeneu, i aquesta negativa és tot el punt: un següent salt que necessita el túnel per ser abastable no pot ser el següent salt que construeix el túnel.

Així, la primera comprovació no és «la passarel·la funciona» sinó «la passarel·la és en aquest enllaç». La subxarxa pròpia del portàtil, la seva entrada ARP o de veí i la interfície de la ruta han de coincidir. Una adreça que només existeix dins de 10.70.0.0/24 pot ser la destinació d’una segona ruta, però mai via de la primera.

A què obliga el següent salt la passarel·la

Instal·lar la ruta al portàtil només decideix el primer lliurament. Després la passarel·la necessita el seu propi camí: reenviament activat, una ruta de túnel per a 10.70.0.0/24 i qualsevol política d’accés que regeixi qui la pot fer servir. A Linux això és net.ipv4.ip_forward=1 més una ruta de túnel; un tallafoc al davant necessita una regla que permeti el flux reenviat.

La direcció de tornada és la part que la gent oblida. El costat remot ha de tenir una ruta de tornada a 192.168.20.0/24, o el disseny ha de traduir l’origen del portàtil en alguna cosa que el costat remot conegui. Un ping que funciona des de la passarel·la demostra que la passarel·la pot arribar a la xarxa remota; no diu res sobre si els paquets del portàtil sobreviuen al viatge de tornada.

Verifiqueu la consulta des de l’equip que envia

Pregunteu al nucli quin següent salt triaria i llegiu la interfície de la resposta:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Si la consulta informa de la passarel·la i la interfície LAN, la primera etapa està configurada com es pretenia. Si informa del dispositiu de túnel, alguna cosa anterior a la taula és més específica i guanya. Si la ruta no s’instal·la de cap manera, el nucli us diu que la passarel·la no és abastable, i aquest missatge és més útil que qualsevol captura de paquets.

Després repetiu la prova des del lloc correcte. Una petició creada a la passarel·la utilitza l’adreça d’origen pròpia de la passarel·la, cosa que pot amagar una ruta de tornada que falta o una política que només permet certs orígens. El manual d’ip-route separa la destinació, la passarel·la i la substitució onlink, i val la pena entendre la substitució abans de fer-la servir.

No feu servir onlink per fingir abastabilitat

onlink diu al nucli que s’ometi la comprovació d’abastabilitat d’una passarel·la i que hi enviï igualment. No crea cap camí, no resol ARP per a una adreça que no hi és ni fa que un encaminador remot respongui al vostre segment Ethernet. És legítim per a passarel·les que responen però no seuen en una subxarxa connectada, i és un parany quan es fa servir per silenciar un error que no heu explicat.

Si la ruta només s’instal·la amb onlink, la pregunta següent és per què la passarel·la no és on penseu. Una VLAN equivocada, una segona adreça a la interfície equivocada o una errata a l’últim octet produeixen això, i cadascuna també trenca el camí de tornada quan el trànsit comença a fluir.

Els túnels punt a punt no són Ethernet

Un dispositiu de túnel no fa ARP i sovint no té cap subxarxa de veïns amb sentit. Les seves rutes sovint semblen 10.70.0.0/24 dev tun0, sense cap via, perquè el parell és l’únic altre extrem. Copiar un via a l’estil LAN en aquesta taula produeix una ruta que el nucli pot rebutjar o, pitjor, una que apunta a una adreça a la qual el parell no respon mai.

Manteniu els dos models separats al manual: una ruta LAN té una passarel·la abastable, una ruta de túnel té una interfície i un parell. WireGuard, OpenVPN i IPsec exposen formes lleugerament diferents, així que anoteu la forma que realment heu fet servir en lloc de generalitzar a partir d’un sol equip.

Afegiu, confirmeu, revertiu

Tot el canvi són tres ordres i una comprovació, i s’ha d’escriure en aquest ordre:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confirmeu el camí, confirmeu una destinació i després tingueu a mà la línia d’esborrat per si el canvi fa que l’equip no sigui abastable d’una manera que no havíeu previst. Si la ruta ha de sobreviure a un reinici, poseu-la a la configuració de xarxa de l’equip i no en un perfil de l’intèrpret d’ordres, i proveu el reinici abans de confiar-hi. Una ruta que només existeix a l’intèrpret que la va afegir és una ruta que depurareu dues vegades.