Du retejoj, unu subreto, unu WireGuard-koncentrilo: funkciigu ĝin

Ambaŭ LAN-oj sidas sur 10.10.7.0/24, do la koncentrilo ne povas elekti retejon laŭ celo. Donu al ĉiu servo pseŭdonimon kaj traduku ĉe ĝia pordego.

Ambaŭ retejoj uzas la saman LAN-gamon, kaj la koincido ne estas tio, kio fakte rompas la dezajnon. La koncentrilo devas elekti retejon nur laŭ la celloka adreso, kaj du identaj celoj donas al ĝi nenion por elekti. Renumeri funkciantan oficejon por kontentigi tunelon kutime estas pli malbona interŝanĝo ol doni al ĉiu publikigita servo apartan adreson, kiun la tunelo povas porti. La suba dezajno publikigas unu HTTPS-servon por retejo kaj nenion alian.

Kial la koincido ne estas la vera problemo

WireGuard plusendas laŭ celo: la AllowedIPs de peer decidas, kiu peer ricevas paketon. Du peer ne povas ambaŭ anonci 10.10.7.0/24 sen ke unu el ili gajnas ĉiun serĉon. Tio estas eco de la peer-tabelo, ne de la tunelo, tial la solvo ĉi tie estas adresplano, ne ruzo pri enkursigado.

La plano estas tute ĉesi anonci la LAN-on. Anoncu anstataŭe pseŭdonimon por ĉiu servo, unu adreson por retejo, kaj lasu la pordegon de ĉiu retejo traduki tiun pseŭdonimon al sia reala aplikaĵo.

La uzanto enkursigas du unikajn adresojn, neniam vidas la ambiguan prefikson, kaj nenio ŝanĝiĝas en iu ajn el la du oficejoj. Tio ankaŭ honeste nomigas la limon: vi publikigas unu HTTPS-servon el ĉiu retejo, ne kunfandas du retojn. La sekvaj reguloj restas malgrandaj, ĉar la aserto estas mallarĝa. Pli larĝa aserto bezonus pli larĝajn regulojn, kaj tiel ĉi tiuj dezajnoj komplikiĝas.

Donu al ĉiu retejo pseŭdonimon, kiun la uzanto povas enkursigi

Elektu adresojn el gamo, kiu konfliktas kun nenio sur la maŝino de la uzanto, la koncentrilo aŭ iu el la du LAN-oj. Ĉi tie la koncentrilo estas 10.66.0.1, la uzanto estas 10.66.0.10, la pordegoj estas 10.66.0.21 kaj 10.66.0.22, kaj la du pseŭdonimoj estas 10.77.1.20 kaj 10.77.2.20. La koncentrilo publikigas ĉiun pseŭdonimon tra la peer, kiu posedas ĝin, do eliranta paketo adresita al unu pseŭdonimo povas eliri nur tra la responda retejo:

