Delimite a regra SNAT de OpenVPN antes de que rompa nginx

Dous fallos chegan sempre do mesmo tipo de host. No primeiro, os clientes autentícanse e despois non alcanzan nada máis aló do túnel. No segundo, a VPN sobe e o propio sitio web do servidor deixa de responder, que é o máis alarmante porque parece dano colateral. Nun VPS baseado en contedores ambos adoitan remontarse á mesma lista curta de comprobacións, e a orde importa: primeiro o dispositivo, segundo a tradución, terceiro o alcance.

Confirme que o contedor pode crear un dispositivo tun

Nada máis importa se a interface do túnel non pode existir. Comprobe que /dev/net/tun está presente e que a creación dun dispositivo de proba ten éxito, porque moitos provedores desactivan tun dentro dos contedores por defecto. Ningunha cantidade de traballo con firewall compensa un dispositivo que nunca se creou.

Se falta o dispositivo, só o host ou o provedor poden habilitalo. A miúdo un plan distinto é máis barato que un fío de soporte aberto que dura unha semana. Confírmeo antes de ler unha soa liña do rexistro de OpenVPN. Do contrario pasará a velada axustando regras que nunca verán un paquete.

Decida que fai MASQUERADE nesta interface

Nunha máquina virtual corrente a regra de saída habitual é POSTROUTING MASQUERADE da interface principal. Nun contedor OpenVZ o dispositivo visible adoita ser venet0, unha interface virtual xestionada polo host e non unha NIC encamiñada, e MASQUERADE non sempre se comporta alí como supoñen os titoriais.

A forma viable é unha tradución explícita ao enderezo que os clientes xa alcanzan, co reenvío permitido en ambos os sentidos. Substituír o pool da configuración do servidor importa tanto como substituír o enderezo. Lea cada liña antes de pegala.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sen as regras de reenvío a tradución segue ocorrendo e o kernel segue negándose a reenviar. Esa combinación produce o estado confuso no que os contadores da regra NAT soben mentres o cliente non recibe nada. As dúas liñas FORWARD tamén deben ir antes de calquera regra drop ampla na mesma cadea. A orde é parte da configuración, non un detalle de implementación.

Delimite a regra a un pool e unha interface

O segundo síntoma ten outra causa: unha regra POSTROUTING sen restrición de orixe nin de saída. Tal regra reescribe cada paquete que sae do host.

Os servizos que dependen da orixe orixinal compórtanse mal. Un servidor web detrás dun proxy local pode deixar de responder, e reinicialo non cambia nada porque a regra segue no camiño. O tráfico que o host envía ao seu propio enderezo público tamén se ve afectado, por iso o fallo pode parecer un problema de DNS ou de certificado en lugar dun de firewall. A regra case con seguridade engadiuse para arranxar o primeiro síntoma.

A solución é estreitar a coincidencia ao pool do túnel e á interface de saída, e logo engadir unha regra por pool en lugar de ampliar unha soa regra para cubrir varias.

Faga persistentes as regras e descubra quen máis é o seu dono

As regras engadidas a man desaparecen ao reiniciar, así que gárdeas con iptables-save ou adminístreas mediante netfilter-persistent onde estea instalado. Confirme que a restauración se executa antes de que arrinque OpenVPN. Despois reinicie unha vez a propósito en lugar de descubrir o oco durante un incidente.

Nun host de contedores, confirme tamén que o ficheiro de persistencia vive en almacenamento de contedor escribible e que o provedor non substitúe o filtrado ao arrincar. Algunhas plataformas xestionan a política fóra do contedor, onde as regras locais ou se ignoran ou chocan coas do propio host.

Verifique con contadores e un fluxo capturado

Desde un cliente conectado, comprobe o enderezo público que informa un servizo externo. Se coincide co enderezo do servidor, a tradución funciona; se non, o paquete sae por outro camiño ou non sae en absoluto. Despois probe tanto un servizo aloxado no servidor como un na internet pública, porque toman camiños distintos polo mesmo conxunto de regras.

No servidor, lea os contadores de paquetes das regras NAT e FORWARD con iptables -t nat -L -v -n e observe un fluxo nunha captura. Se o enderezo do cliente aparece na captura e non segue ningunha resposta, o oco está no camiño de volta ou no filtrado do provedor, non no perfil do cliente. Compare a orixe capturada co enderezo ao que traduce a regra, porque unha discrepancia significa que outra regra coincidiu primeiro. Un só fluxo observado resolve máis que unha páxina de lectura de configuración.

Manteña o pool, o enderezo traducido e o nome da interface xuntos no rexistro de cambios. Unha regra correcta para un pool traduce mal a seguinte.