Két telephely, egy alhálózat, egy WireGuard-hub: működtesse

Mindkét LAN a 10.10.7.0/24-en van, így a hub nem tud telephelyet választani cél szerint. Adjon minden szolgáltatásnak aliast, és fordítson az átjáróján.

Mindkét telephely ugyanazt a LAN-tartományt használja, és valójában nem az átfedés töri el a tervet. A hubnak kizárólag a célcím alapján kell telephelyet választania, két azonos cél pedig semmit nem ad neki a választáshoz. Egy működő iroda újraszámozása egy alagút kedvéért általában rosszabb üzlet, mint minden közzétett szolgáltatásnak külön címet adni, amelyet az alagút el tud vinni. Az alábbi terv telephelyenként egy HTTPS-szolgáltatást tesz közzé, és semmi mást.

Miért nem az átfedés az igazi probléma

A WireGuard cél szerint továbbít: egy peer AllowedIPs bejegyzései döntik el, melyik peer kapja meg a csomagot. Két peer nem hirdetheti egyszerre ugyanazt a 10.10.7.0/24-et anélkül, hogy az egyik minden keresést megnyerne. Ez a peer-tábla tulajdonsága, nem az alagúté, ezért itt a megoldás címterv, nem útválasztási trükk.

A terv az, hogy egyáltalán ne hirdessük a LAN-t. Hirdessünk helyette szolgáltatásonként egy aliast, telephelyenként egy címet, és hagyjuk, hogy az egyes telephelyek átjárója ezt az aliast a valódi alkalmazására fordítsa.

A felhasználó két egyedi címet irányít, soha nem látja a kétértelmű előtagot, és egyik irodában sem változik semmi. Ez a határt is őszintén kimondja: telephelyenként egy HTTPS-szolgáltatást tesz közzé, nem olvaszt össze két hálózatot. A következő szabályok azért maradnak kicsik, mert az állítás szűk. Szélesebb állításhoz szélesebb szabályok kellenének, és pontosan így válnak ezek a tervek bonyolulttá.

Adjon minden telephelynek egy aliast, amelyet a felhasználó irányíthat

Olyan tartományból válasszon címeket, amely nem ütközik semmivel a felhasználó gépén, a hubon vagy egyik LAN-on sem. Itt a hub 10.66.0.1, a felhasználó 10.66.0.10, az átjárók 10.66.0.21 és 10.66.0.22, a két alias pedig 10.77.1.20 és 10.77.2.20. A hub minden aliast az őt birtokló peeren keresztül hirdet, így az egy aliasra címzett kimenő csomag csak a megfelelő telephelyen keresztül hagyhatja el a hálózatot:

[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

A felhasználói oldalnak csak a két aliasra van szüksége, ami mentesíti az ügyfélkonfigurációt mindkét LAN-előtagtól. Semmi nem említ abban a konfigurációban egyik valódi LAN-t sem:

[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

Minden átjáró a hubot és a felhasználó forrását hirdeti, semmi mást, így egy telephely soha nem tanulja meg a másik LAN-ját. A Keepalive fenntart egy NAT-leképezést a telephely uplinkjén; nem engedélyez forgalmat, és a tűzfal továbbra is eldönti, mi engedhető át. Az egyik átjáró konfigurációját a másikba másolni rendben van, amíg a privát kulcs, az interfész címe és az alias mind változik.

Mit kell a hubnak engedélyeznie két peerje között

A hub a saját két peerje között továbbít csomagokat, ami a forward-lánc döntése, nem bemeneti döntés. Engedélyezze az IPv4-továbbítást a platform szokásos mechanizmusával, majd engedélyezze pontosan azokat a párokat, amelyekre a tervnek szüksége van.

Az alábbi szabály a felhasználónak egy aliast és egy portot engedélyez, és a visszirányú forgalmat kapcsolatkövetésen keresztül engedi. Minden mást eldob a forward-úton, és ez a lényeg:

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

Két részlet említésre méltó, mert csendes hibákat okoznak. Az accept az egyik alap-láncban nem írja felül a dropot egy másikban, ezért ezt olvassza össze a meglévő házirenddel, ne mellette töltse be. A forráscím pedig az eszközt azonosítja, nem a személyt; tartsa külön az alkalmazás hitelesítését a hálózati beengedéstől.

Ahol az alias valódi címmé válik

Az A telephely kérést kap a 10.77.1.20-ra, átírja a célt a valódi alkalmazásra, és átírja a forrást a saját LAN-címére, hogy a válasz útvonal nélkül is visszatérhessen az alagútba. Mindkét fordítást egy helyen végezve a hálózat többi része tudatlan marad az aliasról. Az alábbi szabályok alkotják a teljes mechanizmust:

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

Az A telephely forward-házirendjének ezután engedélyeznie kell a lefordított folyamot az alagút-interfészről a LAN-interfészre, valamint a visszirányt. A forward hook a célt a célfordítás után és a forrás átírása előtt látja, ezért a szabály a valódi alkalmazás címét nevezi meg. Olvassa ezt a két hookot ebben a sorrendben, amikor egy szabály úgy tűnik, mintha semmire nem illeszkedne. Az alias ellen írt forward-szabály soha nem illeszkedhet, mert az alias már nem létezik annál a hooknál.

A B telephely ezt a saját aliasával és a saját kulcsával ismétli. Nem használhatja újra az A telephely privát kulcsát, mert két peer egy identitás megosztása olyan konfigurációs hiba, amelyet nehéz észrevenni és könnyű fájl másolásával létrehozni. Tartsa a két átjáródokumentumot azonosnak, kivéve azokat az értékeket, amelyeknek el kell térniük, hogy a különbség feltűnjön az átvizsgáláskor. A másolt fájl a hiba szokásos forrása.

A forrás átírásának ára van. Az alkalmazás az átjárót látja ügyfélként, így a naplói már nem mutatják, melyik felhasználó csatlakozott. Tartsa meg az átjáró auditnyomát, és ne gyengítse az alkalmazás bejelentkezését egy olyan hálózati identitás kompenzálására, amelyet a fordítás eltávolított.

Hogyan bizonyítható, hogy mindkét közzétett név válaszol

Adjon minden aliasnak DNS-nevet, és állítsa be az alkalmazást és a tanúsítványt arra a névre, mert a fordítás nem írja át az átirányításokat vagy a beágyazott abszolút URL-eket. Használjon telephelyenként egy nevet, hogy a tanúsítvány-eltérés soha ne legyen összetéveszthető útválasztási hibával.

Teszteljen a valódi ügyfélről, erősítse meg, melyik telephely válaszolt, és teszteljen egy nem engedélyezett portot is. Minden NAT-változás után új kapcsolatokat használjon, mert a létrejött állapot megtartja a régi leképezést:

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

Az első parancsban üres vagy váratlan alias azt jelenti, hogy a peer kiválasztása hibás, mielőtt bármely tűzfalszabály számítana. Ha az alias helyes és a név mégis meghiúsul, a probléma a DNS-hez és a tanúsítványokhoz költözött. Amint mindkét név válaszol és a harmadik port zárva marad, a terv azt teszi, amit állít: két szűken közzétett szolgáltatás, nem két összevont LAN.

Kapcsolódó cikkek