Bi gune, azpisare bat, WireGuard hub bat: jar ezazu martxan

Bi guneek LAN-tarte bera erabiltzen dute, eta gainjartzea ez da diseinua benetan hausten duena. Hub-ak gune bat helmugako helbidea soilik erabiliz aukeratu behar du, eta bi helmuga berdin-berdinek ez diote aukeratzeko ezer ematen. Funtzionatzen duen bulego bat tunel bat betetzeko berriz zenbakitzea, normalean, truke okerragoa da tunelak eraman dezakeen helbide bereizi bat zerbitzu argitaratu bakoitzari ematea baino. Beheko diseinuak HTTPS zerbitzu bat argitaratzen du gune bakoitzeko, eta besterik ez.

Zergatik gainjartzea ez den benetako arazoa

WireGuard-ek helmugaren arabera birbidaltzen du: peer baten AllowedIPs-ek erabakitzen dute zein peer-ek jasoko duen paketea. Bi peer-ek ezin dute biak 10.10.7.0/24 iragarri, horietako batek bilaketa guztiak irabazi gabe. Hori peer taularen ezaugarria da, ez tunelarena, eta horregatik hemen konponbidea helbide-plana da, ez bideratze-trikia.

Plana LAN-a erabat iragartzeari uztea da. Horren ordez, iragarri alias bat zerbitzu bakoitzeko, helbide bat gune bakoitzeko, eta utzi gune bakoitzeko atebideak alias hori bere aplikazio errealera itzul dezan.

Erabiltzaileak bi helbide bakar bideratzen ditu, ez du inoiz aurrizki anbiguoa ikusten, eta bi bulegoetan ez da ezer aldatzen. Horrek muga ere zintzo adierazten du: gune bakoitzetik HTTPS zerbitzu bat argitaratzen ari zara, ez bi sare batzen. Ondorengo arauak txiki mantentzen dira adierazpena estua delako. Adierazpen zabalago batek arau zabalagoak beharko lituzke, eta horrela bihurtzen dira diseinu hauek konplexu.

Eman gune bakoitzari erabiltzaileak bidera dezakeen alias bat

Aukeratu helbideak erabiltzailearen makinan, hub-aan edo bi LAN-etako edozeinetan ezerrekin talka egiten ez duen tarte batetik. Hemen hub-a 10.66.0.1 da, erabiltzailea 10.66.0.10, atebideak 10.66.0.21 eta 10.66.0.22, eta bi alias-ak 10.77.1.20 eta 10.77.2.20. Hub-ak alias bakoitza duen peer-aren bidez argitaratzen du, beraz alias batera zuzendutako irteerako paketea dagokion gunetik soilik irten daiteke:

[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

Erabiltzailearen aldeak bi alias-ak soilik behar ditu, eta horrek bezeroaren konfigurazioa bi LAN aurrizkietatik libre uzten du. Konfigurazio horretan ezerk ez du LAN errealetako bat ere aipatzen:

[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

Atebide bakoitzak hub-a eta erabiltzailearen iturburua iragartzen ditu, besterik ez, beraz gune batek ez du inoiz bestearen LAN-a ezagutzen. Keepalive-k NAT mapaketa bat mantentzen du gunearen uplink-ean; ez du trafikoa baimendu, eta suebakiak erabakitzen du oraindik zer onartzen den. Atebide baten konfigurazioa bestera kopiatzea ondo dago, baldin eta gako pribatua, interfazearen helbidea eta alias-a guztiak aldatzen badira.

Zer onartu behar du hub-ak bere bi peeren artean

Hub-ak paketeak birbidaltzen ditu bere peer bi artean, hau forward katearen erabakia da, ez sarrerako erabakia. Gaitu IPv4 birbidalketa plataformaren ohiko mekanismoaren bidez, eta gero onartu diseinuak behar dituen bikoteak zehazki.

Beheko arauak erabiltzaileari alias bat eta portu bat onartzen dizkio, eta itzulera-trafikoa onartzen du konexioen jarraipenaren bidez. Forward bidean beste guztia baztertzen du, eta hori da kontua:

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

Bi xehetasun aipatzekoak dira, isilpeko hutsegiteak eragiten dituztelako. Oinarrizko kate bateko accept-ek ez du besteko drop bat gainidazten, beraz nahastu hau lehendik dagoen politikarekin, ez kargatu haren ondoan. Eta iturburu-helbideak gailua identifikatzen du, ez pertsona; mantendu aplikazioaren autentifikazioa sareko onarpenetik bereizita.

Non bihurtzen den alias-a benetako helbide

A guneak 10.77.1.20-rako eskaera bat jasotzen du, helmuga aplikazio errealera berridazten du, eta iturburua bere LAN helbidera berridazten du, erantzunak tunelera bideratu beharrik gabe itzul dadin. Bi itzulpenak leku berean egiteak sarearen gainerakoa alias-aren ezjakinean uzten du. Beheko arauak mekanismo osoa dira:

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

A gunearen forward politikak itzulitako fluxua onartu behar du tunelaren interfazetik LAN interfazera, gehi itzulera norabidea. Forward hook-ak helmuga ikusten du helmuga-itzulpenaren ondoren eta iturburuaren berridazketa baino lehen, horregatik arauak aplikazio errealaren helbidea aipatzen du. Irakurri bi hook horiek ordena horretan, arau batek ezerrekin bat egiten ez duela dirudienean. Alias-aren aurka idatzitako forward arau batek ezin du inoiz bat egin, alias-a ez baita hook horretan existitzen jada.

B guneak bere alias-arekin eta bere gakoarekin errepikatzen du hau. Ez du A gunearen gako pribatua berrerabili behar, bi peer-ek identitate bat partekatzea konfigurazio-errorea baita, ikusteko zaila eta fitxategi bat kopiatuz sortzeko erraza. Mantendu bi atebideen dokumentuak berdinak, desberdin izan behar duten balioak salbu, ezberdintasuna berrikuspenean nabarmendu dadin. Kopiatutako fitxategi bat da akats horren ohiko jatorria.

Iturburuaren berridazketak kostu bat du. Aplikazioak atebidea bere bezero gisa ikusten du, beraz bere erregistroek ez dute jada erakusten zein erabiltzaile konektatu zen. Mantendu atebidearen auditoria-arrastoa, eta ez ahuldu aplikazioaren saioa, itzulpenak kendu zuen sare-identitatea konpentsatzeko.

Nola frogatu argitaratutako bi izenek erantzuten dutela

Eman alias bakoitzari DNS izen bat eta konfiguratu aplikazioa eta ziurtagiria izen horretarako, itzulpenak ez baititu berbideratzeak edo txertatutako URL absolutuak berridazten. Erabili izen bat gune bakoitzeko, ziurtagiri-desadostasuna inoiz bideratze-hutsegitearekin nahas ez dadin.

Probatu benetako bezerotik, egiaztatu zein gunek erantzun zuen, eta probatu baimenik gabeko portu bat ere. Erabili konexio berriak NAT aldaketa bakoitzaren ondoren, ezarritako egoerak mapaketa zaharra mantentzen baitu:

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

Lehen komandoko alias huts batek edo ustekabeko batek peer hautaketa okerra dela esan nahi du, suebaki-arau batek garrantzirik izan baino lehen. Alias-a zuzena bada eta izenak oraindik huts egiten badu, arazoa DNS eta ziurtagirietara joan da. Bi izenek erantzun eta hirugarren portua itxita geratzen denean, diseinuak dioena egiten du: estuki argitaratutako bi zerbitzu, ez bi LAN batuta.