Servidor ou cliente: que unidade de OpenVPN nun Pi con dobre papel

Dous procesos de OpenVPN execútanse nun Pi que á vez admite usuarios itinerantes e chega a un provedor superior, e non comparten case nada agás o hardware. Un escoita os túneles entrantes mentres o outro marca cara a fóra. Cada un le o seu propio directorio, e cada un ten o seu propio modo de fallo. Reiniciar o equivocado é a forma máis común de que unha corrección do cliente acabe sacudindo o oínte.

Casa o nome da unidade co directorio que carga

Upstream 2.6 inclúe dúas unidades de modelo, [email protected] e [email protected]. O modelo do servidor arrinca en /etc/openvpn/server e carga %i.conf desde alí. O modelo do cliente arrinca en /etc/openvpn/client. Unha instancia chamada roaming pode existir nos dous sitios á vez, como servidor e como cliente, con dúas configuracións sen relación e ningún vínculo entre elas máis alá da cadea.

Pregunta a systemd en lugar do sistema de ficheiros, porque os empaquetadores engaden ficheiros adicionais que poden cambiar o directorio de traballo ou os argumentos que recibe o binario.

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

O primeiro comando enumera cada unidade instanciada, incluídas as que fallaron e quedaron cargadas. O segundo imprime o ficheiro da unidade xunto con calquera substitución. O terceiro é a forma máis rápida de ver os dous feitos que deciden a cuestión: o directorio no que arrinca o proceso, e a ruta de configuración que se lle deu.

Decide pola dirección dos paquetes, non polo nome da interface

Unha instancia de servidor posúe un socket de escoita e acepta conexións. O seu transporte cifrado é entrada local e saída local no Pi, mentres que o tráfico que reenvía para os usuarios segue a ruta de reenvío e responde a outro conxunto de regras. Unha instancia de cliente non ten oínte nese sentido: marca cara a un par, así que o seu transporte cifrado é saída local cara á capa inferior.

Esa diferenza dixeche a onde pertence unha regra. Unha regra que coincide cunha interface dentro dunha cadea de reenvío só permite o tráfico que o encamiñamento xa seleccionou; nunca selecciona a ruta. Cando os paquetes dun usuario itinerante saen polo camiño equivocado, a cadea que hai que inspeccionar é forward, non output.

Mira os sockets antes de teorizar. Un servidor ligado a udp/1194 mostra un socket de escoita. O cliente mostra unha asociación co enderezo do provedor e nada que escoite.

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

A ruta por defecto dunha instancia pode capturar as respostas da outra

Un redirect-gateway empurrado polo cliente superior instala unha ruta por defecto que compite con todo o demais da máquina, incluída as respostas que o servidor envía aos usuarios itinerantes. OpenVPN fai unha excepción para o seu propio enderezo de par para que o túnel siga sendo alcanzable, pero esa excepción non di nada sobre un teléfono nunha rede de hotel.

O síntoma adoita ser asimétrico. O handshake complétase, o cliente informa de que está conectado, e o tráfico morre tras o primeiro paquete de resposta. O encamiñamento de políticas baseado na fonte, ou unha marca de paquete posta na instancia do servidor con --mark, mantén os dous fluxos separados; ningunha das dúas cousas é un conxunto completo de regras por si soa, e ambas necesitan rutas válidas na táboa que elixan.

Proba a decisión local en lugar do estado do túnel, porque o núcleo elixe a fonte e a interface antes de que OpenVPN vexa o paquete.

ip route get 203.0.113.44
ip rule show

Reinicia un papel e demostra que o outro sobreviviu

A orde importa cando os dous papeis dependen da mesma capa inferior. Reinicia o cliente primeiro se a ruta superior debe existir antes de que se poida reenviar o tráfico dos usuarios, e reinicia o servidor primeiro cando só cambias o seu oínte ou o seu grupo. En calquera caso, confirma as dúas unidades despois, porque un reinicio fallido pode deixar o outro papel funcionando cun estado obsoleto.

Escribe a condición de parada antes do cambio: perder o túnel superior bloquea os usuarios itinerantes ou recae na ligazón ascendente propia do Pi? DNS e IPv6 tamén necesitan unha resposta explícita, porque un resolutor empurrado adoita sobrevivir á ruta que o fixo útil.

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

Acepta o cambio só cando se cumpran tres cousas á vez: complétase unha nova conexión entrante, unha aplicación reenviada chega ao seu destino pola saída prevista, e ambos procesos seguen informando do seu par esperado. Se unha das tres falla, cambiaste a instancia equivocada ou a ruta equivocada, e o seguinte paso é reler a unidade en lugar de reiniciar calquera outra cousa.