Dvije lokacije, jedna podmreža, jedan WireGuard hub: pokrenite to

Obje lokacije koriste isti LAN raspon, a preklapanje nije ono što zapravo kvari dizajn. Hub mora odabrati lokaciju samo prema odredišnoj adresi, a dva identična odredišta ne daju mu ništa za odabir. Prenumerisanje ureda koji radi kako bi se zadovoljio tunel obično je lošija razmjena od davanja svakoj objavljenoj usluzi zasebne adrese koju tunel može prenijeti. Dizajn ispod objavljuje jednu HTTPS uslugu po lokaciji i ništa drugo.

Zašto preklapanje nije pravi problem

WireGuard prosljeđuje prema odredištu: AllowedIPs nekog peer-a odlučuju koji peer prima paket. Dva peer-a ne mogu oba oglašavati 10.10.7.0/24, a da jedan od njih ne dobije svako traženje. To je svojstvo tablice peer-a, a ne tunela, zato je rješenje ovdje plan adresa, a ne trik s rutiranjem.

Plan je potpuno prestati oglašavati LAN. Umjesto toga oglašavajte alias po usluzi, jednu adresu po lokaciji, i neka gateway svake lokacije prevede taj alias u svoju stvarnu aplikaciju.

Korisnik rutira dvije jedinstvene adrese, nikad ne vidi dvosmisleni prefiks, i ništa se ne mijenja ni u jednom uredu. To i pošteno postavlja granicu: objavljujete jednu HTTPS uslugu sa svake lokacije, a ne spajate dvije mreže. Pravila koja slijede ostaju mala jer je tvrdnja uska. Šira tvrdnja zahtijevala bi šira pravila, a tako ovi dizajni postaju komplikovani.

Dajte svakoj lokaciji alias koji korisnik može rutirati

Odaberite adrese iz raspona koji ne kolidira ni s čim na korisnikovom računaru, na hubu ni na bilo kojem LAN-u. Ovdje je hub 10.66.0.1, korisnik 10.66.0.10, gateway-i 10.66.0.21 i 10.66.0.22, a dva aliasa 10.77.1.20 i 10.77.2.20. Hub objavljuje svaki alias kroz peer koji ga posjeduje, pa izlazni paket upućen jednom aliasu može izaći samo kroz odgovarajuću lokaciju:

[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

Korisničkoj strani trebaju samo dva aliasa, što klijentsku konfiguraciju drži bez oba LAN prefiksa. Ništa u toj konfiguraciji ne spominje ni jedan stvarni 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

Svaki gateway oglašava hub i korisnikov izvor, ništa drugo, pa lokacija nikad ne sazna LAN druge lokacije. Keepalive održava NAT mapiranje na uplinku lokacije; ono ne odobrava promet, a firewall i dalje odlučuje šta se propušta. Kopiranje konfiguracije jednog gateway-a u drugi je u redu dok se privatni ključ, adresa interfejsa i alias svi mijenjaju.

Šta hub mora dopustiti između dva svoja peer-a

Hub prosljeđuje pakete između dva svoja peer-a, što je odluka u forward lancu, a ne ulazna odluka. Uključite IPv4 prosljeđivanje uobičajenim mehanizmom platforme, zatim dopustite tačno one parove koje dizajn treba.

Pravilo ispod dopušta korisniku jedan alias i jedan port i dopušta povratni promet kroz praćenje veza. Ono odbacuje sve ostalo na forward putu, i to je poenta:

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 detalja vrijedi navesti jer izazivaju tihe kvarove. Accept u jednom baznom lancu ne nadjačava drop u drugom, pa ovo spojite s postojećom politikom umjesto da je učitavate uporedo. I izvorna adresa identifikuje uređaj, ne osobu; držite autentifikaciju aplikacije odvojenom od mrežnog dopuštanja.

Gdje alias postaje stvarna adresa

Lokacija A prima zahtjev za 10.77.1.20, prepisuje odredište na stvarnu aplikaciju i prepisuje izvor na svoju LAN adresu kako bi se odgovor mogao vratiti bez rute do tunela. Obavljanje oba prevođenja na jednom mjestu drži ostatak mreže u neznanju o aliasu. Pravila ispod su cijeli mehanizam:

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 lokacije A zatim mora dopustiti prevedeni tok od interfejsa tunela do LAN interfejsa, plus povratni smjer. Forward hook vidi odredište nakon prevođenja odredišta i prije prepisivanja izvora, zato pravilo imenuje adresu stvarne aplikacije. Čitajte ta dva hook-a tim redom kad god se čini da pravilo ništa ne pogađa. Forward pravilo napisano prema aliasu nikad ne može pogoditi, jer alias više ne postoji na tom hook-u.

Lokacija B to ponavlja sa svojim aliasom i svojim ključem. Ne smije ponovo koristiti privatni ključ lokacije A, jer dva peer-a koja dijele jedan identitet su konfiguracijska greška koju je teško vidjeti i lako stvoriti kopiranjem datoteke. Držite oba dokumenta gateway-a identičnima osim vrijednosti koje se moraju razlikovati, da razlika upadne u oči pri pregledu. Kopirana datoteka je uobičajeni izvor te greške.

Prepisivanje izvora ima cijenu. Aplikacija vidi gateway kao svog klijenta, pa njeni zapisi više ne pokazuju koji se korisnik povezao. Zadržite revizijski trag gateway-a i ne slabite prijavu u aplikaciju da biste nadoknadili mrežni identitet koji je prevođenje uklonilo.

Kako dokazati da oba objavljena imena odgovaraju

Dajte svakom aliasu DNS ime i konfigurirajte aplikaciju i certifikat za to ime, jer prevođenje ne prepisuje preusmjeravanja ni ugrađene apsolutne URL-ove. Koristite jedno ime po lokaciji da se nesklad certifikata nikad ne pobrka s rutnim kvarom.

Testirajte sa stvarnog klijenta, potvrdite koja je lokacija odgovorila i testirajte i neovlašteni port. Koristite nove veze nakon svake promjene NAT-a, jer uspostavljeno stanje zadržava staro mapiranje:

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

Prazan ili neočekivan alias u prvoj komandi znači da je odabir peer-a pogrešan prije nego što i jedno firewall pravilo postane važno. Ako je alias ispravan a ime i dalje ne radi, problem se preselio na DNS i certifikate. Kad oba imena odgovore i treći port ostane zatvoren, dizajn radi ono što tvrdi: dvije usko objavljene usluge, a ne dva spojena LAN-a.