To steder, ét subnet, én WireGuard-hub: få det til at virke

Begge steder bruger samme LAN-interval, og overlapningen er ikke det, der egentlig ødelægger designet. Hubben skal vælge et sted udelukkende ud fra destinationsadressen, og to identiske destinationer giver den intet at vælge med. At omnummerere et kontor, der virker, for at tilfredsstille en tunnel er som regel en dårligere handel end at give hver publiceret tjeneste en adresse, som tunnelen kan bære. Designet nedenfor publicerer én HTTPS-tjeneste per sted og intet andet.

Hvorfor overlapningen ikke er det egentlige problem

WireGuard videresender efter destination: en peers AllowedIPs afgør, hvilken peer et paket havner hos. To peers kan ikke begge annoncere 10.10.7.0/24 uden at en af dem vinder hvert opslag. Det er en egenskab ved peer-tabellen og ikke ved tunnelen, og derfor er løsningen her en adresseplan og ikke et routing-trick.

Planen er helt at holde op med at annoncere LAN'et. Annoncér i stedet et alias per tjeneste, én adresse per sted, og lad hvert steds gateway oversætte aliaset til sin rigtige applikation.

Brugeren router to unikke adresser, ser aldrig det tvetydige præfiks, og intet ændrer sig i noget af de to kontorer. Det siger også grænsen ærligt: du publicerer én HTTPS-tjeneste fra hvert sted, ikke sammenlægger to netværk. Reglerne nedenfor forbliver små, fordi udsagnet er snævert. Et bredere udsagn ville kræve bredere regler, og det er sådan, disse design bliver komplicerede.

Giv hvert sted et alias, som brugeren kan route

Vælg adresser fra et interval, der ikke støder mod noget på brugerens maskine, på hubben eller i noget af de to LAN. Her er hubben 10.66.0.1, brugeren 10.66.0.10, gatewayene 10.66.0.21 og 10.66.0.22, og de to aliaser 10.77.1.20 og 10.77.2.20. Hubben publicerer hvert alias gennem den peer, der ejer det, så en udgående pakke adresseret til et alias kun kan forlade gennem det matchende sted:

[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

Brugersiden har kun brug for de to aliaser, hvilket holder klientkonfigurationen fri af begge LAN-præfikser. Intet i den konfiguration nævner noget af de rigtige 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

Hver gateway annoncerer hubben og brugerens kilde, intet andet, så et sted lærer aldrig det andet steds LAN at kende. Keepalive opretholder en NAT-mapping på stedets uplink; det autoriserer ikke trafik, og firewallen afgør stadig, hvad der lukkes ind. At kopiere den ene gateways konfiguration til den anden er fint, så længe den private nøgle, interface-adressen og aliaset alle ændres.

Hvad hubben skal tillade mellem to af sine peers

Hubben videresender pakker mellem to af sine egne peers, hvilket er en beslutning i forward-kæden og ikke en input-beslutning. Aktivér IPv4-forwarding gennem platformens sædvanlige mekanisme, og tillad derefter præcis de par, designet har brug for.

Reglen nedenfor tillader brugeren ét alias og én port og tillader returtrafik gennem connection tracking. Den dropper alt andet på forward-vejen, og det er pointen:

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

To detaljer er værd at nævne, fordi de giver stille fejl. En accept i en basiskæde tilsidesætter ikke en drop i en anden, så flet dette sammen med den eksisterende politik i stedet for at indlæse det ved siden af. Og kildeadressen identificerer enheden, ikke personen; hold applikationsgodkendelse adskilt fra netværksadgang.

Hvor et alias bliver en rigtig adresse

Sted A modtager en anmodning til 10.77.1.20, omskriver destinationen til den rigtige applikation og omskriver kilden til sin egen LAN-adresse, så svaret kan vende tilbage uden en rute til tunnelen. At gøre begge oversættelser ét sted holder resten af netværket uvidende om aliaset. Reglerne nedenfor er hele mekanismen:

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

Sted A's forward-politik skal derefter tillade den oversatte strøm fra tunnelinterfacet til LAN-interfacet plus returretningen. Forward-hooket ser destinationen efter destinationsoversættelsen og før kildeomskrivningen, og derfor nævner reglen den rigtige applikations adresse. Læs de to hooks i den rækkefølge, når en regel ser ud til ikke at matche noget. En forward-regel skrevet mod aliaset kan aldrig matche, fordi aliaset ikke længere findes i det hook.

Sted B gentager dette med sit eget alias og sin egen nøgle. Det må ikke genbruge sted A's private nøgle, fordi to peers, der deler én identitet, er en konfigurationsfejl, som er svær at se og let at lave ved at kopiere en fil. Hold begge gateway-dokumenter identiske bortset fra de værdier, der skal være forskellige, så forskellen springer i øjnene ved gennemlæsning. En kopieret fil er den sædvanlige oprindelse til den fejl.

Kildeomskrivningen har en pris. Applikationen ser gatewayen som sin klient, så dens logfiler viser ikke længere, hvilken bruger der har forbundet. Behold gatewayens revisionsspor, og svæk ikke applikationslogin for at kompensere for en netværksidentitet, som oversættelsen fjernede.

Sådan beviser du, at begge offentliggjorte navne svarer

Giv hvert alias et DNS-navn, og konfigurér applikationen og certifikatet til det navn, fordi oversættelse ikke omskriver viderekoblinger eller indlejrede absolutte URL'er. Brug ét navn per sted, så en certifikatmismatch aldrig kan forveksles med en routingfejl.

Test fra den rigtige klient, bekræft hvilket sted der svarede, og test også en uautoriseret port. Brug nye forbindelser efter enhver NAT-ændring, fordi etableret tilstand beholder den gamle mapping:

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

Et tomt eller uventet alias i den første kommando betyder, at peer-valget er forkert, før nogen firewallregel har betydning. Hvis aliaset er rigtigt, og navnet stadig fejler, er problemet flyttet til DNS og certifikater. Når begge navne svarer, og den tredje port forbliver lukket, gør designet, hvad det lover: to snævert publicerede tjenester, ikke to sammenlagte LAN.