Dve lokality, jedna podsiet, jeden hub WireGuard: rozbehnite to

Obe lokality používajú rovnaký rozsah LAN a práve prekrytie nie je to, čo návrh naozaj rozbíja. Hub musí vybrať lokalitu iba podľa cieľovej adresy a dve rovnaké ciele mu nedávajú nič, podľa čoho vyberať. Prečíslovať fungujúcu kanceláriu kvôli tunelu je zvyčajne horší obchod než dať každej publikovanej službe vlastnú adresu, ktorú tunel unesie. Návrh nižšie publikuje jednu službu HTTPS na lokalitu a nič iné.

Prečo prekrytie nie je skutočný problém

WireGuard preposiela podľa cieľa: AllowedIPs peera rozhodujú, ktorý peer paket dostane. Dva peery nemôžu oba ohlasovať 10.10.7.0/24 bez toho, aby jeden z nich vyhral každé hľadanie. To je vlastnosť tabuľky peerov, nie tunela, preto je riešením tu plán adries, a nie trik s routovaním.

Plán je prestať LAN ohlasovať úplne. Namiesto toho ohlaste alias pre každú službu, jednu adresu na lokalitu, a brána každej lokality tento alias preloží na svoju skutočnú aplikáciu.

Používateľ routuje dve jedinečné adresy, nikdy nevidí nejednoznačný prefix a v žiadnej z dvoch kancelárií sa nič nemení. To tiež čestne vymedzuje hranicu: publikujete jednu službu HTTPS z každej lokality, nezlúčujete dve siete. Pravidlá nižšie zostávajú malé, pretože tvrdenie je úzke. Širšie tvrdenie by potrebovalo širšie pravidlá, a tak sa tieto návrhy komplikujú.

Dajte každej lokalite alias, ktorý používateľ dokáže routovať

Vyberte adresy z rozsahu, ktorý nekoliduje s ničím na počítači používateľa, na hube ani v žiadnej z dvoch LAN. Tu je hub 10.66.0.1, používateľ 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 cez peera, ktorý ho vlastní, takže odchádzajúci paket adresovaný jednému aliasu môže odísť len cez zodpovedajúcu 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

Používateľská strana potrebuje len dva aliasy, čo drží konfiguráciu klienta bez oboch prefixov LAN. Nič v tej konfigurácii nespomína ani jednu skutočnú 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 ohlasuje hub a zdroj používateľa, nič iné, takže lokalita sa nikdy nedozvie LAN tej druhej. Keepalive udržiava mapovanie NAT na uplinku lokality; nepovoľuje prevádzku a firewall stále rozhoduje, čo sa prepustí. Kopírovať konfiguráciu jednej brány do druhej je v poriadku, pokiaľ sa zmení privátny kľúč, adresa rozhrania aj alias.

Čo musí hub povoliť medzi dvoma svojimi peermi

Hub preposiela pakety medzi dvoma svojimi peermi, čo je rozhodnutie vo forward reťazci, nie vstupné rozhodnutie. Zapnite preposielanie IPv4 obvyklým mechanizmom platformy a potom povoľte presne tie dvojice, ktoré návrh potrebuje.

Pravidlo nižšie povoľuje používateľovi jeden alias a jeden port a umožňuje spätnú prevádzku cez sledovanie spojení. Zahadzuje všetko ostatné na forward ceste, a o to ide:

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 stoja za zmienku, pretože spôsobujú tiché poruchy. Accept v jednom základnom reťazci neprebíja drop v inom, takže to zlúčte s existujúcou politikou, namiesto načítania vedľa nej. A zdrojová adresa identifikuje zariadenie, nie osobu; držte autentifikáciu aplikácie oddelene od sieťového povolenia.

Kde sa alias stane skutočnou adresou

Lokalita A dostane požiadavku na 10.77.1.20, prepíše cieľ na skutočnú aplikáciu a prepíše zdroj na svoju vlastnú adresu LAN, aby sa odpoveď mohla vrátiť bez trasy do tunela. Vykonanie oboch prekladov na jednom mieste drží zvyšok siete v nevedomosti o aliase. Pravidlá nižšie sú celý mechanizmus:

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 potom musí povoliť preložený tok z rozhrania tunela do rozhrania LAN plus spätný smer. Hook forward vidí cieľ po preklade cieľa a pred prepisom zdroja, preto pravidlo uvádza adresu skutočnej aplikácie. Čítajte tie dva hooky v tomto poradí, kedykoľvek sa zdá, že pravidlo na nič nesedí. Forward pravidlo písané proti aliasu nemôže nikdy sedieť, pretože alias v tom hooku už neexistuje.

Lokalita B to opakuje so svojím aliasom a svojím kľúčom. Nesmie znova použiť privátny kľúč lokality A, pretože dva peery zdieľajúce jednu identitu sú konfiguračná chyba, ktorú je ťažké vidieť a ľahké vytvoriť skopírovaním súboru. Držte oba dokumenty brán identické okrem hodnôt, ktoré sa musia líšiť, aby rozdiel pri kontrole vynikol. Skopírovaný súbor je obvyklým zdrojom tej závady.

Prepísanie zdroja má cenu. Aplikácia vidí bránu ako svojho klienta, takže jej logy už neukazujú, ktorý používateľ sa pripojil. Zachovajte audítnú stopu brány a neoslabujte prihlásenie do aplikácie, aby ste kompenzovali sieťovú identitu, ktorú preklad odstránil.

Ako dokázať, že obe publikované mená odpovedajú

Dajte každému aliasu meno v DNS a nakonfigurujte aplikáciu aj certifikát pre to meno, pretože preklad neprepisuje presmerovania ani vložené absolútne URL. Používajte jedno meno na lokalitu, aby si nesúlad certifikátu nikto nikdy nepomýlil s poruchou routovania.

Testujte zo skutočného klienta, overte, ktorá lokalita odpovedala, a otestujte aj nepovolený port. Po každej zmene NAT použite nové spojenia, pretože nadviazaný stav drží staré mapovanie:

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

Prázdny alebo neočakávaný alias v prvom príkaze znamená, že voľba peera je nesprávna skôr, než začne záležať na akomkoľvek firewall pravidle. Ak je alias správny a meno napriek tomu zlyháva, problém sa presunul do DNS a certifikátov. Keď obe mená odpovedajú a tretí port zostane zatvorený, návrh robí to, čo tvrdí: dve úzko publikované služby, nie dve zlúčené LAN.