To steder, ett subnet, én WireGuard-hub: få det til å virke

Begge stedene bruker samme LAN-område, og overlappen er ikke det som egentlig ødelegger designet. Huben må velge et sted kun ut fra destinasjonsadressen, og to identiske destinasjoner gir den ingenting å velge etter. Å omnummerere et kontor som fungerer for å tilfredsstille en tunnel er vanligvis en dårligere handel enn å gi hver publisert tjeneste en egen adresse som tunnelen kan bære. Designet nedenfor publiserer én HTTPS-tjeneste per sted og ingenting annet.

Hvorfor overlappen ikke er det egentlige problemet

WireGuard videresender etter destinasjon: AllowedIPs til en peer avgjør hvilken peer en pakke går til. To peer kan ikke begge annonsere 10.10.7.0/24 uten at en av dem vinner hvert oppslag. Det er en egenskap ved peer-tabellen og ikke ved tunnelen, derfor er løsningen her en adresseplan og ikke et rutetriks.

Planen er å slutte å annonsere LAN-et helt. Annonser i stedet et alias per tjeneste, én adresse per sted, og la gatewayen på hvert sted oversette aliaset til sin virkelige applikasjon.

Brukeren ruter to unike adresser, ser aldri det tvetydige prefikset, og ingenting endres i noen av de to kontorene. Det sier også grensen ærlig: du publiserer én HTTPS-tjeneste fra hvert sted, ikke slår sammen to nettverk. Reglene nedenfor holder seg små fordi utsagnet er smalt. Et bredere utsagn ville trenge bredere regler, og det er slik disse designene blir kompliserte.

Gi hvert sted et alias som brukeren kan rute

Velg adresser fra et område som ikke kolliderer med noe på brukerens maskin, huben eller noen av de to LAN-ene. Her er huben 10.66.0.1, brukeren 10.66.0.10, gatewayene 10.66.0.21 og 10.66.0.22, og de to aliasene 10.77.1.20 og 10.77.2.20. Huben publiserer hvert alias gjennom peeren som eier det, slik at en utgående pakke adressert til ett alias bare kan gå ut gjennom det samsvarende stedet:

[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

Brukersiden trenger bare de to aliasene, noe som holder klientkonfigurasjonen fri for begge LAN-prefiksene. Ingenting i den konfigurasjonen nevner noen av de virkelige LAN-ene:

[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

Hver gateway annonserer huben og brukerens kilde, ingenting annet, slik at et sted aldri lærer det andre stedets LAN. Keepalive opprettholder en NAT-mapping på stedets uplink; det autoriserer ikke trafikk, og brannmuren avgjør fortsatt hva som slippes inn. Å kopiere konfigurasjonen fra én gateway til den andre er greit så lenge den private nøkkelen, grensesnittadressen og aliaset alle endres.

Hva huben må tillate mellom to av peerne sine

Huben videresender pakker mellom to av sine egne peer, noe som er en beslutning i forward-kjeden og ikke en inngangsbeslutning. Aktiver IPv4-videresending gjennom plattformens vanlige mekanisme, og tillat deretter nøyaktig de parene designet trenger.

Regelen nedenfor lar brukeren nå ett alias og én port, og tillater returtrafikk gjennom tilkoblingssporing. Den dropper alt annet i forward-banen, og det er poenget:

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

To detaljer er verdt å nevne fordi de gir stille feil. En accept i én basiskjede overstyrer ikke en drop i en annen, så slå dette sammen med den eksisterende policyen i stedet for å laste det ved siden av. Og kildeadressen identifiserer enheten, ikke personen; hold applikasjonsautentisering adskilt fra nettverkstilgang.

Hvor et alias blir en virkelig adresse

Sted A mottar en forespørsel til 10.77.1.20, skriver om destinasjonen til den virkelige applikasjonen og skriver om kilden til sin egen LAN-adresse slik at svaret kan komme tilbake uten en rute til tunnelen. Å gjøre begge oversettelsene på ett sted holder resten av nettverket uvitende om aliaset. Reglene nedenfor er hele mekanismen:

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

Forward-policyen til sted A må da tillate den oversatte strømmen fra tunnelgrensesnittet til LAN-grensesnittet, pluss returretningen. Forward-hooken ser destinasjonen etter destinasjonsoversettelsen og før kildeomskrivingen, derfor navngir regelen adressen til den virkelige applikasjonen. Les de to hookene i den rekkefølgen når en regel ser ut til ikke å matche noe. En forward-regel skrevet mot aliaset kan aldri matche, fordi aliaset ikke lenger finnes i den hooken.

Sted B gjentar dette med sitt eget alias og sin egen nøkkel. Det må ikke gjenbruke den private nøkkelen til sted A, fordi to peer som deler én identitet er en konfigurasjonsfeil som er vanskelig å se og lett å lage ved å kopiere en fil. Hold begge gateway-dokumentene identiske bortsett fra verdiene som må være forskjellige, slik at forskjellen skiller seg ut i gjennomgangen. En kopiert fil er den vanlige opprinnelsen til den feilen.

Kildeomskrivingen har en pris. Applikasjonen ser gatewayen som sin klient, så loggene viser ikke lenger hvilken bruker som koblet til. Behold revisjonssporet til gatewayen, og ikke svekk applikasjonsinnloggingen for å kompensere for en nettverksidentitet som oversettelsen fjernet.

Hvordan bevise at begge de publiserte navnene svarer

Gi hvert alias et DNS-navn og konfigurer applikasjonen og sertifikatet for det navnet, fordi oversettelse ikke skriver om omdirigeringer eller innebygde absolutte URL-er. Bruk ett navn per sted slik at et sertifikatavvik aldri kan forveksles med en rutefeil.

Test fra den virkelige klienten, bekreft hvilket sted som svarte, og test også en uautorisert port. Bruk nye tilkoblinger etter enhver NAT-endring, siden etablert tilstand beholder den gamle mappingen:

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

Et tomt eller uventet alias i den første kommandoen betyr at peer-valget er feil før noen brannmurregel betyr noe. Hvis aliaset er riktig og navnet fortsatt feiler, har problemet flyttet seg til DNS og sertifikater. Når begge navnene svarer og den tredje porten forblir lukket, gjør designet det det hevder: to smalt publiserte tjenester, ikke to sammenslåtte LAN.