To stader, eitt subnett, éin WireGuard-hub: få det til å verke

Begge stadene brukar same LAN-område, og overlappinga er ikkje det som eigentleg øydelegg designet. Huben må velje ein stad berre ut frå måladressa, og to identiske mål gir han ingenting å velje etter. Å nummerere om eit kontor som fungerer for å tilfredsstille ein tunnel er vanlegvis ein dårlegare byttehandel enn å gi kvar publiserte teneste ei eiga adresse som tunnelen kan bera. Designet nedanfor publiserer éi HTTPS-teneste per stad og ingenting anna.

Kvifor overlappinga ikkje er det eigentlege problemet

WireGuard videresendar etter mål: AllowedIPs til ein peer avgjer kva peer ein pakke går til. To peer kan ikkje begge annonsere 10.10.7.0/24 utan at ein av dei vinn kvart oppslag. Det er ein eigenskap ved peer-tabellen og ikkje ved tunnelen, difor er løysinga her ein adresseplan og ikkje eit rutetricks.

Planen er å slutte heilt å annonsere LAN-et. Annonser i staden eit alias per teneste, éi adresse per stad, og la porten på kvar stad omsetje aliaset til sin verkelege applikasjon.

Brukaren rutar to unike adresser, ser aldri det tvitydige prefikset, og ingenting endrar seg i nokon av dei to kontora. Det seier også grensa ærleg: du publiserer éi HTTPS-teneste frå kvar stad, du slår ikkje saman to nettverk. Reglane nedanfor held seg små fordi påstanden er smal. Ein breiare påstand ville trenge breiare reglar, og det er slik desse designa blir kompliserte.

Gi kvar stad eit alias som brukaren kan rute

Vel adresser frå eit område som ikkje kolliderer med noko på maskina til brukaren, huben eller noko av dei to LAN-a. Her er huben 10.66.0.1, brukaren 10.66.0.10, portane 10.66.0.21 og 10.66.0.22, og dei to aliasa 10.77.1.20 og 10.77.2.20. Huben publiserer kvart alias gjennom peeren som eig det, slik at ein utgåande pakke adressert til eitt alias berre kan gå ut gjennom den samsvarande staden:

[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

Brukarsida treng berre dei to aliasa, noko som held klientkonfigurasjonen fri for begge LAN-prefiksa. Ingenting i den konfigurasjonen nemner noko av dei verkelege LAN-a:

[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

Kvar port annonserer huben og kjelda til brukaren, ingenting anna, slik at ein stad aldri lærer LAN-et til den andre staden. Keepalive held ved like ei NAT-mapping på uplinken til staden; det autoriserer ikkje trafikk, og brannmuren avgjer framleis kva som slepp inn. Å kopiere konfigurasjonen frå ein port til den andre er greitt så lenge den private nøkkelen, grensesnittadressa og aliaset alle blir endra.

Kva huben må tillate mellom to av peerane sine

Huben videresendar pakkar mellom to av sine eigne peer, noko som er ei avgjerd i forward-kjeda og ikkje ei inngangsavgjerd. Slå på IPv4-videresending gjennom den vanlege mekanismen til plattforma, og tillat deretter nøyaktig dei para designet treng.

Regelen nedanfor lèt brukaren nå eitt alias og éin port, og tillèt returtrafikk gjennom tilkoplingssporing. Han droppar alt anna 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 detaljar er verd å nemne fordi dei gir stille feil. Ein accept i éi basiskjede overstyrer ikkje ein drop i ei anna, så slå dette saman med den eksisterande policyen i staden for å laste det ved sida av. Og kjeldeadressa identifiserer eininga, ikkje personen; hald applikasjonsautentisering skild frå nettilgang.

Kvar eit alias blir ei verkeleg adresse

Stad A tek imot ein førespurnad til 10.77.1.20, skriv om målet til den verkelege applikasjonen og skriv om kjelda til si eiga LAN-adresse slik at svaret kan kome tilbake utan ei rute til tunnelen. Å gjere begge omsetjingane på ein stad held resten av nettverket uvitande om aliaset. Reglane nedanfor er heile 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 stad A må då tillate den omsette straumen frå tunnelgrensesnittet til LAN-grensesnittet, pluss returretninga. Forward-hooken ser målet etter målomsetjinga og før kjelda blir skriven om, difor namngir regelen adressa til den verkelege applikasjonen. Les dei to hookane i den rekkjefølgja når ein regel ser ut til ikkje å passe med noko. Ein forward-regel skriven mot aliaset kan aldri passe, fordi aliaset ikkje finst lenger i den hooken.

Stad B gjer dette om att med sitt eige alias og sin eigen nøkkel. Det må ikkje bruke om att den private nøkkelen til stad A, fordi to peer som deler éin identitet er ein konfigurasjonsfeil som er vanskeleg å sjå og lett å lage ved å kopiere ei fil. Hald begge gateway-dokumenta identiske bortsett frå verdiane som må vere ulike, slik at skilnaden skil seg ut i gjennomgangen. Ei kopiert fil er den vanlege opphavet til den feilen.

Kjeldomskrivinga har ein pris. Applikasjonen ser porten som klienten sin, så loggane viser ikkje lenger kva brukar som kopla til. Hald på revisjonssporet til porten, og svekk ikkje applikasjonsinnlogginga for å kompensere for ein nettidentitet som omsetjinga fjerna.

Korleis prove at begge dei publiserte namna svarar

Gi kvart alias eit DNS-namn og konfigurer applikasjonen og sertifikatet for det namnet, fordi omsetjing ikkje skriv om omdirigeringar eller innebygde absolutte URL-ar. Bruk eitt namn per stad slik at eit sertifikatavvik aldri kan bli forveksla med ein rutefeil.

Test frå den verkelege klienten, stadfest kva stad som svara, og test også ein uautorisert port. Bruk nye tilkoplingar etter kvar NAT-endring, sidan etablert tilstand held på den gamle mappinga:

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

Eit tomt eller uventa alias i den første kommandoen betyr at peer-valet er feil før nokon brannmurregel betyr noko. Viss aliaset er rett og namnet framleis feilar, har problemet flytta seg til DNS og sertifikat. Når begge namna svarar og den tredje porten blir verande lukka, gjer designet det det hevdar: to smalt publiserte tenester, ikkje to samanslåtte LAN.