Dve lokaciji, ena podmreža, eno zvezdišče WireGuard: poženite to

Obe lokaciji uporabljata isti obseg LAN in natanko prekrivanje ni tisto, kar resnično lomi zasnovo. Zvezdišče mora lokacijo izbrati samo po ciljnem naslovu, dva enaka cilja pa mu ne dasta ničesar, po čemer bi izbiralo. Prenumeriranje delujoče pisarne zaradi tunela je običajno slabša menjava kot dati vsaki objavljeni storitvi ločen naslov, ki ga tunel lahko prenese. Spodnja zasnova objavi eno storitev HTTPS na lokacijo in nič drugega.

Zakaj prekrivanje ni resnična težava

WireGuard posreduje po cilju: AllowedIPs nekega peerja odločajo, kateri peer prejme paket. Dva peerja ne moreta oba oglaševati 10.10.7.0/24, ne da bi eden od njiju dobil vsako iskanje. To je lastnost tabele peerjev in ne tunela, zato je rešitev tukaj načrt naslovov in ne trik z usmerjanjem.

Načrt je prenehati oglaševati LAN v celoti. Namesto tega oglašujte alias na storitev, en naslov na lokacijo, in pustite prehodu vsake lokacije, da ta alias prevede v svojo resnično aplikacijo.

Uporabnik usmerja dva edinstvena naslova, nikoli ne vidi dvoumne predpone, in v nobeni od obeh pisarn se nič ne spremeni. To tudi pošteno poimenuje mejo: objavljate eno storitev HTTPS z vsake lokacije, ne združujete dveh omrežij. Spodnja pravila ostanejo majhna, ker je trditev ozka. Širša trditev bi zahtevala širša pravila, in tako te zasnove postanejo zapletene.

Vsaki lokaciji dajte alias, ki ga uporabnik lahko usmerja

Izberite naslove iz obsega, ki ne trči ob nič na uporabnikovem računalniku, zvezdišču ali katerem koli od dveh omrežij LAN. Tukaj je zvezdišče 10.66.0.1, uporabnik 10.66.0.10, prehoda 10.66.0.21 in 10.66.0.22, dva aliasa pa 10.77.1.20 in 10.77.2.20. Zvezdišče objavi vsak alias prek peerja, ki ga ima v lasti, zato lahko odhodni paket, naslovljen na en alias, odide samo prek ustrezne lokacije:

[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

Uporabniška stran potrebuje le dva aliasa, kar ohranja konfiguracijo odjemalca brez obeh predpon LAN. Nič v tej konfiguraciji ne omenja nobenega od resničnih omrežij LAN:

[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

Vsak prehod oglašuje zvezdišče in vir uporabnika, nič drugega, zato se lokacija nikoli ne nauči omrežja LAN druge lokacije. Keepalive vzdržuje preslikavo NAT na uplinku lokacije; ne dovoljuje prometa in požarni zid še vedno odloča, kaj se spusti. Kopiranje konfiguracije enega prehoda v drugega je v redu, dokler se zasebni ključ, naslov vmesnika in alias vsi spremenijo.

Kaj mora zvezdišče dovoliti med dvema svojima peerjema

Zvezdišče posreduje pakete med dvema svojima peerjema, kar je odločitev v verigi forward in ne vhodna odločitev. Omogočite posredovanje IPv4 z običajnim mehanizmom platforme, nato dovolite natanko tiste pare, ki jih zasnova potrebuje.

Spodnje pravilo dovoli uporabniku en alias in ena vrata ter dovoli povratni promet prek sledenja povezavam. Zavrže vse drugo na poti forward, in to je bistvo:

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

Dve podrobnosti velja omeniti, ker povzročata tihe odpovedi. Accept v eni osnovni verigi ne razveljavi drop v drugi, zato to zlijte z obstoječo politiko, namesto da bi ga nalagali ob njej. In izvorni naslov prepozna napravo, ne osebe; hranite preverjanje pristnosti aplikacije ločeno od omrežnega dovoljenja.

Kjer alias postane resničen naslov

Lokacija A prejme zahtevo za 10.77.1.20, prepiše cilj na resnično aplikacijo in prepiše vir na svoj naslov LAN, da se lahko odgovor vrne brez poti do tunela. Izvajanje obeh prevodov na enem mestu ohranja preostanek omrežja nevednega o aliasu. Spodnja pravila so celoten mehanizem:

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

Politika forward lokacije A mora nato dovoliti prevedeni tok od vmesnika tunela do vmesnika LAN, plus povratno smer. Hook forward vidi cilj po prevodu cilja in pred prepisom vira, zato pravilo poimenuje naslov resnične aplikacije. Berite ta dva hooka v tem vrstnem redu, kadar koli se zdi, da pravilo ne ustreza ničemur. Pravilo forward, napisano proti aliasu, se nikoli ne more ujemati, ker alias v tem hooku ne obstaja več.

Lokacija B to ponovi s svojim aliasom in svojim ključem. Ne sme znova uporabiti zasebnega ključa lokacije A, ker sta dva peerja, ki si delita eno identiteto, konfiguracijska napaka, ki jo je težko videti in lahko ustvariti s kopiranjem datoteke. Oba dokumenta prehodov naj bosta enaka razen vrednosti, ki se morajo razlikovati, da razlika pri pregledu izstopi. Kopirana datoteka je običajen izvor te napake.

Prepis vira ima ceno. Aplikacija vidi prehod kot svojega odjemalca, zato njeni dnevniki ne kažejo več, kateri uporabnik se je povezal. Ohranite revizijsko sled prehoda in ne oslabite prijave v aplikacijo, da bi nadomestili omrežno identiteto, ki jo je prevod odstranil.

Kako dokazati, da se odzivata obe objavljeni imeni

Vsakemu aliasu dajte ime DNS in konfigurirajte aplikacijo ter potrdilo za to ime, ker prevod ne prepisuje preusmeritev ali vdelanih absolutnih URL-jev. Uporabite eno ime na lokacijo, da se neujemanje potrdila nikoli ne zamenja z napako usmerjanja.

Preizkusite iz resničnega odjemalca, potrdite, katera lokacija je odgovorila, in preizkusite tudi nepooblaščena vrata. Po vsaki spremembi NAT uporabite nove povezave, ker vzpostavljeno stanje ohranja staro preslikavo:

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

Prazen ali nepričakovan alias v prvem ukazu pomeni, da je izbira peerja napačna, preden postane pomembno katero koli pravilo požarnega zidu. Če je alias pravilen in ime še vedno ne deluje, se je težava preselila v DNS in potrdila. Ko se odzoveta obe imeni in tretja vrata ostanejo zaprta, zasnova naredi to, kar trdi: dve ozko objavljeni storitvi, ne dve združeni omrežji LAN.