Servidor e cliente OpenVPN nun mesmo host: por que caen os clientes

Engada un perfil de cliente a unha máquina que xa executa un servidor VPN e o primeiro damnificado será o servizo orixinal. O túnel novo pode non establecerse nunca, ou pode levantarse mentres os clientes existentes do servidor deixan de recibir respostas sen facer ruído. Dúas colisións producen ambos os resultados: un conxunto de túneles que xa está en uso e unha ruta predeterminada instalada pola metade cliente nova que cobre toda a táboa. Ningunha das dúas xera unha mensaxe de erro de OpenVPN, por iso o fallo se le como un problema do servidor.

Unha máquina, dous roles e dúas respostas incompatibles sobre onde deben ir as respostas.

Mesmo conxunto, dous servidores: cal gaña

Cada instancia de servidor necesita a súa propia subrede de túnel. Copiar unha liña como server 10.8.0.0 255.255.255.0 na segunda configuración dá ás dúas instancias o mesmo prefixo, e o resultado é ou ben unha negativa a arrincar ou ben unha competición silenciosa na que os clientes dun servidor reciben direccións que o outro tamén cre súas. Os portos UDP distintos e os nomes de dispositivo distintos non axudan, porque ningún dos dous toca o espazo de direccións. Cambie o segundo conxunto e cámbieo en todos os sitios onde as rutas o mencionan.

Enumeremos que está activo antes de editar: ip -4 addr show lista os dispositivos de túnel, ss -lunp lista os oíntes e systemctl list-units nomea as unidades. Unha ollada ás direccións do túnel decide se os conxuntos chocan.

Que engade o perfil de cliente á táboa

A metade cliente escribe rutas en canto se conecta. redirect-gateway def1 parte a ruta predeterminada en 0.0.0.0/1 máis 128.0.0.0/1, ambas encamiñadas polo dispositivo novo, xunto cunha ruta de host ao servidor remoto que está deliberadamente fixada á interface física. Esa fixación existe para que o túnel conserve un camiño para o seu propio transporte. Todo o demais, incluídas as respostas que o servidor local debe aos seus propios clientes, segue agora a nova ruta predeterminada e sae pola ligazón remota.

Así que a segunda colisión non é un túnel roto. É un túnel que funciona no lugar equivocado da táboa.

Tres xeitos de manter os roles separados

A corrección menos invasiva mantén a ruta predeterminada fóra do perfil de cliente: route-nopull máis liñas route explícitas para os prefixos remotos, de modo que a táboa local só cambie onde vostede o pediu. O paso seguinte é unha regra de política que exime a subrede de túnel local, deixando que as respostas aos clientes locais saian pola interface pola que chegaron mesmo cando existe unha ruta predeterminada. A máis completa é un espazo de nomes de rede separado para o rol de cliente, que elimina por completo a táboa compartida e custa un segundo contexto de encamiñamento que manter.

Sexa cal sexa o camiño que tome, a excepción debe nomear a subrede de túnel local e non a LAN. A resposta que envía o servidor local ten como destino unha dirección de túnel, así que unha excepción con forma de LAN nunca coincide con ela.

Cal das dúas instancias ten a culpa

Detéña a instancia cliente e volva probar os clientes orixinais. Unha recuperación inmediata significa encamiñamento, non servidor. Volva levantar o cliente e rastrexar unha soa resposta con ip route get ao que se lle dan tanto unha dirección de orixe como de destino, o que mostra o camiño que elixiría o núcleo, e despois observe a interface que os paquetes usan de verdade con tcpdump -ni any port 1194. O ficheiro de estado do servidor, escrito cada poucos segundos mediante a directiva status, contén a lista de clientes conectados e contadores de bytes en ambos os sentidos.

Lea eses contadores uns contra outros. O tráfico que sae e nunca volve é unha resposta de encamiñamento, non un problema de handshake.