Zwee Site, een Subnetz, een WireGuard-Hub: maacht et fonctionéieren

Béid Site benotzen deeselwechte LAN-Beräich, an d'Iwwerlappung ass net dat, wat den Design wierklech briecht. Den Hub muss e Site nëmmen duerch d'Zieladress auswielen, an zwee identesch Ziler ginn him näischt ze wielen. Eng funktionéierend Büro ëmzenummeréieren, fir en Tunnel ze erfëllen, ass meeschtens e schlechten Tausch, wéi all publizéierte Service eng eege Adress ze ginn, déi den Tunnel droe kann. Den Design hei drënner publizéiert een HTTPS-Service pro Site an soss näischt.

Firwat d'Iwwerlappung net de richtege Problem ass

WireGuard leet nom Zil weider: d'AllowedIPs vun engem Peer entscheeden, wéi en Peer e Paket kritt. Zwee Peer kënnen net allebéid 10.10.7.0/24 annonciéieren, ouni datt ee vun hinnen all Sich gewënnt. Dat ass eng Eegeschaft vun der Peer-Tabell an net vum Tunnel, dofir ass d'Léisung hei en Adressplang an net en Trick mam Routing.

De Plang ass, de LAN guer net méi z'annonciéieren. Annonciéiert amplaz en Alias pro Service, eng Adress pro Site, a loosst de Gateway vun all Site dësen Alias op seng richteg Applikatioun iwwersetzen.

De Benotzer routet zwou eenzegaarteg Adressen, gesäit ni de méideitege Prefix, an a kengem vun de béide Büroen ännert sech eppes. Dat seet och d'Grenz éierlech: Dir publizéiert een HTTPS-Service vun all Site, net zwee Netzwierker zesummen. D'Reegelen hei drënner bleiwen kleng, well d'Aussag enk ass. Eng méi breet Aussag géif méi breed Regele brauchen, an esou ginn dës Designen komplizéiert.

Gitt all Site en Alias, deen de Benotzer route kann

Wielt Adressen aus engem Beräich, deen mat näischt op dem Benotzer senger Maschinn, dem Hub oder engem vun de béide LAN kollidéiert. Hei ass den Hub 10.66.0.1, de Benotzer 10.66.0.10, d'Gategoriewe 10.66.0.21 an 10.66.0.22, an déi zwou Aliasen 10.77.1.20 an 10.77.2.20. Den Hub publizéiert all Alias iwwer de Peer, deen en huet, sou datt en erausgoend Paket un en Alias nëmmen iwwer de passende Site erausgoe kann:

[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

D'Benotzersäit brauch nëmmen déi zwou Aliasen, wat d'Client-Konfiguratioun fräi vun béide LAN-Prefixe hält. Näischt an där Konfiguratioun ernimmt ee vun de richtege 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

All Gateway annoncéiert den Hub an d'Quell vum Benotzer, soss näischt, sou datt ee Site ni de LAN vum aneren léiert. Keepalive hält eng NAT-Mappung um Uplink vum Site oprecht; et autoriséiert keen Trafik, an d'Firewall entscheet nach ëmmer, wat zougelooss gëtt. D'Konfiguratioun vun engem Gateway an deen aneren ze kopéieren ass okay, soulaang de privaten Schlëssel, d'Interface-Adress an den Alias alleguerten sech änneren.

Wat den Hub tëscht zwee vu senge Peer mussen erlaben

Den Hub leet Pakete tëscht zwee vu sengen eegene Peer weider, wat eng Entscheedung an der Forward-Kette an net eng Input-Entscheedung ass. Aktivéiert IPv4-Forwarding iwwer den normale Mechanismus vun der Plattform, an erlaabt duerno genee déi Puer, déi den Design brauch.

D'Reegel hei drënner erlaabt dem Benotzer een Alias an ee Port, an erlaabt Réckverkéier iwwer d'Verbindungsverfollegung. Si verwërftt alles anescht um Forward-Wee, an dat ass de Punkt:

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

Zwee Detailer si wäert ernimmt ze ginn, well si stille Feeler verursaachen. En Accept an enger Basiskette hieft keen Drop an enger anerer op, also fusionéiert dëst mat der bestehender Politik, amplaz et dernieft ze lueden. An d'Quelladress identifizéiert d'Apparat, net d'Persoun; haalt d'Applikatiounsauthentifizéierung getrennt vun der Netzzouloossung.

Wou en Alias eng richteg Adress gëtt

Site A kritt eng Ufro op 10.77.1.20, schreift d'Zil op déi richteg Applikatioun ëm an d'Quell op seng eegen LAN-Adress, sou datt d'Äntwert zréckkomme kann ouni eng Route an den Tunnel. Béid Iwwersetzungen op enger Plaz ze maachen hält de Rescht vum Netzwierk onwëssend iwwer den Alias. D'Reegelen hei drënner sinn de ganze 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

D'Forward-Politik vu Site A muss dann dee iwwersetzte Floss vun der Tunnel-Interface op d'LAN-Interface erlaben, plus d'Réckrichtung. Den Forward-Hook gesäit d'Zil nom Zil-Iwwersetzen an virum Quell-Ëmschreiwen, dofir nennt d'Reegel d'Adress vun der richtege Applikatioun. Liest déi zwee Hooken an där Reihenfolleg, wann eng Reegel schéngt op näischt ze passen. Eng Forward-Reegel géint den Alias geschriwwen kann ni passen, well den Alias op deem Hook net méi existéiert.

Site B widderhëlt dëst mat sengem eegenen Alias a sengem eegene Schlëssel. En däerf de privaten Schlëssel vu Site A net erëmbenotzen, well zwee Peer, déi eng Identitéit deelen, e Konfiguratiounsfeeler sinn, dee schwéier ze gesinn an einfach duerch d'Kopéiere vun enger Datei ze maachen ass. Haalt béid Gateway-Dokumenter identesch ausser de Wäerter, déi sech mussen ënnerscheeden, sou datt den Ënnerscheed bei der Iwwerpréifung opfällt. Eng kopéiert Datei ass de gewéinlechen Ursprong vun deem Feeler.

D'Quell-Ëmschreiwen huet e Präis. D'Applikatioun gesäit de Gateway als hire Client, dofir weisen hir Loggen net méi, wéi e Benotzer sech verbonnen huet. Haalt den Audit-Trail vum Gateway, an schwächt net den Applikatiounslogin of, fir eng Netzwierkidentitéit ze kompenséieren, déi d'Iwwersetzung ewechgeholl huet.

Wéi een beweist, datt béid publizéiert Nimm äntweren

Gitt all Alias en DNS-Numm an konfiguréiert d'Applikatioun an d'Zertifikat fir deen Numm, well d'Iwwersetzung Ëmleedungen oder agebaut absolut URLen net ëmschreift. Benotzt een Numm pro Site, sou datt eng Zertifikatsdiskrepanz ni mat engem Routingfeeler verwiesselt gëtt.

Test vum richtege Client, bestätegt, wéi e Site geäntwert huet, a test och en net autoriséierte Port. Benotzt nei Verbindungen no all NAT-Ännerung, well de festgestallte Staat déi al Mappung behält:

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

En eidele oder onerwaarten Alias am éischte Kommando heescht, datt d'Peer-Auswiel falsch ass, ier eng Firewall-Reegel iwwerhaapt zielt. Wann den Alias richteg ass an den Numm nach ëmmer feelt, ass de Problem op DNS an Zertifikater geplënnert. Soubal béid Nimm äntweren an den drëtten Port zou bleift, mécht den Design dat, wat en behaapt: zwee enk publizéiert Servicer, net zwee fusionéiert LAN.