Servidor o client: quina unitat OpenVPN en un Pi amb doble paper

Dos processos d’OpenVPN s’executen en un Pi que alhora admet usuaris itinerants i arriba a un proveïdor superior, i gairebé no comparteixen res més enllà del maquinari. Un escolta els túnels entrants mentre l’altre marca cap a fora. Cadascun llegeix el seu propi directori, i cadascun té el seu propi mode de fallada. Reiniciar el que no toca és la manera més habitual que una correcció del client acabi sacsejant l’oient.

Feu coincidir el nom de la unitat amb el directori que carrega

Upstream 2.6 inclou dues unitats de plantilla, [email protected] i [email protected]. La plantilla del servidor arrenca a /etc/openvpn/server i carrega %i.conf des d’allà. La plantilla del client arrenca a /etc/openvpn/client. Una instància anomenada roaming pot existir als dos llocs alhora, com a servidor i com a client, amb dues configuracions sense relació i cap vincle entre elles més enllà de la cadena.

Pregunteu a systemd en lloc del sistema de fitxers, perquè els empaquetadors afegeixen fitxers addicionals que poden canviar el directori de treball o els arguments que rep el binari.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

La primera ordre llista cada unitat instanciada, incloses les que van fallar i van quedar carregades. La segona imprimeix el fitxer de la unitat juntament amb qualsevol substitució. La tercera és la manera més ràpida de veure els dos fets que decideixen la qüestió: el directori on arrenca el procés, i el camí de configuració que se li va lliurar.

Decidiu per la direcció dels paquets, no pel nom de la interfície

Una instància de servidor posseeix un sòcol d’escolta i accepta connexions. El seu transport xifrat és entrada local i sortida local al Pi, mentre que el trànsit que reenvia per als usuaris segueix el camí de reenviament i respon a un altre conjunt de regles. Una instància de client no té cap oient en aquest sentit: marca cap a un parell, així que el seu transport xifrat és sortida local cap a la capa inferior.

Aquesta diferència us diu on pertany una regla. Una regla que coincideix amb una interfície dins d’una cadena de reenviament només permet el trànsit que l’encaminament ja ha seleccionat; mai no selecciona la ruta. Quan els paquets d’un usuari itinerant surten pel camí equivocat, la cadena a inspeccionar és forward, no output.

Mireu els sòcols abans de teoritzar. Un servidor lligat a udp/1194 mostra un sòcol d’escolta. El client mostra una associació amb l’adreça del proveïdor i res que escolti.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

La ruta per defecte d’una instància pot capturar les respostes de l’altra

Un redirect-gateway empès pel client superior instal·la una ruta per defecte que competeix amb tota la resta de la màquina, incloent-hi les respostes que el servidor envia als usuaris itinerants. OpenVPN fa una excepció per a la seva pròpia adreça de parell perquè el túnel segueixi sent abastable, però aquesta excepció no diu res sobre un telèfon en una xarxa d’hotel.

El símptoma sol ser asimètric. L’handshake es completa, el client informa que està connectat, i el trànsit mor després del primer paquet de resposta. L’encaminament de polítiques basat en la font, o una marca de paquet posada a la instància del servidor amb --mark, manté els dos fluxos separats; cap de les dues coses no és un conjunt complet de regles per si sola, i totes dues necessiten rutes vàlides a la taula que triïn.

Proveu la decisió local en lloc de l’estat del túnel, perquè el nucli tria la font i la interfície abans que OpenVPN vegi el paquet.

ip route get 203.0.113.44
ip rule show

Reinicieu un paper i demostreu que l’altre ha sobreviscut

L’ordre importa quan els dos papers depenen de la mateixa capa inferior. Reinicieu el client primer si la ruta superior ha d’existir abans que es pugui reenviar el trànsit dels usuaris, i reinicieu el servidor primer quan només canvieu el seu oient o el seu pool. De qualsevol manera, confirmeu les dues unitats després, perquè un reinici fallit pot deixar l’altre paper funcionant amb un estat obsolet.

Escriviu la condició d’aturada abans del canvi: perdre el túnel superior bloqueja els usuaris itinerants o recau en l’enllaç ascendent propi del Pi? DNS i IPv6 també necessiten una resposta explícita, perquè un resolutor empès sovint sobreviu a la ruta que el va fer útil.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Accepteu el canvi només quan tres coses es compleixin alhora: una nova connexió entrant es completa, una aplicació reenviada arriba a la seva destinació per la sortida prevista, i tots dos processos encara informen del seu parell esperat. Si una de les tres falla, heu canviat la instància equivocada o la ruta equivocada, i el següent pas és rellegir la unitat en lloc de reiniciar qualsevol altra cosa.