Dos llocs, una subxarxa, un concentrador WireGuard: feu-ho funcionar

Els dos llocs fan servir el mateix rang de LAN, i la superposició no és el que trenca realment el disseny. El concentrador ha de triar un lloc només amb l'adreça de destinació, i dues destinacions idèntiques no li donen res per triar. Renumerar una oficina que funciona per satisfer un túnel sol ser un intercanvi pitjor que donar a cada servei publicat una adreça diferent que el túnel pugui transportar. El disseny de sota publica un servei HTTPS per lloc i res més.

Per què la superposició no és el problema real

WireGuard reenvia per destinació: les AllowedIPs d'un peer decideixen quin peer rep un paquet. Dos peers no poden anunciar tots dos 10.10.7.0/24 sense que un d'ells guanyi totes les consultes. Això és una propietat de la taula de peers i no del túnel, i per això la solució aquí és un pla d'adreces i no un truc d'encaminament.

El pla és deixar d'anunciar la LAN del tot. Anuncieu en canvi un àlies per servei, una adreça per lloc, i deixeu que la passarel·la de cada lloc tradueixi aquest àlies a la seva aplicació real.

L'usuari encamina dues adreces úniques, no veu mai el prefix ambigu i no canvia res en cap de les dues oficines. Això també diu la frontera amb honestedat: publiqueu un servei HTTPS des de cada lloc, no fusiona dues xarxes. Les regles que segueixen es mantenen petites perquè l'afirmació és estreta. Una afirmació més àmplia necessitaria regles més àmplies, i així és com aquests dissenys es compliquen.

Doneu a cada lloc un àlies que l'usuari pugui encaminar

Trieu adreces d'un rang que no entri en conflicte amb res a la màquina de l'usuari, al concentrador ni a cap de les dues LAN. Aquí el concentrador és 10.66.0.1, l'usuari és 10.66.0.10, les passarel·les són 10.66.0.21 i 10.66.0.22, i els dos àlies són 10.77.1.20 i 10.77.2.20. El concentrador publica cada àlies a través del peer que el posseeix, així que un paquet sortint adreçat a un àlies només pot sortir pel lloc corresponent:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

El costat de l'usuari només necessita els dos àlies, cosa que manté la configuració del client lliure dels dos prefixos de LAN. Res en aquesta configuració no esmenta cap de les LAN reals:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Cada passarel·la anuncia el concentrador i l'origen de l'usuari, res més, així que un lloc mai no aprèn la LAN de l'altre lloc. El keepalive manté una assignació NAT a l'enllaç ascendent del lloc; no autoritza trànsit, i el tallafoc encara decideix què s'admet. Copiar la configuració d'una passarel·la a l'altra és correcte sempre que la clau privada, l'adreça d'interfície i l'àlies canviïn tots.

Què ha de permetre el concentrador entre dos dels seus peers

El concentrador reenvia paquets entre dos dels seus propis peers, cosa que és una decisió de la cadena forward i no una decisió d'entrada. Activeu el reenviament IPv4 amb el mecanisme habitual de la plataforma i després permeteu exactament les parelles que el disseny necessita.

La regla de sota permet a l'usuari un àlies i un port, i permet el trànsit de tornada mitjançant el seguiment de connexions. Descarta tota la resta al camí forward, i aquest és el punt:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

Val la pena esmentar dos detalls perquè provoquen fallades silencioses. Un accept en una cadena base no anul·la un drop en una altra, així que fusiona-ho amb la política existent en lloc de carregar-ho al costat. I l'adreça d'origen identifica el dispositiu, no la persona; manteniu l'autenticació de l'aplicació separada de l'admissió a la xarxa.

On un àlies es converteix en una adreça real

El lloc A rep una petició per a 10.77.1.20, reescriu la destinació a l'aplicació real i reescriu l'origen a la seva pròpia adreça de LAN perquè la resposta pugui tornar sense una ruta cap al túnel. Fer les dues traduccions en un sol lloc manté la resta de la xarxa ignorant de l'àlies. Les regles de sota són tot el mecanisme:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

La política forward del lloc A ha d'admetre després el flux traduït de la interfície del túnel a la interfície de LAN, més la direcció de tornada. El hook forward veu la destinació després de la traducció de destinació i abans de la reescriptura d'origen, i per això la regla anomena l'adreça de l'aplicació real. Llegiu aquests dos hooks en aquest ordre sempre que una regla sembli no coincidir amb res. Una regla forward escrita contra l'àlies no pot coincidir mai, perquè l'àlies ja no existeix en aquest hook.

El lloc B repeteix això amb el seu propi àlies i la seva pròpia clau. No ha de reutilitzar la clau privada del lloc A, perquè dos peers que comparteixen una identitat són un error de configuració difícil de veure i fàcil de crear copiant un fitxer. Manteniu els dos documents de passarel·la idèntics excepte els valors que han de diferir, perquè la diferència destaqui en la revisió. Un fitxer copiat és l'origen habitual d'aquesta fallada.

La reescriptura d'origen té un cost. L'aplicació veu la passarel·la com el seu client, així que els seus registres ja no mostren quin usuari s'ha connectat. Manteniu el rastre d'auditoria de la passarel·la i no debiliteu l'inici de sessió de l'aplicació per compensar una identitat de xarxa que la traducció ha eliminat.

Com demostrar que tots dos noms publicats responen

Doneu a cada àlies un nom DNS i configureu l'aplicació i el certificat per a aquest nom, perquè la traducció no reescriu redireccions ni URL absolutes incrustades. Feu servir un nom per lloc perquè una discrepància de certificat no es pugui confondre mai amb una fallada d'encaminament.

Proveu des del client real, confirmeu quin lloc ha respost i proveu també un port no autoritzat. Feu servir connexions noves després de qualsevol canvi de NAT, perquè l'estat establert conserva l'assignació antiga:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

Un àlies buit o inesperat a la primera comanda vol dir que la selecció de peer és incorrecta abans que cap regla de tallafoc importi. Si l'àlies és correcte i el nom encara falla, el problema s'ha traslladat a DNS i certificats. Quan els dos noms responen i el tercer port continua tancat, el disseny fa el que afirma: dos serveis publicats estretament, no dues LAN fusionades.