As regras que encamiñan todos os portos poden engulir o teu listener WireGuard

Un gateway público xa executa WireGuard en UDP 51820, SSH no 22 e unha aplicación que debe ser accesible desde internet. A regra tentadora encamiña todos os portos ao peer e dá o traballo por rematado. Nun gateway WireGuard esa regra pode capturar o transporte do propio túnel e deixarte fóra da máquina que o termina. Publicar é unha decisión de encamiñamento cunha excepción para o plano de control, non unha única liña DNAT.

Entrada pública ou entrada polo túnel: escolla unha

Publicar un servizo crea un novo punto de entrada en internet. Non é o mesmo que conceder pertenza á VPN a un peer, porque o visitante nunca entra no túnel e o gateway convértese na cara pública do backend. Esa distinción decide o público da regra e o seu certificado.

As interfaces administrativas raramente pertencen a esa posición. Unha páxina de administración alcanzada por clientes VPN autorizados mantén a superficie de ataque dentro do túnel e evita expor un formulario de acceso a exploracións arbitrarias. Os puntos finais públicos da aplicación seguen necesitando o seu propio certificado TLS, autenticación e limitación de taxa; o salto WireGuard cifrado non protexe a parte do visitante ata o gateway.

Se o servizo realmente debe ser público, anota o nome de host, o certificado que o cobre e os rangos de visitantes que deben chegar a el. Eses tres feitos deciden despois a forma da regra e a política de filtrado. Todo o que quede fóra é unha ampliación do ámbito nun listener público.

Un porto dentro, un backend fóra

Use un único porto público e un único servizo backend. Neste exemplo eth0 leva o enderezo público 198.51.100.20, o enderezo do túnel do gateway é 10.200.0.1 e o peer executa a aplicación en 10.200.0.7. O porto público TCP 9443 mapéase ao TCP 8443 do peer:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

A regra SNAT coincide co backend traducido e co destino público orixinal, así que outra conexión ao mesmo servizo backend queda fóra deste mapeado. Tamén agocha o enderezo do visitante do peer, e ese é o compromiso que fai que unha volta encamiñada con preservación da orixe sexa un deseño aparte. A referencia das extensións de iptables documenta ambos os dous obxectivos e as súas opcións de coincidencia.

O encamiñamento aínda debe estar activado, e a cadea de filtro precisa un permiso para o destino e o porto traducidos máis as respostas establecidas. A cadea FORWARD ve o destino traducido despois do DNAT, así que unha regra escrita contra o enderezo público non coincide co paquete encamiñado. Escribe o permiso contra a tupla do backend, non contra a pública.

O peer debe aceptar a conexión do servizo desde o enderezo do túnel do gateway e enviar a resposta de volta polo túnel. O seu AllowedIPs debe autorizar a orixe que realmente recibe, que baixo tradución de orixe é o enderezo do túnel do gateway, e unha entrada ampla 0.0.0.0/0 en cada peer non é necesaria para este deseño. O que bota o tráfico de volta é un peer cuxa lista omite ese enderezo, ou un deseño con preservación da orixe que encamiña no seu lugar o enderezo do propio visitante, así que comproba a orixe que o peer ve de verdade, non a da túa regra.

Manteña os listeners do propio gateway fóra da regra

Substitúa a coincidencia de porto por unha regra que cubra cada destino TCP e UDP, e o socket WireGuard do propio gateway cae dentro dela. A tradución de destino ocorre antes de que a máquina decida que un paquete é local, así que o UDP 51820 pode acabar no peer en vez de no proceso que mantén todas as conexións dos peers. A regra cárgase sen erro e o túnel morre, un fallo difícil de ler desde o lado do peer.

SSH, os axentes de monitorización e calquera outro servizo aloxado no gateway teñen a mesma exposición. Unha regra que encamiña todo non distingue o plano de control da aplicación publicada, e o primeiro reinicio após o cambio é o momento no que o bloqueo se fai evidente. A regra que captura todo non avisa do servizo que asume en silencio. Descóbreso cando falla a conexión seguinte.

Se o encamiñamento amplo é realmente necesario, reserve os portos de control antes da regra que captura todo ou use un enderezo público separado para a publicación. A segunda opción é máis limpa porque o enderezo de control mantén a súa propia política, pero o provedor debe entregar ese enderezo; engadir un rexistro DNS non aloca ningún.

O encamiñamento amplo de TCP e UDP tampouco son todos os protocolos. ICMP, IPv6, a retroalimentación path-MTU e o transporte externo da VPN precisan a súa propia política, e unha regra que cobre TCP e UDP deixa eses casos á cadea predeterminada.

Escolla o modelo antes de escribir as regras

Catro formas cobren a maioría das publicacións desde un gateway, e a escolla depende de cantos servizos executa e de canto risco no plano de control pode tolerar. A táboa de abaixo ordénaas da máis estreita á máis ampla.

Comece polo modelo estreito aínda que espere máis servizos despois. É o máis doado de auditar, e converter un conxunto de regras estreitas nunha regra que captura todo xa revisada é máis simple que descubrir que listener capturou unha regra ampla. Calquera modelo que escolla, manteña as regras co dono da devasa. Aplicar liñas de iptables xunto a unha configuración de UFW ou nftables que tamén xestiona as mesmas cadeas produce unha política que cambia segundo a orde de arranque.

Demostre a publicación e a ruta de control

Probe desde un cliente externo autorizado usando o nome de host aprobado e un certificado válido para el. Confirme que backend respondeu e despois comprobe que os portos públicos non relacionados seguen negados. Unha comprobación de certificado desactivada non é unha proba HTTPS superada, e unha conexión que chega ao backend incorrecto é peor ca unha fallida.

Despois verifique o propio gateway: conecte un peer WireGuard, abra unha sesión SSH e confirme que a monitorización segue informando. O servizo publicado pode funcionar mentres o plano de control está roto, así que ambas as dúas comprobacións pertencen á mesma xanela de cambio. Reinicie unha vez para demostrar que as regras se reaplican na orde esperada, despois retire a publicación e confirme que a retirada corresponde de verdade á adición. Un conxunto grande de adicións no arranque cunha limpeza incompleta é o xeito no que unha proba temporal se converte nunha abertura permanente.