Dvě lokality, jedna podsíť, jeden hub WireGuard: rozchoďte to

Obě lokality používají stejný rozsah LAN a právě překrytí není to, co návrh doopravdy rozbíjí. Hub musí vybrat lokalitu pouze podle cílové adresy a dvě shodné cíle mu nedávají nic, podle čeho vybírat. Přečíslovat fungující kancelář kvůli tunelu je obvykle horší obchod než dát každé publikované službě vlastní adresu, kterou tunel unese. Návrh níže publikuje jednu službu HTTPS na lokalitu a nic jiného.

Proč překrytí není skutečný problém

WireGuard přeposílá podle cíle: AllowedIPs peeru rozhodují, který peer paket dostane. Dva peery nemohou oba ohlašovat 10.10.7.0/24, aniž by jeden z nich vyhrál každé hledání. To je vlastnost tabulky peerů, ne tunelu, a proto je řešením tady plán adres, a ne trik s routováním.

Plán je přestat LAN ohlašovat úplně. Místo toho ohlaste alias pro každou službu, jednu adresu na lokalitu, a brána každé lokality tento alias přeloží na svou skutečnou aplikaci.

Uživatel routuje dvě jedinečné adresy, nikdy nevidí nejednoznačný prefix a v žádné ze dvou kanceláří se nic nemění. To také poctivě vymezuje hranici: publikujete jednu službu HTTPS z každé lokality, nesléváte dvě sítě. Pravidla níže zůstávají malá, protože tvrzení je úzké. Širší tvrzení by potřebovalo širší pravidla, a tak se tyto návrhy komplikují.

Dejte každé lokalitě alias, který uživatel umí routovat

Vyberte adresy z rozsahu, který nekoliduje s ničím na uživatelově počítači, na hubu ani v žádné z obou LAN. Tady je hub 10.66.0.1, uživatel 10.66.0.10, brány 10.66.0.21 a 10.66.0.22 a dva aliasy 10.77.1.20 a 10.77.2.20. Hub publikuje každý alias přes peer, který ho vlastní, takže odchozí paket adresovaný jednomu aliasu může odejít jen přes odpovídající lokalitu:

[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

Uživatelská strana potřebuje jen dva aliasy, což drží konfiguraci klienta bez obou prefixů LAN. Nic v té konfiguraci nezmiňuje ani jednu skutečnou 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

Každá brána ohlašuje hub a zdroj uživatele, nic jiného, takže lokalita se nikdy nedozví LAN té druhé. Keepalive udržuje mapování NAT na uplinku lokality; nepovoluje provoz a firewall stále rozhoduje, co se propustí. Kopírovat konfiguraci jedné brány do druhé je v pořádku, dokud se změní privátní klíč, adresa rozhraní i alias.

Co musí hub povolit mezi dvěma svými peery

Hub přeposílá pakety mezi dvěma svými peery, což je rozhodnutí ve forward řetězci, ne vstupní rozhodnutí. Zapněte přeposílání IPv4 obvyklým mechanismem platformy a pak povolte přesně ty dvojice, které návrh potřebuje.

Pravidlo níže povoluje uživateli jeden alias a jeden port a umožňuje zpětný provoz přes sledování spojení. Zahazuje vše ostatní na forward cestě, a o to jde:

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

Dva detaily stojí za zmínku, protože způsobují tiché poruchy. Accept v jednom základním řetězci nepřebíjí drop v jiném, takže to slučte s existující politikou, místo abyste to načítali vedle ní. A zdrojová adresa identifikuje zařízení, ne osobu; držte autentizaci aplikace oddělenou od síťového povolení.

Kde se alias stane skutečnou adresou

Lokalita A dostane požadavek na 10.77.1.20, přepíše cíl na skutečnou aplikaci a přepíše zdroj na svou vlastní adresu LAN, aby se odpověď mohla vrátit bez routy do tunelu. Provedení obou překladů na jednom místě drží zbytek sítě v nevědomosti o aliasu. Pravidla níže jsou celý mechanismus:

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 politika lokality A pak musí povolit přeložený tok z rozhraní tunelu do rozhraní LAN plus zpětný směr. Hook forward vidí cíl po překladu cíle a před přepsáním zdroje, proto pravidlo uvádí adresu skutečné aplikace. Čtěte ty dva hooky v tomto pořadí, kdykoli se zdá, že pravidlo na nic nesedí. Forward pravidlo psané proti aliasu nemůže nikdy sedět, protože alias v tom hooku už neexistuje.

Lokalita B to opakuje se svým aliasem a svým klíčem. Nesmí znovu použít privátní klíč lokality A, protože dva peery sdílející jednu identitu jsou konfigurační chyba, kterou je těžké vidět a snadné vytvořit zkopírováním souboru. Držte oba dokumenty bran identické kromě hodnot, které se musí lišit, aby rozdíl při kontrole vynikl. Zkopírovaný soubor je obvyklým zdrojem té závady.

Přepsání zdroje má cenu. Aplikace vidí bránu jako svého klienta, takže její logy už neukazují, který uživatel se připojil. Zachovejte auditní stopu brány a neoslabujte přihlášení do aplikace, abyste kompenzovali síťovou identitu, kterou překlad odstranil.

Jak dokázat, že obě publikovaná jména odpovídají

Dejte každému aliasu jméno v DNS a nakonfigurujte aplikaci i certifikát pro to jméno, protože překlad nepřepisuje přesměrování ani vložené absolutní URL. Používejte jedno jméno na lokalitu, aby si nesoulad certifikátu nikdo nikdy nespletl s poruchou routování.

Testujte ze skutečného klienta, ověřte, která lokalita odpověděla, a otestujte i nepovolený port. Po každé změně NAT použijte nová spojení, protože navázaný stav drží staré mapování:

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

Prázdný nebo neočekávaný alias v prvním příkazu znamená, že volba peeru je špatná dřív, než začne záležet na jakémkoli firewall pravidle. Pokud je alias správný a jméno přesto nefunguje, problém se přesunul do DNS a certifikátů. Jakmile obě jména odpovídají a třetí port zůstane zavřený, návrh dělá, co tvrdí: dvě úzce publikované služby, ne dvě sloučené LAN.