Un único servidor público para VPN e web: como repartir os papeis

Unha soa máquina pode responder ás tres necesidades á vez: rematar túneles, responder HTTPS e reenviar entre dúas LAN privadas. Se iso é sensato redúcese a tres cousas que pode resolver no papel: quen posúe o enderezo público, quen posúe cada par de porto e protocolo, e que proceso ten permiso para reenviar paquetes. Se acerta con elas, o servidor compartido non ten nada de especial. Se falla, pasará unha fin de semana cun servizo que arrinca limpo e nunca responde.

O que segue é un procedemento de decisión, non unha folla de construción. Cada paso remata coa comprobación que demostra que o papel que acaba de engadir está realmente illado.

Escolla o dono do enderezo antes dos portos

Un extremo de túnel e un servidor web poden compartir un kernel; compartir un enderezo, un porto e un protocolo ao mesmo tempo é o que falla. WireGuard adoita coller UDP 51820, OpenVPN colle UDP 1194 ou TCP 443, e un servidor web colle TCP 443. O par que doe é OpenVPN sobre TCP 443 xunto a HTTPS, porque ambos queren o mesmo socket e o kernel dállo a quen se vinculou primeiro. Só un demultiplexor diante, como sslh ou un proxy consciente de TLS, déixalles compartir ese porto, e engade un compoñente cuxo fallo parece exactamente un problema de firewall.

Mire os donos antes de cambiar nada: ss -lntup imprime o enderezo local, o porto e o proceso de cada socket en escoita. Dúas liñas que mostran 0.0.0.0:443 significan que o segundo servizo nunca se vinculou, por moi alegre que fose o seu script init. A ponte tamén move o dono. Cando eth0 se une a br0, a IP pasa a br0 e cada regra de firewall que nomea eth0 deixa de coincidir, así que vincule os servizos na ponte e confirme con ip -br addr.

A mesma regra de propiedade explica unha sorpresa que xorde coas máquinas virtuais. Un servidor de túnel que se executa dentro dun convidado na mesma LAN mantén o enderezo do convidado, así que as conexións dirixidas ao enderezo do propio host quedan no host e o túnel do convidado nunca as ve, diga o que diga o perfil do cliente.

Encamiñe entre as dúas LAN ou faga NAT dun lado

Dúas LAN que non se ven poden cada unha marcar o servidor público, que despois reenvía entre os túneles. Ese deseño encamiñado necesita tres cousas: reenvío activado, unha ruta cara a cada prefixo remoto e unha política de reenvío que deixe pasar o tránsito. sysctl -w net.ipv4.ip_forward=1 cobre a primeira, ip route add 10.20.0.0/24 dev wg1 a segunda, e unha liña de nftables como nft add rule inet filter forward iifname "wg0" oifname "wg1" accept a terceira.

O NAT de orixe é máis doado de engadir e máis difícil de depurar. O masquerading reescribe o enderezo do cliente, así que o lado remoto ve o concentrador en vez do host real, e as súas regras de acceso e rexistros deixan de ser útiles para a atribución. Cando as dúas redes son súas, encamiñe. Cando un lado pertence a un terceiro que non engadirá unha ruta de volta, o NAT é a opción que sae esta semana. En calquera caso, escriba o plan de enderezos, porque dúas /24 solapadas non as pode encamiñar ningunha configuración.

Nada do feito de servir de saída a Internet para un portátil impide que a mesma caixa remate túneles entrantes. Só o impiden os enderezos solapados, e por iso o plan de enderezos é o documento que importa.

Probe a división con dous papeis detidos

A proba útil é a resta: deteña dous papeis e confirme que o terceiro aínda responde. Unha solicitude web debe completarse co servizo de túnel caído, e un aperto de mans de túnel debe completarse co servidor web detido. Se ambos só funcionan cando todo está en marcha, ten unha dependencia accidental, como unha táboa de firewall compartida, unha ruta perdida ou un nome que apunta ao enderezo equivocado.

Tres comandos fan concreta esa proba. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ proba que o receptor local responde sen DNS externo, wg show no cliente proba que o aperto de mans se completou, e tcpdump -ni any port 51820 no concentrador separa un problema de encamiñamento dun problema de clave. Un aperto de mans que nunca aparece na captura morreu antes do host: firewall do provedor, enderezo público incorrecto ou unha regra NAT no camiño.

Repita a resta para as LAN reenviadas. Cun par desconectado, un ping a través do concentrador debe fallar; co par reconectado, o ping debe recuperarse sen tocar ningunha regra. Un ping que só se recupera despois de reiniciar o túnel apunta á política e non á accesibilidade, que é outra corrección.

Manteña o conxunto de regras lexible mentres resta papeis. nft list ruleset debería amosar unha regra de aceptación por dirección que realmente necesite, e unha cadea de reenvío que acepta todo non é separación, é unha demostración que funciona.

Liñas de acceso só IPv6 e servizos IPv4

Algunhas liñas de acceso só dan accesibilidade IPv6, e os servizos aínda se deben publicar sobre IPv4. O túnel en si viaxa pola familia que aínda pasa tráfico, mentres que o servizo publicado está nun enderezo dentro do túnel. Iso invirte a suposición habitual e rompe discretamente a monitorización: unha regra de firewall ou unha comprobación de tempo activo escrita para a ruta IPv4 vixía agora unha interface que non leva nada.

Probe cada familia por separado con curl -4 e curl -6, porque unha solicitude correcta non di nada sobre a ruta que non probou. A propiedade dos portos non cambia entre familias, pero o receptor si: ss -lntup lista os sockets IPv4 e IPv6 en liñas separadas, e 0.0.0.0:443 non cobre [::]:443 a menos que o proceso pedise un socket de dobre pila.

Un servizo que responde nunha familia e rexeita na outra adoita ser un problema de receptor, non de encamiñamento. Antes de dar por rematado o deseño, confirme que cada papel posúe o seu propio enderezo ou porto, que o reenvío está activado e permitido, e que cada papel aínda responde cos outros dous detidos.