Un Pi, dúas instancias de OpenVPN: que le cada unidade

Conte os procesos OpenVPN antes de tocar un perfil. Un Pi que admite usuarios itinerantes e tamén marca un servizo de subida executa dous demos, e cada un le un ficheiro de configuración escollido polo nome de instancia que escribiu. Despois, os modelos empaquetados dan a cada demo o seu propio directorio de traballo, o seu propio ficheiro de estado de execución e o seu propio dispositivo de túnel. Se se equivoca nesa división, pasará unha noite cambiando un axuste correcto dentro dun ficheiro que o proceso en execución nunca abre.

Cada nome de instancia escolle o seu propio ficheiro

Nos ficheiros de unidade que se distribúen con OpenVPN 2.6, os argumentos de arranque levan un marcador de posición de instancia que se enche co texto posterior ao signo @. O modelo do servidor execútase desde o directorio de configuración do servidor e resolve o seu argumento contra %i.conf alí, mentres que o modelo do cliente fai o mesmo desde o directorio do cliente. Así, [email protected] le admits.conf no directorio do servidor, e [email protected] le uplink.conf no directorio do cliente, e ningún dos dous nomes ten significado no outro directorio.

Confirme a correspondencia na propia máquina en lugar de supoñer que o paquete conservou os valores predeterminados da orixe. Un drop-in da distribución pode substituír o directorio de traballo ou o argumento de configuración directamente.

systemctl cat [email protected]
systemctl cat [email protected]

Lea a liña WorkingDirectory e o argumento de configuración nesa saída, porque a unidade habilitada é o único que decide que ficheiro se carga. Un drop-in que engade --config a ExecStart gaña ao modelo mesmo cando a ruta do modelo parece correcta. Pida as rutas do fragmento e do drop-in cando queira saber se hai unha anulación local en xogo. Se ambos os roles se resolven nun só ficheiro, ten un único proceso que tenta ser servidor e cliente, e a opción posterior dese ficheiro gaña en silencio.

O transporte local e a carga reenviada tocan ganchos distintos

A conexión cifrada do servidor con cada usuario itinerante xérase no propio Pi, así que as súas respostas externas saen polo gancho de saída local. A conexión do cliente co seu par de subida tamén é saída xerada localmente, aínda que chega a unha rede remota. A carga reenviada é unha terceira categoría, e o núcleo só a fai coincidir despois de ter escollido xa un dispositivo de saída para o paquete.

Unha regra que coincide cunha interface de saída dentro dunha cadea de reenvío pode permitir ou descartar un paquete que o encamiñamento xa asignou a esa interface, pero nunca escolle a interface. Cando un host termina un túnel e orixina outro, a política que envía a carga do usuario ao túnel de subida e a política que protexe as respostas cifradas do propio Pi son decisións separadas. Casualidade aterran na mesma tarxeta de rede física, e por iso se confunden.

Esa distinción explica un medio fallo habitual. Os usuarios conéctanse, o handshake remata e o seu tráfico segue saíndo polo camiño equivocado, porque o handshake era local e a carga era reenviada, e só se probara unha das dúas cousas.

Unha ruta importada pode tragar as respostas aos seus usuarios

O axuste de seguridade do perfil do cliente decide que pode empurrar a parte de subida á táboa de encamiñamento do Pi, e unha redirección ampla é a opción que converte un host de dobre rol que funciona nun roto. Se a ruta empurrada cobre os enderezos públicos dos usuarios itinerantes, as respostas que o servidor xera cara a eles poden seguir a nova ruta cara ao túnel de subida en vez de saír pola capa base. A xente adoita confirmar que o túnel cara ao provedor aínda funciona e detense aí, porque ese tráfico é o transporte propio do túnel e segue fluíndo mentres todo o demais se comporta mal.

A política baseada na orixe ou nunha marca é a forma de manter os dous fluxos separados. A opción de marca de Linux de OpenVPN marca os paquetes cifrados propios do demo cunha marca de devasa, que unha regra de encamiñamento pode enviar despois a unha táboa dedicada. Os enderezos de orixe funcionan igual de ben cando as respostas externas do servidor sempre saen dun único enderezo de capa base. Calquera dos dous enfoques necesita rutas válidas na táboa que escolle e unha excepción para o punto final do provedor, ou o túnel mesmo deixa de subir.

Pregunte ao núcleo que camiño tomaría realmente unha resposta antes de escribir calquera regra. Os enderezos seguintes son marcadores de posición para un enderezo de capa base do Pi e o enderezo público dun usuario itinerante.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Verifique a división e despois deteña un rol á vez

Probe tres fluxos por separado, porque un handshake que funciona non demostra nada sobre os outros dous. Acepte unha nova conexión entrante, envíe unha aplicación permitida pola saída de subida e confirme que ambos os procesos seguen alcanzando os seus propios pares.

Despois deteña o rol de cliente e observe que conserva o rol de servidor. Esta é a forma máis barata de atopar unha regra de ruta ou de marca que estaba pensada para unha instancia e se aplicou a ambas.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

O que quere ver é o listener aínda vinculado, o dispositivo de túnel aínda presente e o rexistro libre de erros novos mentres o rol de cliente está detido. Se deter o cliente tamén corta as respostas do servidor aos usuarios existentes, os dous roles comparten algo que debería terse limitado a un deles. Anote que instancia, que ficheiro de configuración e que propietario de fluxo tocou cada cambio, porque a próxima persoa que depure este host, se non, repetirá o mesmo descubrimento desde cero.