Tvær síður, eitt undirnet, einn WireGuard-hnútur: látið það virka

Bæði LANin eru á 10.10.7.0/24, svo hnúturinn getur ekki valið síðu eftir áfangastað. Gefið hverri þjónustu samheiti og þýðið í gátt hennar.

Báðar síðurnar nota sama LAN-sviðið, og skörunin er ekki það sem brýtur hönnunina í raun. Hnúturinn verður að velja síðu eingöngu út frá áfangastaðarfanginu, og tveir sams konar áfangastaðir gefa honum ekkert að velja með. Að endurnúmera vinnandi skrifstofu til að fullnægja göngum er yfirleitt verri skipti en að gefa hverri birtri þjónustu sérstakt fang sem göngin geta borið. Hönnunin hér að neðan birtir eina HTTPS-þjónustu á hverja síðu og ekkert annað.

Hvers vegna skörunin er ekki raunverulega vandamálið

WireGuard sendir áfram eftir áfangastað: AllowedIPs jafnings ráða því hvaða jafningi fær pakkann. Tveir jafningar geta ekki báðir tilkynnt 10.10.7.0/24 án þess að annar þeirra vinni hverja leit. Það er eiginleiki jafningjatöflunnar en ekki ganganna, og þess vegna er lausnin hér fangskipulag en ekki brella í leiðsögn.

Áætlunin er að hætta alfarið að tilkynna LANið. Tilkynnið í staðinn samheiti fyrir hverja þjónustu, eitt fang á hverja síðu, og látið gátt hverrar síðu þýða það samheiti yfir í raunverulega forritið sitt.

Notandinn leiðir tvö einstök fang, sér aldrei tvíræða forskeytið, og ekkert breytist á hvorri skrifstofunni. Þetta segir líka mörkin heiðarlega: þú birtir eina HTTPS-þjónustu frá hverri síðu, ekki að sameina tvö net. Reglurnar sem fylgja haldast litlar vegna þess að fullyrðingin er þröng. Víðtækari fullyrðing þyrfti víðtækari reglur, og þannig verða þessar hannanir flóknar.

Gefðu hverri síðu samheiti sem notandinn getur leitt

Veljið fang úr sviði sem stangast ekki á við neitt á vél notandans, hnútnum eða hvoru LANinu sem er. Hér er hnúturinn 10.66.0.1, notandinn 10.66.0.10, gáttirnar 10.66.0.21 og 10.66.0.22, og samheitin tvö 10.77.1.20 og 10.77.2.20. Hnúturinn birtir hvert samheiti í gegnum þann jafning sem á það, svo útfarandi pakki sem er stilaður á eitt samheiti getur aðeins farið út um samsvarandi síðu:

[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

Notandahliðin þarf aðeins samheitin tvö, sem heldur stillingum biðlarans lausum við bæði LAN-forskeytin. Ekkert í þeim stillingum nefnir annað raunverulega LANið:

[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

Hver gátt tilkynnir hnútinn og uppruna notandans, ekkert annað, svo síða lærir aldrei LAN hinnar síðunnar. Keepalive viðheldur NAT-vörpun á uppstreymistengingu síðunnar; það heimilar ekki umferð, og eldveggurinn ákveður enn hvað er hleypt inn. Að afrita stillingar einnar gáttar yfir í hina er í lagi svo framarlega sem einkalykillinn, viðmótsfangið og samheitið breytast öll.

Hvað hnúturinn verður að leyfa milli tveggja jafningja sinna

Hnúturinn sendir pakka á milli tveggja eigin jafningja, sem er ákvörðun í forward-keðjunni en ekki inntaksákvörðun. Virkið IPv4-framsendingu með venjulegum hætti kerfisins, og leyfið síðan nákvæmlega þau pör sem hönnunin þarf.

Reglan hér að neðan leyfir notandanum eitt samheiti og eina gátt og leyfir afturumferð í gegnum tengslarakningu. Hún hendir öllu öðru á forward-slóðinni, og það er punktarinn:

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

Tveir smáatriðir eru þess virði að nefna því þeir valda hljóðlátum bilunum. Accept í einni grunnkeðju hnekkir ekki drop í annarri, svo sameinið þetta við núverandi stefnu í stað þess að hlaða því við hliðina. Og upprunafangið auðkennir tækið, ekki manneskjuna; haldið forritaaðkenningunni aðskilinni frá netaðgangi.

Þar sem samheiti verður raunverulegt fang

Síða A fær beiðni um 10.77.1.20, endurskrifar áfangastaðinn yfir í raunverulega forritið og endurskrifar upprunann yfir í eigið LAN-fang svo svarið geti snúið til baka án leiðar í göngin. Að gera báðar þýðingarnar á einum stað heldur restinni af netinu óvitandi um samheitið. Reglurnar hér að neðan eru allur gangurinn:

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-stefna síðu A verður þá að leyfa þýdda strauminn frá viðmóti ganganna yfir í LAN-viðmótið, auk afturáttarinnar. Forward-hookið sér áfangastaðinn eftir áfangastaðarþýðingu og fyrir endurskrifun upprunans, og þess vegna nefnir reglan fang raunverulega forritsins. Lesið þessi tvö hook í þeirri röð hvenær sem regla virðist passa við neitt. Forward-regla skrifuð gegn samheitinu getur aldrei passað, því samheitið er ekki lengur til í því hooki.

Síða B endurtekur þetta með eigin samheiti og eigin lykli. Hún má ekki endurnýta einkalykil síðu A, því tveir jafningar sem deila einni auðkennu eru stillingarvilla sem er erfitt að sjá og auðvelt að búa til með því að afrita skrá. Haldið báðum gáttarskjölunum eins nema hvað varðar gildin sem verða að vera frábrugðin, svo munurinn standi upp úr við yfirferð. Afrituð skrá er venjuleg uppspretta þess galla.

Endurskrifun upprunans hefur kostnað. Forritið sér gáttina sem biðlara sinn, svo skrár þess sýna ekki lengur hvaða notandi tengdist. Haldið endurskoðunarferli gáttarinnar, og veikið ekki innskráningu forritsins til að bæta upp netauðkenni sem þýðingin fjarlægði.

Hvernig sanna á að bæði birtu nöfnin svari

Gefið hverju samheiti DNS-nafn og stillið forritið og skírteinið fyrir það nafn, því þýðing endurskrifar ekki tilvísanir eða innbyggða algilda URL. Notið eitt nafn á hverja síðu svo ósamræmi í skírteini verði aldrei ruglað saman við leiðsagnargalla.

Prófið frá raunverulega biðlaranum, staðfestið hvaða síða svaraði, og prófið líka óheimila gátt. Notið nýjar tengingar eftir hverja NAT-breytingu, því komið ástand heldur gömlu vörpuninni:

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

Tómt eða óvænt samheiti í fyrstu skipun þýðir að val jafningsins er rangt áður en nokkur eldveggjarregla skiptir máli. Ef samheitið er rétt og nafnið mistekst samt, hefur vandamálið flutt sig í DNS og skírteini. Þegar bæði nöfnin svara og þriðja gáttin helst lokuð, gerir hönnunin það sem hún segir: tvær þröngt birtar þjónustur, ekki tvö sameinuð LAN.

Tengdir greinar