Dos túnels OpenVPN en un sol amfitrió Linux: qui és el propietari de la ruta?

Dos perfils connectats, i un d’ells porta en silenci trànsit destinat a l’altre. Un amfitrió Linux pot executar tots dos clients OpenVPN alhora sense dificultat. El que no pot fer és decidir per vosaltres quin procés pot reclamar quin prefix. Aquesta decisió s’ha de prendre abans que pugi el segon túnel, no després que un recurs deixi de respondre.

Partiu de la feina que ha de fer el segon enllaç

Una oficina accessible per un perfil i un laboratori accessible per un altre necessiten tots dos túnels aixecats i que cap dels dos ho reclami tot. Una aplicació tossuda que ha de sortir pel segon perfil necessita una regla de política, no una segona ruta per defecte. Un enllaç de reserva només necessita un túnel funcionant alhora, així que el de recanvi no hauria d’arrencar amb la màquina.

Aquestes són tres configuracions diferents, i es confonen perquè totes tres comencen igual: un segon perfil i una connexió correcta. Escriviu primer la disposició prevista i després configureu-hi en conseqüència. Una frase d’intenció estalvia una hora de captures de paquets.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

La primera ordre llista les instàncies que s’executen, incloses les iniciades a mà fora del gestor. La segona imprimeix la reivindicació de ruta per defecte actual, que és l’estat que haureu d’explicar més endavant.

Les pools superposades es trenquen abans que l’encaminament

Dos servidors assignaran alegrement adreces del mateix 10.8.0.0/24. Llavors el client té dues interfícies dins d’un sol prefix sense res que digui quina destinació pertany a quina, i el comportament resultant sembla una fallada d’encaminament però en realitat és una fallada de numeració. Renumerar una pool costa una edició de configuració; cada solució d’encaminament posterior costa un cap de setmana. Reviseu la pool abans d’afegir-hi una ruta.

Mireu també la LAN local. Una LAN domèstica numerada 192.168.1.0/24 que un túnel també exposa produeix la mateixa ambigüitat, i el símptoma és un nom d’amfitrió que es resol mentre la connexió no s’acaba mai. Sembla una fallada de resolució de noms fins que imprimiu les rutes.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Compareu les dues sortides amb les dues configuracions de servidor abans de tocar el client. Si els prefixos se superposen, atureu-vos i renumereu, perquè cap quantitat de reinicis no els separarà.

Doneu a cada perfil la seva unitat i a cada prefix un propietari

Cada perfil té el seu propi nom d’instància i el seu propi fitxer de configuració, així que la instància anomenada office carrega office.conf mentre la que es diu lab carrega lab.conf. Confirmeu aquest mapatge a través del gestor de serveis en lloc de confiar en un llistat de directori, ja que un drop-in pot canviar quin fitxer es carrega. Equivocar el mapatge significa que ajusteu el perfil que no s’executa.

Després decidiu qui instal·la les rutes. Quan els servidors empenyen conjunts incompatibles, o rebutgeu l’empenta i lliste els prefixos vosaltres mateixos, o deixeu que un perfil es quedi la ruta per defecte i dirigiu l’altre amb regles de política. Dos processos que instal·len tots dos una ruta per defecte acaben amb un guanyador silenciós i cap registre escrit de la decisió.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

La primera mostra la unitat amb qualsevol anul·lació que en canviï els arguments. La segona mostra si el perfil accepta les rutes empenyudes, que és l’interruptor que decideix tota la resta.

Les marques mantenen les respostes a la interfície d’on han arribat

Quan cada túnel serveix fonts diferents, una resposta pot sortir per l’enllaç equivocat i la connexió mor després del primer paquet. El patró que aguanta és marcar els paquets entrants per la interfície d’entrada, restaurar aquesta marca a la resposta i donar a cada marca una taula amb la seva pròpia porta d’enllaç per defecte.

El filtratge lax de camí invers normalment s’ha de relaxar per a les interfícies afectades, perquè una resposta arriba legítimament per un enllaç que la taula principal mai triaria. Manteniu les marques estretes perquè no capturin mai el trànsit xifrat dels propis túnels, cosa que enviaria el túnel a través de si mateix.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Llegiu les regles existents abans d’afegir-ne una altra. Les prioritats duplicades i les taules oblidades són la raó habitual que una política de marques sembli no tenir cap efecte.

Demostreu l’aïllament aturant un enllaç

Amb tots dos túnels aixecats, anoteu l’adreça de cada interfície, la ruta a un amfitrió darrere de cada túnel i el camí que pren una destinació no relacionada. Demaneu la consulta al nucli en lloc de llegir una sola taula, perquè una taula mai no mostra la decisió final.

Després atureu una instància i observeu com la seva interfície i les seves rutes desapareixen mentre l’altra continua. Una ruptura en la supervivent significa que les dues encara comparteixen un nom de dispositiu, una ruta o una regla de tallafoc que ningú no ha separat.

Torneu a posar el perfil aturat i repetiu les mateixes comprovacions. Quan un túnel només sobreviu a la primera arrencada després d’un reinici, esteu veient un defecte de cicle de vida, no un disseny d’encaminament.