Dous sitios, unha subrede, un concentrador WireGuard: fagamos que funcione

Os dous sitios usan o mesmo rango de LAN, e a superposición non é o que realmente rompe o deseño. O concentrador debe elixir un sitio usando só o enderezo de destino, e dous destinos idénticos non lle dan nada con que elixir. Renumerar unha oficina que funciona para satisfacer un túnel adoita ser un peor intercambio que darlle a cada servizo publicado un enderezo distinto que o túnel poida transportar. O deseño de abaixo publica un servizo HTTPS por sitio e nada máis.

Por que a superposición non é o problema real

WireGuard reenvía por destino: as AllowedIPs dun peer deciden que peer recibe un paquete. Dous peers non poden anunciar ambos 10.10.7.0/24 sen que un deles gañe todas as buscas. Iso é unha propiedade da táboa de peers e non do túnel, por iso a solución aquí é un plan de enderezos e non un truco de encamiñamento.

O plan é deixar de anunciar a LAN por completo. Anuncie no seu lugar un alias por servizo, un enderezo por sitio, e deixe que a pasarela de cada sitio traduza ese alias á súa aplicación real.

O usuario encamiña dous enderezos únicos, nunca ve o prefixo ambiguo, e nada cambia en ningunha das dúas oficinas. Iso tamén di a fronteira con honestidade: está a publicar un servizo HTTPS desde cada sitio, non fusionando dúas redes. As regras que seguen mantéñense pequenas porque a afirmación é estreita. Unha afirmación máis ampla necesitaría regras máis amplas, e así é como estes deseños se complican.

Déalle a cada sitio un alias que o usuario poida encamiñar

Escolla enderezos dun rango que non entre en conflito con nada na máquina do usuario, o concentrador nin ningunha das dúas LAN. Aquí o concentrador é 10.66.0.1, o usuario é 10.66.0.10, as pasarelas son 10.66.0.21 e 10.66.0.22, e os dous alias son 10.77.1.20 e 10.77.2.20. O concentrador publica cada alias a través do peer que o posúe, así que un paquete saínte dirixido a un alias só pode saír polo sitio correspondente:

[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

O lado do usuario só necesita os dous alias, o que mantén a configuración do cliente libre de ambos prefixos de LAN. Nada nesa configuración menciona ningunha das LAN reais:

[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 pasarela anuncia o concentrador e a orixe do usuario, nada máis, así que un sitio nunca aprende a LAN do outro. O keepalive mantén unha asignación NAT no enlace ascendente do sitio; non autoriza tráfico, e a devasa segue decidindo que se admite. Copiar a configuración dunha pasarela á outra está ben sempre que a clave privada, o enderezo de interface e o alias cambien todos.

Que debe permitir o concentrador entre dous dos seus peers

O concentrador reenvía paquetes entre dous dos seus propios peers, o que é unha decisión da cadea forward e non unha decisión de entrada. Active o reenvío IPv4 mediante o mecanismo habitual da plataforma e despois permita exactamente os pares que o deseño necesita.

A regra de abaixo permite ao usuario un alias e un porto, e permite o tráfico de volta mediante o seguimento de conexións. Descarta todo o demais na ruta forward, e ese é o punto:

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

Paga a pena sinalar dous detalles porque causan fallos silenciosos. Un accept nunha cadea base non anula un drop noutra, así que fusione isto coa política existente en lugar de cargalo ao lado. E o enderezo de orixe identifica o dispositivo, non a persoa; manteña a autenticación da aplicación separada da admisión na rede.

Onde un alias se converte nun enderezo real

O sitio A recibe unha petición para 10.77.1.20, reescribe o destino á aplicación real e reescribe a orixe ao seu propio enderezo de LAN para que a resposta poida volver sen unha ruta cara ao túnel. Facer as dúas traducións nun só lugar mantén o resto da rede ignorante do alias. As regras de abaixo son todo o mecanismo:

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

A política forward do sitio A debe entón admitir o fluxo traducido desde a interface do túnel á interface de LAN, máis a dirección de volta. O hook forward ve o destino despois da tradución de destino e antes da reescritura de orixe, por iso a regra nomea o enderezo da aplicación real. Lea eses dous hooks nesa orde sempre que unha regra pareza non coincidir con nada. Unha regra forward escrita contra o alias nunca pode coincidir, porque o alias xa non existe nese hook.

O sitio B repite isto co seu propio alias e a súa propia clave. Non debe reutilizar a clave privada do sitio A, porque dous peers que comparten unha identidade son un erro de configuración difícil de ver e fácil de crear copiando un ficheiro. Manteña ambos documentos de pasarela idénticos agás os valores que deben diferir, para que a diferenza destaque na revisión. Un ficheiro copiado é a orixe habitual desa falla.

A reescritura de orixe ten un custo. A aplicación ve a pasarela como o seu cliente, así que os seus rexistros xa non mostran que usuario se conectou. Conserve o rastro de auditoría da pasarela, e non debilite o inicio de sesión da aplicación para compensar unha identidade de rede que a tradución eliminou.

Como demostrar que ambos nomes publicados responden

Déalle a cada alias un nome DNS e configure a aplicación e o certificado para ese nome, porque a tradución non reescribe redireccións nin URL absolutas incrustadas. Use un nome por sitio para que unha discrepancia de certificado nunca se confunda cunha falla de encamiñamento.

Probe desde o cliente real, confirme que sitio respondeu e probe tamén un porto non autorizado. Use conexións novas despois de calquera cambio de NAT, xa que o estado establecido conserva a asignación 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 alias baleiro ou inesperado no primeiro comando significa que a selección de peer é incorrecta antes de que importe calquera regra de devasa. Se o alias é correcto e o nome segue fallando, o problema trasladouse a DNS e certificados. Unha vez que ambos nomes responden e o terceiro porto permanece pechado, o deseño fai o que afirma: dous servizos publicados de forma estreita, non dúas LAN fusionadas.