OpenVPN redirect-gateway: què fa cada indicador a les rutes

Connecteu-vos amb redirect-gateway al perfil i la ruta per defecte de la màquina pot desaparèixer, dividir-se en dues o quedar-se exactament on era, segons indicadors que ningú no llegeix dues vegades. L’opció modifica l’estat d’encaminament i res més, així que l’única prova fiable del que ha fet és la taula que el client ha instal·lat després. El que segueix és la taula després d’una connexió, la ruta que manté viu el túnel mateix i el trànsit IPv6 que la directiva no afirma mai cobrir. Cada pas és una ordre que podeu executar al client mentre el túnel és actiu.

Què fa cada indicador a la ruta per defecte

Sense cap indicador, l’opció elimina la ruta per defecte ordinària i hi posa el túnel, de manera que la vella porta d’enllaç desapareix de la taula mentre la connexió és activa. Afegiu def1 i aquesta ruta per defecte continua llistada, amb dues rutes més estretes fent la feina. Afegiu bypass-dhcp i la ruta DHCP també sobreviu, cosa que importa en una xarxa on el client encara ha d’arribar al servidor DHCP local. La llista d’indicadors de la pàgina del manual d’OpenVPN 2.6 és prou curta per llegir-la un cop, i cada entrada canvia quines rutes acaben a la taula.

Una opció emesa es comporta igual quan arriba, així que el perfil del client pot no contenir res mentre la taula sembla completament redirigida. És normal: el servidor va enviar els indicadors, el client els va aplicar i el fitxer local no va esmentar mai la directiva. Quan una emissió sembla no fer res, comproveu el filtre del costat del client que accepta o descarta les opcions estirades, perquè una opció descartada no genera cap error en cap dels dos costats.

def1 guanya per especificitat sense tocar la ruta per defecte

Dues rutes de mig defecte cobreixen entre elles l’espai IPv4, 0.0.0.0/1 i 128.0.0.0/1. Cadascuna és més específica que 0.0.0.0/0, així que una consulta les prefereix mentre la ruta per defecte real es queda a la taula per a tot el que demana la coincidència menys específica.

Llegiu la taula més que el perfil, perquè només la taula mostra en quin d’aquests casos esteu. Dues línies n’hi ha prou per distingir-los:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Fixeu-vos en la interfície i la mètrica de cada línia, no només en la destinació. Una ruta per defecte que apunta al túnel i una parella de mig defecte que apunten al túnel descriuen la mateixa intenció i fallen de manera diferent quan el túnel cau, perquè en un cas el recanvi encara existeix. Anoteu tots dos camps a la nota de canvi. Un recanvi supervivent és de vegades el que manté una sessió remota viva prou estona per reparar el túnel, i també és el que filtra trànsit quan la intenció era un túnel complet.

Manteniu l’extrem del túnel abastable

El client necessita una ruta fins a l’extrem llunyà del túnel que no passi ella mateixa pel túnel. OpenVPN instal·la aquesta ruta d’amfitrió abans de canviar res més, i una edició manual de rutes o un segon client VPN poden treure-la. El símptoma posterior és una connexió que diu que està connectada i després no passa res.

Pregunteu al nucli quina interfície faria servir per a l’adreça de l’extrem mentre el túnel és actiu. La resposta ha de nomenar la interfície física i la seva porta d’enllaç, mai tun0:

ip route get 198.51.100.20

Si aquesta consulta retorna el dispositiu del túnel, el túnel porta el seu propi transport i col·lapsarà tan bon punt un paquet hagi de sortir. Els prefixos locals, un segon adaptador i l’encaminament per política encara importen aquí, i per això una redirecció que funciona en un portàtil net pot fallar en un amfitrió amb una interfície de gestió i dues rutes per defecte. Normalment es culpa el perfil del que ha fet el pla d’adreces.

El trànsit IPv6 continua usant la seva taula

Redirigir IPv4 deixa IPv6 tranquil, i les dues famílies es canvien amb indicadors diferents. En un amfitrió de doble pila amb una ruta v6 per defecte que funciona, el trànsit v4 pot quedar completament dins del túnel mentre cada destinació capaç de v6 surt per l’enllaç físic. Un amfitrió que sembla correcte en una taula filtra a l’altra.

Comproveu la taula v6 després de connectar en lloc de suposar que el túnel l’ha coberta. La directiva porta indicadors de família d’adreces precisament per això, i un perfil que els omet hereta el que la plataforma fa per defecte:

ip -6 route show default
ip -6 route get 2001:db8::10

Demostreu quina interfície fa servir una aplicació

Un estat connectat no és un bloqueig, i un canvi de ruta no és un interruptor de seguretat. Si el trànsit directe ha d’aturar-se quan el túnel falla, aquesta política viu al tallafoc i necessita la seva pròpia prova.

Proveu el camí que una aplicació segueix realment en lloc del camí que descriu el perfil. Demaneu primer la ruta, després lligueu una sol·licitud a cada interfície per torn i compareu què informa el costat llunyà:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Si les dues sol·licituds retornen la mateixa adreça, l’aplicació no fa servir el túnel encara que la taula d’encaminament digui que hauria. Si només té èxit la sol·licitud lligada al túnel, el camí físic està filtrat per a aquesta destinació i el túnel fa el que heu demanat. Escriviu els indicadors, les rutes instal·lades, la consulta de l’extrem i tots dos resultats de sortida al registre de canvis, perquè la propera persona hereti fets en lloc d’una captura de pantalla.