Divas vietnes, viens apakštīkls, viens WireGuard centrmezgls: liksim strādāt

Abi vietnes izmanto vienu un to pašu LAN diapazonu, un dizainu patiesībā nelauž pārklāšanās. Centrmezglam vietne jāizvēlas tikai pēc galamērķa adreses, un divi identiski galamērķi tam neko nedod izvēlei. Strādājoša biroja pārnumurēšana, lai apmierinātu tuneli, parasti ir sliktāks darījums nekā katram publicētajam pakalpojumam dot atsevišķu adresi, ko tunelis var pārnest. Zemāk redzamais dizains publicē vienu HTTPS pakalpojumu katrā vietnē un neko citu.

Kāpēc pārklāšanās nav īstā problēma

WireGuard pārsūta pēc galamērķa: vienaudža AllowedIPs nosaka, kurš vienaudzis saņems paketi. Divi vienaudži nevar abi pieteikt 10.10.7.0/24, ja vien viens no tiem neuzvar katrā meklēšanā. Tā ir vienaudžu tabulas, nevis tuneļa īpašība, tāpēc risinājums šeit ir adrešu plāns, nevis maršrutēšanas triks.

Plāns ir pilnībā pārtraukt LAN pieteikšanu. Tā vietā pieteikt alias katram pakalpojumam, vienu adresi katrai vietnei, un ļaut katras vietnes vārtejai pārtulkot šo alias savā īstajā lietojumprogrammā.

Lietotājs maršrutē divas unikālas adreses, nekad neredz divdomīgo prefiksu, un nevienā no diviem birojiem nekas nemainās. Tas arī godīgi nosauc robežu: jūs publicējat vienu HTTPS pakalpojumu no katras vietnes, nevis apvienojat divus tīklus. Turpmākie noteikumi paliek mazi, jo apgalvojums ir šaurs. Plašākam apgalvojumam vajadzētu plašākus noteikumus, un tieši tā šie dizaini kļūst sarežģīti.

Dodiet katrai vietnei alias, ko lietotājs var maršrutēt

Izvēlieties adreses no diapazona, kas nesaduras ar neko lietotāja mašīnā, centrmezglā vai kādā no diviem LAN. Šeit centrmezgls ir 10.66.0.1, lietotājs ir 10.66.0.10, vārtejas ir 10.66.0.21 un 10.66.0.22, un divi alias ir 10.77.1.20 un 10.77.2.20. Centrmezgls publicē katru alias caur to vienaudzi, kuram tas pieder, tāpēc izejošā pakete, kas adresēta vienam alias, var iziet tikai caur atbilstošo vietni:

[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

Lietotāja pusei vajag tikai divus alias, kas klienta konfigurāciju atstāj brīvu no abiem LAN prefiksiem. Nekas šajā konfigurācijā nemin nevienu īsto 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

Katra vārteja pieteic centrmezglu un lietotāja avotu, neko citu, tāpēc vietne nekad neuzzina otras vietnes LAN. Keepalive uztur NAT kartējumu vietnes augšuplinkā; tas neautorizē trafiku, un ugunsmūris joprojām izlemj, kas tiek ielaists. Vienas vārtejas konfigurācijas kopēšana otrā ir kārtībā, ja privātā atslēga, saskarnes adrese un alias visi mainās.

Kas centrmezglam jāatļauj starp diviem tā vienaudžiem

Centrmezgls pārsūta paketes starp diviem saviem vienaudžiem, un tas ir forward ķēdes lēmums, nevis ievades lēmums. Iespējojiet IPv4 pārsūtīšanu ar platformas parasto mehānismu, pēc tam atļaujiet tieši tos pārus, kas dizainam vajadzīgi.

Zemāk esošais noteikums ļauj lietotājam vienu alias un vienu portu, un atļauj atgriešanās trafiku, izmantojot savienojumu izsekošanu. Tas izmet visu pārējo forward ceļā, un tā ir jēga:

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

Divi sīkumi ir vērts pieminēt, jo tie izraisa klusas kļūmes. Accept vienā bāzes ķēdē neatceļ drop citā, tāpēc sapludiniet to ar esošo politiku, nevis ielādējiet to blakus. Un avota adrese identificē ierīci, nevis personu; turiet lietojumprogrammas autentifikāciju atsevišķi no tīkla pielaišanas.

Kur alias kļūst par īstu adresi

Vietne A saņem pieprasījumu uz 10.77.1.20, pārraksta galamērķi uz īsto lietojumprogrammu un pārraksta avotu uz savu LAN adresi, lai atbilde varētu atgriezties bez maršruta uz tuneli. Abu tulkojumu veikšana vienā vietā atstāj pārējo tīklu nezinošu par alias. Zemāk esošie noteikumi ir viss mehānisms:

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

Pēc tam vietnes A forward politikai jāatļauj pārtulkotā plūsma no tuneļa saskarnes uz LAN saskarni, plus atgriešanās virziens. Forward hook redz galamērķi pēc galamērķa tulkojuma un pirms avota pārrakstīšanas, tāpēc noteikums nosauc īstās lietojumprogrammas adresi. Lasiet šos divus hook šādā secībā, kad vien noteikums šķiet neatbilstošs nekam. Forward noteikums, kas rakstīts pret alias, nekad nevar atbilst, jo alias tajā hook vairs neeksistē.

Vietne B atkārto to ar savu alias un savu atslēgu. Tā nedrīkst atkārtoti izmantot vietnes A privāto atslēgu, jo divi vienaudži, kas dala vienu identitāti, ir konfigurācijas kļūda, ko ir grūti pamanīt un viegli radīt, kopējot failu. Turiet abus vārtejas dokumentus identiskus, izņemot vērtības, kurām jāatšķiras, lai atšķirība būtu pamanāma pārskatā. Nokopēts fails ir parastais šī defekta avots.

Avota pārrakstīšanai ir cena. Lietojumprogramma redz vārteju kā savu klientu, tāpēc tās žurnāli vairs nerāda, kurš lietotājs pievienojās. Saglabājiet vārtejas audita pēdas, un nevājiniet lietojumprogrammas pieteikšanos, lai kompensētu tīkla identitāti, ko tulkojums noņēma.

Kā pierādīt, ka abi publicētie nosaukumi atbild

Dodiet katram alias DNS nosaukumu un konfigurējiet lietojumprogrammu un sertifikātu šim nosaukumam, jo tulkojums nepārraksta pāradresācijas vai iegultos absolūtos URL. Izmantojiet vienu nosaukumu katrai vietnei, lai sertifikāta neatbilstība nekad netiktu sajaukta ar maršrutēšanas defektu.

Testējiet no īstā klienta, apstipriniet, kura vietne atbildēja, un pārbaudiet arī neatļautu portu. Pēc jebkuras NAT izmaiņas izmantojiet jaunus savienojumus, jo izveidotais stāvoklis saglabā veco kartējumu:

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

Tukšs vai negaidīts alias pirmajā komandā nozīmē, ka vienaudža izvēle ir nepareiza, pirms vēl kāds ugunsmūra noteikums kļūst svarīgs. Ja alias ir pareizs un nosaukums joprojām nedarbojas, problēma ir pārcēlusies uz DNS un sertifikātiem. Kad abi nosaukumi atbild un trešais ports paliek aizvērts, dizains dara to, ko apgalvo: divi šauri publicēti pakalpojumi, nevis divi apvienoti LAN.