Onde vai o NAT da VPN en before.rules de UFW e como probalo

Unha regra NAT que funciona ao escribila nun shell falla ao pegala en before.rules, porque ese ficheiro non é un script. É un documento en formato de restauración con seccións de táboa, declaracións de cadea e unha marca COMMIT por cada táboa. Unha liña no lugar equivocado ou aborta toda a restauración ou descarta en silencio regras que vostede cría presentes. O procedemento seguinte coloca o fragmento onde o marco o espera e demostra o resultado antes da próxima recarga.

Un comando de shell non é un ficheiro de restauración

Unha liña que comeza por iptables -t nat é unha instrución para o binario iptables, mentres que o ficheiro que le UFW é a descrición dun conxunto de regras completo. A diferenza non é cosmética: o formato de restauración debe saber en que táboa está, que cadeas existen e onde remata a táboa. Un comando pegado nese documento é ou un erro de sintaxe ou, peor, unha regra adherida á táboa equivocada. O marco carga estes ficheiros mediante ferramentas de restauración precisamente porque son declarativos e non secuenciais.

O documento tamén se carga como un todo, así que unha sección mal formada pode impedir que se aplique o resto do ficheiro. Por iso un pequeno erro nun fragmento NAT leva consigo as regras de filtrado, e así é como un cambio de cortafuegos se converte nunha caída.

Pon o fragmento dentro da sección de táboa existente

Un fragmento NAT ten unha forma, e a forma importa máis que o texto da regra que contén. A cabeceira da táboa abre a sección, as declaracións de cadea establecen os contadores, seguen as regras e un COMMIT pecha a sección.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

O grupo e a interface de arriba son marcadores para os seus; a estrutura é a parte que paga a pena copiar. Se o ficheiro xa contén unha sección *nat, engada a regra dentro desa sección en lugar de abrir unha segunda, porque o formato espera un COMMIT por táboa e dúas seccións para a mesma táboa son unha reparación agardando a ocorrer. Manteña intactas as definicións de cadea da distribución, incluídas as que o provedor engadiu para a súa propia integración. O manual do marco UFW documenta os ficheiros before, user e after xunto co requisito dun COMMIT coincidente.

Se o ficheiro resulta estar baleiro, non o encha cun tutorial. Confirme que paquete o posúe e cal é a política activa en realidade, porque un ficheiro persistente baleiro non demostra que o núcleo non teña regras, e un conxunto de regras cargado non demostra que a próxima recarga teña un ficheiro completo que ler. Restaure primeiro a liña base admitida e despois volva aplicar os cambios do sitio por riba.

Proba o candidato sen aplicalo

A ferramenta de restauración pode analizar e construír un conxunto de regras sen aplicalo, que é a proba máis barata dispoñible. Execútea sobre unha copia protexida en lugar do ficheiro activo, e lea o texto do erro en vez de só o estado de saída. Un fallo de análise nomea unha liña e normalmente unha táboa, o que é máis do que lle dirá unha recarga fallida.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Superar esa comprobación demostra que o documento se analiza e nada máis. Non demostra que o candidato siga contendo todas as cadeas das que depende UFW, que só permita as fontes que pretendía ou que a administración remota siga sendo accesible. Son revisións separadas, e a última merece unha segunda sesión aberta antes de comezar.

Escolla a ferramenta que corresponda ao backend instalado e á familia de enderezos. Un host que executa o backend nft a través da capa de compatibilidade necesita o comando correspondente, e as regras IPv6 viven nun ficheiro completamente distinto.

Mantén separados o reenvío, o NAT e a política de acceso

A tradución de orixe resolve un problema de enderezo e non concede nada. O reenvío é un permiso aparte que controlan un sysctl e a táboa de filtrado, e é o que a xente esquece cando un túnel encamiña pero non pasa tráfico. A política de acceso é unha terceira decisión sobre que fontes poden chegar a que servizos, e ningunha regra NAT a expresa. Manter os tres separados é o que fai que un fallo sexa diagnosticable en lugar dun único síntoma vago.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Lea esas tres saídas xuntas, non unha a unha. Unha regra masquerade co reenvío desactivado produce un cliente que se conecta e non chega a nada, o que desde o lado do cliente parece exactamente un fallo de encamiñamento e envía a xente ao ficheiro equivocado. A táboa de filtrado é tamén onde se agocha un accept demasiado amplo, así que revise a súa política por defecto mentres está alí.

Verifica unha recarga, unha denegación e unha perda de VPN

Tres observacións compoñen unha proba de aceptación completa: a recarga ten éxito, unha operación de cliente permitida funciona e unha petición que debería rexeitarse rexéitase de verdade. A terceira é a que se omite, e é a única evidencia de que a política fai algo.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Despois probe o fallo para o que deseñou. Deixe caer o túnel e observe que fai o host, porque unha política que só funciona mentres a VPN está activa é unha política cunha dependencia non declarada. Recargue unha vez máis despois para demostrar que é o ficheiro, e non un estado de execución residual, o que produce o resultado funcional.

O NAT de IPv4 non di nada sobre IPv6, así que indique a cobertura prevista para ambas as familias na mesma nota que a regra. O obxectivo é unha política xestionada coherente, e un fragmento que resultou analizable non é proba dela.