Un sol amfitrió públic per a VPN i web: com separar els papers

Una sola màquina pot satisfer les tres necessitats alhora: tancar túnels, respondre HTTPS i reenviar entre dues LAN privades. Si això és sensat depèn de tres coses que podeu decidir sobre el paper: qui posseeix l’adreça pública, qui posseeix cada parell de port i protocol i a quin procés se li permet reenviar paquets. Si ho encerteu, l’amfitrió compartit no té res d’especial. Si ho feu malament, passareu un cap de setmana amb un servei que arrenca net i no respon mai.

El que segueix és un procediment de decisió, no un full de construcció. Cada pas acaba amb la comprovació que demostra que el paper que acabeu d’afegir està realment aïllat.

Trieu el propietari de l’adreça abans que els ports

Un extrem de túnel i un servidor web poden compartir un nucli; compartir una adreça, un port i un protocol alhora és el que falla. WireGuard normalment ocupa UDP 51820, OpenVPN ocupa UDP 1194 o TCP 443, i un servidor web ocupa TCP 443. La parella que fa mal és OpenVPN sobre TCP 443 al costat d’HTTPS, perquè tots dos volen el mateix sòcol i el nucli el lliura a qui s’hi va enllaçar primer. Només un demultiplexor al davant, com ara sslh o un proxy que entengui TLS, els permet compartir aquell port, i afegeix un component el falliment del qual sembla exactament un problema de tallafocs.

Mireu els propietaris abans de canviar res: ss -lntup imprimeix l’adreça local, el port i el procés de cada sòcol que escolta. Dues files amb 0.0.0.0:443 volen dir que el segon servei no es va enllaçar mai, per molt alegre que fos el seu script d’inici. El bridge també mou el propietari. Quan eth0 s’uneix a br0, la IP es mou a br0 i cada regla de tallafocs que anomena eth0 deixa de coincidir, així que enllaceu els serveis al bridge i confirmeu-ho amb ip -br addr.

La mateixa regla de propietat explica una sorpresa que apareix amb les màquines virtuals. Un servidor de túnel que s’executa dins d’un convidat a la mateixa LAN conserva l’adreça del convidat, així que les connexions dirigides a l’adreça pròpia de l’amfitrió es queden a l’amfitrió i el túnel del convidat no les veu mai, digui el que digui el perfil del client.

Encamineu entre les dues LAN o feu NAT d’una banda

Dues LAN que no es veuen poden marcar cadascuna l’amfitrió públic, que després reenvia entre els túnels. Aquest disseny encaminat necessita tres coses: reenviament activat, una ruta cap a cada prefix remot i una política de reenviament que deixi passar el trànsit. sysctl -w net.ipv4.ip_forward=1 cobreix la primera, ip route add 10.20.0.0/24 dev wg1 la segona, i una línia d’nftables com nft add rule inet filter forward iifname "wg0" oifname "wg1" accept la tercera.

El NAT d’origen és més fàcil d’afegir i més difícil de depurar. L’emmascarament reescriu l’adreça del client, així que la banda remota veu el concentrador i no l’amfitrió real, i les seves regles d’accés i registres deixen de ser útils per atribuir. Quan les dues xarxes són vostres, encamineu. Quan una banda pertany a un tercer que no afegirà una ruta de tornada, el NAT és l’opció que es lliura aquesta setmana. De qualsevol manera, escriviu el pla d’adreces, perquè dues /24 superposades no es poden encaminar amb cap quantitat de configuració.

Res del fet de fer de sortida a internet per a un portàtil no impedeix que la mateixa caixa tanqui túnels entrants. Només ho fan les adreces superposades, i per això el pla d’adreces és el document que importa.

Proveu la separació amb dos papers aturats

La prova útil és la sostracció: atureu dos papers i confirmeu que el tercer encara respon. Una petició web hauria de completar-se amb el servei de túnel aturat, i un handshake de túnel hauria de completar-se amb el servidor web aturat. Si tots dos només funcionen quan tot funciona, teniu una dependència accidental: una taula de tallafocs compartida, una ruta esgarriada o un nom que apunta a l’adreça equivocada.

Tres ordres fan concret aquesta prova. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ demostra que l’oient local respon sense DNS extern, wg show al client demostra que el handshake s’ha completat, i tcpdump -ni any port 51820 al concentrador separa un problema d’encaminament d’un problema de clau. Un handshake que no apareix mai a la captura va morir abans de l’amfitrió: tallafocs del proveïdor, adreça pública equivocada o una regla de NAT pel camí.

Repetiu la sostracció per a les LAN reenviades. Amb un parell desconnectat, un ping a través del concentrador hauria de fallar; amb ell reconnectat, el ping hauria de recuperar-se sense tocar cap regla. Un ping que només es recupera després de reiniciar el túnel assenyala la política i no l’abast, i això és una correcció diferent.

Manteniu el conjunt de regles llegible mentre sostreieu papers. nft list ruleset hauria de mostrar una regla d’acceptació per direcció que realment necessiteu, i una cadena forward que ho accepta tot no és separació, és una demostració que funciona.

Línies d’accés només IPv6 i serveis IPv4

Algunes línies d’accés només donen abast IPv6, i els serveis encara s’han de publicar sobre IPv4. El túnel mateix viatja per la família que encara passa trànsit, mentre que el servei publicat se situa en una adreça dins del túnel. Això inverteix la suposició habitual i trenca el monitoratge sense soroll: una regla de tallafocs o una comprovació d’activitat escrita per al camí IPv4 ara vigila una interfície que no porta res.

Proveu cada família pel seu compte amb curl -4 i curl -6, perquè una petició correcta no diu res sobre el camí que no heu provat. La propietat del port no canvia entre famílies, però l’oient sí: ss -lntup llista els sòcols IPv4 i IPv6 com a files separades, i 0.0.0.0:443 no cobreix [::]:443 tret que el procés hagi demanat un sòcol de doble pila.

Un servei que respon en una família i refusa l’altra sol ser un problema d’oient, no d’encaminament. Abans de donar el disseny per acabat, confirmeu que cada paper posseeix la seva adreça o port, que el reenviament està activat i permès i que cada paper encara respon amb els altres dos aturats.