Un reenviament de ports que ho abasta tot pot engolir el vostre oient de WireGuard

Una passarel·la pública ja executa WireGuard a UDP 51820, SSH a 22 i una aplicació que ha de ser accessible des d’internet. La regla temptadora reenvia cada port al parell i dona la feina per feta. En una passarel·la WireGuard, aquesta regla pot capturar el transport propi del túnel i deixar-vos fora de la màquina que el termina. Publicar és una decisió d’encaminament amb una excepció de pla de control, no una sola línia DNAT.

Entrada pública, entrada pel túnel: trieu-ne una

Publicar un servei crea un punt d’entrada nou a internet. No és el mateix que atorgar pertinença a la VPN a un parell, perquè el visitant no s’uneix mai al túnel i la passarel·la es converteix en la cara pública del backend. Aquesta distinció decideix el públic de la regla i el seu certificat.

Les interfícies administratives poques vegades pertanyen a aquesta posició. Una pàgina d’administració a què arriben clients VPN autoritzats manté la superfície d’atac dins del túnel i evita exposar un formulari d’inici de sessió a un escaneig arbitrari. Els punts finals d’aplicació públics encara necessiten el seu propi certificat TLS, autenticació i limitació de taxa; el salt WireGuard xifrat no protegeix la cama del visitant fins a la passarel·la.

Si el servei realment ha de ser públic, anoteu el nom d’amfitrió, el certificat que el cobreix i els rangs de visitants que hi han d’arribar. Aquests tres fets decideixen més endavant la forma de la regla i la política de filtratge. Qualsevol cosa fora d’ells és una ampliació d’abast en un oient públic.

Un port endins, un backend enfora

Feu servir un sol port públic i un sol servei de backend. En aquest exemple eth0 porta l’adreça pública 198.51.100.20, l’adreça de túnel de la passarel·la és 10.200.0.1 i el parell executa l’aplicació a 10.200.0.7. El TCP 9443 públic s’assigna al TCP 8443 del parell:

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

La regla SNAT coincideix amb el backend traduït i la destinació pública original, de manera que una altra connexió al mateix servei de backend queda fora d’aquest mapatge. També amaga l’adreça del visitant al parell, i aquest és el compromís que converteix un retorn encaminat que preserva l’origen en un disseny a part. La referència d’extensions d’iptables documenta tots dos objectius i les seves opcions de coincidència.

Encara cal habilitar el reenviament, i la cadena de filtratge necessita un permís per a la destinació i el port traduïts, més les respostes establertes. La cadena FORWARD veu la destinació traduïda després del DNAT, així que una regla escrita contra l’adreça pública no coincideix amb el paquet reenviat. Escriviu el permís contra la tupla del backend, no contra la pública.

El parell ha d’acceptar la connexió del servei des de l’adreça de túnel de la passarel·la i enviar la resposta de tornada pel túnel. El seu AllowedIPs ha d’autoritzar l’origen que realment rep, que amb traducció d’origen és l’adreça de túnel de la passarel·la, i una entrada àmplia 0.0.0.0/0 a cada parell no cal per a aquest disseny. El que fa caure el tràfic de retorn és un parell la llista del qual omet aquesta adreça, o un disseny que preserva l’origen i reenvia l’adreça pròpia del visitant, així que comproveu l’origen que el parell veu de debò, no el de la vostra regla.

Mantingueu els oients propis de la passarel·la fora de la regla

Canvieu la coincidència de port per una regla que cobreixi cada destinació TCP i UDP, i el socket WireGuard propi de la passarel·la hi cau a dins. La traducció de destinació passa abans que la màquina decideixi que un paquet és local, així que UDP 51820 pot acabar al parell en lloc del procés que manté cada connexió de parell. La regla es carrega amb èxit i el túnel mor, una fallada difícil de llegir des del costat del parell.

SSH, els agents de monitoratge i qualsevol altre servei allotjat a la passarel·la tenen la mateixa exposició. Una regla que ho reenvia tot no distingeix el pla de control de l’aplicació publicada, i el primer reinici després del canvi és quan el bloqueig es fa evident. La regla que ho abasta tot no avisa del servei que pren en silenci. Ho descobriu quan falla la connexió següent.

Si el reenviament ampli és realment necessari, reserveu els ports de control abans de la regla que ho abasta tot o feu servir una adreça pública separada per publicar. La segona opció és més neta perquè l’adreça de control conserva la seva pròpia política, però el proveïdor ha de lliurar aquesta adreça; afegir un registre DNS no n’assigna cap.

El reenviament ampli de TCP i UDP tampoc no és tots els protocols. ICMP, IPv6, la retroalimentació de MTU de camí i el transport exterior de la VPN necessiten la seva pròpia política, i una regla que cobreix TCP i UDP deixa aquests casos a la cadena per defecte.

Trieu el model abans d’escriure regles

Quatre formes cobreixen la majoria de publicacions de passarel·la, i l’elecció depèn de quants serveis executeu i de quant risc de pla de control podeu tolerar. La taula de sota les ordena de la més estreta a la més àmplia.

Comenceu amb el model estret encara que espereu més serveis més endavant. És el més fàcil d’auditar, i convertir un conjunt de regles estretes en una regla que ho abasta tot i revisada és més simple que descobrir quin oient ha capturat una regla àmplia. Trieu el model que trieu, manteniu les regles amb el propietari del tallafoc. Aplicar línies d’iptables al costat d’una configuració d’UFW o nftables que també gestiona les mateixes cadenes produeix una política que canvia segons l’ordre d’arrencada.

Proveu tant la publicació com el camí de control

Proveu des d’un client extern autoritzat amb el nom d’amfitrió aprovat i un certificat vàlid per a ell. Confirmeu quin backend ha respost i comproveu després que els ports públics no relacionats continuen denegats. Una comprovació de certificat desactivada no és una prova HTTPS superada, i una connexió que arriba al backend equivocat és pitjor que una de fallida.

Després d’això, verifiqueu la passarel·la mateixa: connecteu un parell WireGuard, obriu una sessió SSH i confirmeu que el monitoratge encara informa. El servei publicat pot funcionar mentre el pla de control està trencat, així que les dues comprovacions pertanyen a la mateixa finestra de canvi. Reinicieu un cop per demostrar que les regles es tornen a aplicar en l’ordre esperat, després retireu la publicació i confirmeu que la retirada coincideix de debò amb l’addició. Un conjunt gran d’addicions d’arrencada amb una retirada incompleta és com una prova temporal es converteix en una obertura permanent.