El túnel complet va matar la sessió SSH: fixa la ruta de retorn

Inicia un OpenVPN client a la màquina on treballes per SSH, i a mig comandament la sessió es congela. El túnel es declara connectat, l'amfitrió arriba a internet a través d'ell i les teves pulsacions segueixen arribant mentre no torna res. El que ha canviat no és el túnel: és el camí de retorn dels paquets adreçats a tu, que ara coincideix amb la nova ruta per defecte i entra en un túnel que la passarel·la remota no farà servir per arribar a la teva taula.

Què instal·la realment redirect-gateway

En la seva forma def1, redirect-gateway afegeix 0.0.0.0/1 i 128.0.0.0/1 en lloc de sobreescriure la ruta per defecte. Aquestes dues meitats cobreixen tot l'espai d'adreces i totes dues segueixen sent prefixos més llargs que 0.0.0.0/0, així que qualsevol destinació sense una coincidència més específica entra ara al túnel. Aquest és el mecanisme que cal retenir, perquè cada correcció d'aquí baix funciona instal·lant una coincidència més específica.

La teva adreça administrativa és una d'aquestes destinacions.

El servidor VPN reenvia el tràfic dels seus clients cap a internet. No té cap ruta per a l'adreça pública des de la qual et connectes, ni cap motiu per tractar aquests paquets com una cosa diferent del tràfic que arriba d'un client, així que els descarta. Mentrestant, la petició que has enviat sí que ha arribat a l'amfitrió, i per això la sessió sembla viva només d'un costat.

ip route show table main | head -n 20
ip route get 198.51.100.23

Troba la teva adreça d'origen i el camí anterior al túnel

Al servidor, llista la connexió SSH establerta i anota l'adreça del parell de la qual ha vingut. Aquesta adreça és la que ha de cobrir la teva ruta de retorn, i no sempre és la que creus: un amfitrió de salt, una passarel·la NAT o un traductor d'operadora poden substituir la font per una altra.

Després troba la passarel·la física i la interfície que portaven el tràfic abans que arrenqués el túnel. En la def1 disposició la ruta per defecte encara és present sota les mitges rutes per defecte, així que la informació està disponible, tot i que llegir una taula de rutes llarga a ull convida a errors.

Anota els dos valors i el nom de la interfície junts, perquè la ruta que estàs a punt d'afegir necessita tots tres. Si l'amfitrió feia servir una regla d'encaminament per polítiques per triar el seu enllaç ascendent, pot ser que una ruta simple no es consulti gens, i aquesta possibilitat canvia la correcció.

Fixa una ruta d'amfitrió que superi les mitges rutes per defecte

Una ruta /32 és més llarga que qualsevol de les dues mitges rutes per defecte, així que les respostes a la teva adreça la prenen amb preferència al túnel. El següent salt és la passarel·la anterior al túnel i el dispositiu és la interfície física, cosa que manté el paquet en el camí que feia servir abans que el túnel existís.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifica amb una consulta en lloc d'inspeccionar la taula: la resposta ha de nomenar eth0 i la passarel·la, mai tun0.

OpenVPN ja afegeix una ruta d'amfitrió cap a la pròpia adreça del servidor VPN pel mateix motiu, així que el patró resulta familiar i l'adreça administrativa és simplement una altra excepció. No recorris a route-nopull per arreglar això, perquè descarta les rutes empenyudes que el túnel necessita, inclosa la xarxa remota i les opcions de DNS.

Fes que sobrevisqui a una reconnexió

Una ruta afegida a mà desapareix quan el client es reconnecta i reinstal·la la seva, cosa que converteix una correcció en una caiguda recurrent. Enganxa el comandament a alguna cosa que s'executi després d'instal·lar-se les rutes.

Tant un script route-up com el hook pre-up del gestor de xarxa funcionen, i la comprovació fiable és una reconnexió seguida de la mateixa consulta.

A Windows l'equivalent és una ruta persistent afegida amb -p, que sobreviu als reinicis però encara ha d'apuntar a la passarel·la correcta després d'un canvi de xarxa. Sigui quina sigui la plataforma, escriu el motiu al costat de la ruta: el proper administrador ha de saber que existeix per protegir una sessió de gestió, no perquè el disseny de la xarxa ho exigís.

Quan una ruta fixada encara no és prou

El filtratge de camí invers pot descartar un paquet que arriba per una interfície i surt per una altra, que és exactament el que crea una ruta fixada. Comprova el valor efectiu de rp_filter abans de desactivar res globalment, i prefereix corregir l'asimetria a apagar la comprovació. És la configuració per interfície la que s'aplica, i el mode loose sovint només registra l'asimetria en lloc de descartar el paquet. Llegeix les dues coses abans de concloure que el filtre és culpa teva.

Els amfitrions amb encaminament per polítiques necessiten una regla a més d'una ruta, perquè la base de regles tria la taula abans que es consulti la ruta que conté. Una ruta de la taula main és invisible per a un flux que coincideix amb una regla que apunta a una altra taula. Llegeix les regles abans d'afegir res a main. Si una regla ja cobreix el tràfic de gestió, l'excepció pertany a la taula d'aquesta regla.

Mantingues oberta una consola fora de banda mentre proves, i torna-ho a comprovar des d'un segon inici de sessió abans de desconnectar el que estàs fent servir. Una ruta que envia el teu propi tràfic de gestió al túnel talla la connexió a través de la qual la repares. Tornar-hi llavors vol dir una consola sèrie o un arrencament de rescat, que és un mal intercanvi per saltar-se un pas de verificació.