Kaks saiti, üks alamvõrk, üks WireGuard-jaotur: pange see tööle

Mõlemad saidid kasutavad sama LAN-vahemikku ja ülekatmine ei ole see, mis disaini tegelikult rikub. Jaotur peab saidi valima ainult sihtkoha aadressi järgi ning kaks identset sihtkohta ei anna talle midagi, mille järgi valida. Töötava kontori ümber nummerdamine tunneli rahuldamiseks on tavaliselt halvem vahetus kui anda igale avaldatud teenusele eraldi aadress, mida tunnel suudab kanda. Allpool olev disain avaldab ühe HTTPS-teenuse saidi kohta ega midagi muud.

Miks ülekatmine ei ole tegelik probleem

WireGuard edastab sihtkoha järgi: peeri AllowedIPs määrab, milline peer paketi saab. Kaks peeri ei saa mõlemad 10.10.7.0/24 välja kuulutada, ilma et üks neist võidaks iga otsingu. See on peer-tabeli, mitte tunneli omadus, seepärast on lahendus siin aadressiplaan, mitte marsruutimise trikk.

Plaan on LAN-i üldse mitte enam välja kuulutada. Kuulutage selle asemel välja alias iga teenuse kohta, üks aadress saidi kohta, ja laske iga saidi lüüsil selle alias oma pärisrakenduseks tõlkida.

Kasutaja marsruudib kahte unikaalset aadressi, ei näe kunagi mitmetähenduslikku prefiksit ja kummaski kontoris ei muutu midagi. See ütleb ka piiri ausalt: te avaldate igast saidist ühe HTTPS-teenuse, ei liida kahte võrku kokku. Järgnevad reeglid jäävad väikeseks, sest väide on kitsas. Laiem väide vajaks laiemaid reegleid ja just nii need disainid keeruliseks muutuvad.

Andke igale saidile alias, mida kasutaja saab marsruutida

Valige aadressid vahemikust, mis ei ole vastuolus millegagi kasutaja masinas, jaoturis ega kummaski LAN-is. Siin on jaotur 10.66.0.1, kasutaja 10.66.0.10, lüüsid 10.66.0.21 ja 10.66.0.22 ning kaks aliast 10.77.1.20 ja 10.77.2.20. Jaotur avaldab iga aliase selle peeri kaudu, kellele see kuulub, seega ühele aliasele adresseeritud väljuv pakett saab lahkuda ainult vastavast saidist:

[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

Kasutajapool vajab ainult kahte aliast, mis hoiab kliendi konfiguratsiooni mõlemast LAN-prefiksist vabana. Miski selles konfiguratsioonis ei maini kumbagi päris LAN-i:

[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

Iga lüüs kuulutab välja jaoturi ja kasutaja allika, ei midagi muud, seega ei saa sait kunagi teada teise saidi LAN-i. Keepalive hoiab saidi ühendusliinil NAT-vastendust; see ei autoriseeri liiklust ja tulemüür otsustab endiselt, mis lubatakse. Ühe lüüsi konfiguratsiooni teise kopeerimine on korras seni, kui privaatvõti, liidese aadress ja alias kõik muutuvad.

Mida jaotur peab kahe oma peeri vahel lubama

Jaotur edastab pakette kahe oma peeri vahel, mis on forward-ahela otsus, mitte sisendi otsus. Lubage IPv4 edastamine platvormi tavapärase mehhanismi kaudu ja seejärel lubage täpselt need paarid, mida disain vajab.

Allolev reegel lubab kasutajal ühe aliase ja ühe pordi ning lubab tagasiliiklust ühenduste jälgimise kaudu. See viskab kõik muu forward-teelt välja ja see ongi mõte:

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

Kaks detaili tasub ära märkida, sest need põhjustavad vaikseid tõrkeid. Accept ühes baasahelas ei tühista drop-i teises, seega sulandage see olemasoleva poliitikaga, mitte ärge laadige seda kõrvale. Ja allikaaadress identifitseerib seadme, mitte inimese; hoidke rakenduse autentimine võrgu lubamisest eraldi.

Kus aliasest saab päris aadress

Sait A saab päringu aadressile 10.77.1.20, kirjutab sihtkoha ümber pärisrakenduseks ja kirjutab allika ümber oma LAN-aadressiks, et vastus saaks naasta ilma tunnelisse viiva marsruudita. Mõlema tõlke tegemine ühes kohas hoiab ülejäänud võrgu aliasest teadmatuna. Allolevad reeglid on kogu mehhanism:

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

Seejärel peab saidi A forward-poliitika lubama tõlgitud voogu tunneliliidesest LAN-liidesesse, pluss tagasisuuna. Forward-konks näeb sihtkohta pärast sihtkoha tõlget ja enne allika ümberkirjutust, seepärast nimetab reegel pärisrakenduse aadressi. Lugege neid kahte konksu selles järjekorras, kui reegel näib, et ei sobi millegagi. Aliase vastu kirjutatud forward-reegel ei saa kunagi sobida, sest aliast selles konksus enam ei ole.

Sait B kordab seda oma aliase ja oma võtmega. See ei tohi saidi A privaatvõtit uuesti kasutada, sest kaks peeri, kes jagavad üht identiteeti, on konfiguratsiooniviga, mida on raske näha ja lihtne faili kopeerides luua. Hoidke mõlemad lüüsi dokumendid identsed, välja arvatud väärtused, mis peavad erinema, et erinevus ülevaatamisel silma hakkaks. Kopeeritud fail on selle vea tavaline allikas.

Allika ümberkirjutamisel on hind. Rakendus näeb lüüsi oma kliendina, seega selle logid ei näita enam, milline kasutaja ühendus. Hoidke lüüsi auditijälg ja ärge nõrgendage rakenduse sisselogimist, et kompenseerida võrguidentiteeti, mille tõlge eemaldas.

Kuidas tõestada, et mõlemad avaldatud nimed vastavad

Andke igale aliasele DNS-nimi ja seadistage rakendus ja sertifikaat selle nime jaoks, sest tõlge ei kirjuta ümber ümbersuunamisi ega manustatud absoluutseid URL-e. Kasutage ühte nime saidi kohta, et sertifikaadi mittevastavust ei saaks kunagi marsruutimistõrkeks pidada.

Testige päris kliendist, kinnitage, milline sait vastas, ja testige ka volitamata porti. Kasutage pärast iga NAT-muudatust uusi ühendusi, sest kehtestatud olek hoiab vana vastendust:

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

Tühi või ootamatu alias esimeses käsus tähendab, et peeri valik on vale enne, kui ükskõik milline tulemüürireegel loeb. Kui alias on õige ja nimi siiski ei tööta, on probleem liikunud DNS-i ja sertifikaatide juurde. Kui mõlemad nimed vastavad ja kolmas port jääb suletuks, teeb disain seda, mida ta väidab: kaks kitsalt avaldatud teenust, mitte kaks kokku liidetud LAN-i.