[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

La uzanta flanko bezonas nur la du pseŭdonimojn, kio tenas la klientan agordon libera de ambaŭ LAN-prefiksoj. Nenio en tiu agordo mencias iun el la realaj LAN-oj:

[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

Ĉiu pordego anoncas la koncentrilon kaj la fonton de la uzanto, nenion alian, do retejo neniam ekscias la LAN-on de la alia. Keepalive konservas NAT-mapadon sur la suprenligo de la retejo; ĝi ne rajtigas trafikon, kaj la fajroŝirmilo ankoraŭ decidas, kio estas allasata. Kopii la agordon de unu pordego al la alia estas en ordo kondiĉe ke la privata ŝlosilo, la interfaca adreso kaj la pseŭdonimo ĉiuj ŝanĝiĝas.

Kion la koncentrilo devas permesi inter du el siaj peer

La koncentrilo plusendas paketojn inter du el siaj propraj peer, kio estas decido en la forward-ĉeno, ne eniga decido. Ŝaltu IPv4-plusendadon per la kutima mekanismo de la platformo, poste permesu ĝuste la parojn, kiujn la dezajno bezonas.

La suba regulo permesas al la uzanto unu pseŭdonimon kaj unu pordon, kaj permesas revenan trafikon per spurado de konektoj. Ĝi forĵetas ĉion alian sur la forward-vojo, kaj tio estas la celo:

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

Du detaloj indas mencii, ĉar ili kaŭzas silentajn fiaskojn. Accept en unu baza ĉeno ne superregas drop en alia, do kunfandu ĉi tion kun la ekzistanta politiko anstataŭ ŝargi ĝin apude. Kaj la fonta adreso identigas la aparaton, ne la personon; tenu la aplikaĵan aŭtentikigon aparta de la reta allaso.

Kie pseŭdonimo fariĝas reala adreso

Retejo A ricevas peton por 10.77.1.20, reskribas la celon al la reala aplikaĵo kaj reskribas la fonton al sia propra LAN-adreso, por ke la respondo povu reveni sen enkursigilo al la tunelo. Fari ambaŭ tradukojn en unu loko tenas la reston de la reto senscia pri la pseŭdonimo. La subaj reguloj estas la tuta mekanismo:

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

La forward-politiko de retejo A devas poste allasi la tradukitan fluon de la tunela interfaco al la LAN-interfaco, plus la revenan direkton. La forward-hoko vidas la celon post la cela traduko kaj antaŭ la fonta reskribo, tial la regulo nomas la adreson de la reala aplikaĵo. Legu tiujn du hokojn en tiu ordo kiam ajn regulo ŝajnas ne kongrui kun io. Forward-regulo skribita kontraŭ la pseŭdonimo neniam povas kongrui, ĉar la pseŭdonimo ne plu ekzistas ĉe tiu hoko.

Retejo B ripetas tion kun sia propra pseŭdonimo kaj sia propra ŝlosilo. Ĝi ne rajtas reuzi la privatan ŝlosilon de retejo A, ĉar du peer, kiuj dividas unu identecon, estas agorda eraro, kiun estas malfacile vidi kaj facile krei per kopiado de dosiero. Tenu ambaŭ pordegajn dokumentojn identaj krom la valoroj, kiuj devas malsami, por ke la diferenco evidentiĝu dum revizio. Kopiita dosiero estas la kutima origino de tiu difekto.

La fonta reskribo havas prezon. La aplikaĵo vidas la pordegon kiel sian klienton, do ĝiaj protokoloj ne plu montras, kiu uzanto konektiĝis. Tenu la reviziaĵan spuron de la pordego, kaj ne malfortigu la ensaluton de la aplikaĵo por kompensi retan identecon, kiun la traduko forprenis.

Kiel pruvi, ke ambaŭ publikigitaj nomoj respondas

Donu al ĉiu pseŭdonimo DNS-nomon kaj agordu la aplikaĵon kaj la atestilon por tiu nomo, ĉar traduko ne reskribas alidirektadojn aŭ enmetitajn absolutajn URL-ojn. Uzu unu nomon por retejo, por ke atestila malkongruo neniam povu esti konfuzita kun enkursiga misfunkcio.

Testu el la reala kliento, konfirmu, kiu retejo respondis, kaj testu ankaŭ nepermesitan pordon. Uzu novajn konektojn post ajna NAT-ŝanĝo, ĉar establita stato konservas la malnovan mapadon:

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

Malplena aŭ neatendita pseŭdonimo en la unua komando signifas, ke la peer-elekto estas malĝusta antaŭ ol iu ajn fajroŝirmila regulo gravas. Se la pseŭdonimo estas ĝusta kaj la nomo tamen fiaskas, la problemo moviĝis al DNS kaj atestiloj. Post kiam ambaŭ nomoj respondas kaj la tria pordo restas fermita, la dezajno faras tion, kion ĝi asertas: du mallarĝe publikigitaj servoj, ne du kunfanditaj LAN-oj.

Rilataj artikoloj