Twee sites, één subnet, één WireGuard-hub: maak het werkend

Beide sites gebruiken dezelfde LAN-reeks, en de overlap is niet wat het ontwerp werkelijk breekt. De hub moet een site kiezen op basis van alleen het bestemmingsadres, en twee identieke bestemmingen geven hem niets om uit te kiezen. Een werkend kantoor hernummeren om een tunnel tevreden te stellen is meestal een slechtere ruil dan elke gepubliceerde dienst een eigen adres geven dat de tunnel kan dragen. Het ontwerp hieronder publiceert één HTTPS-dienst per site en niets anders.

Waarom de overlap niet het echte probleem is

WireGuard stuurt door op bestemming: de AllowedIPs van een peer bepalen welke peer een pakket ontvangt. Twee peers kunnen niet allebei 10.10.7.0/24 aankondigen zonder dat een van hen elke zoekopdracht wint. Dat is een eigenschap van de peertabel en niet van de tunnel, daarom is de oplossing hier een adresplan en geen routeringstruc.

Het plan is het LAN helemaal niet meer aan te kondigen. Kondig in plaats daarvan een alias per dienst aan, één adres per site, en laat de gateway van elke site die alias vertalen naar zijn echte applicatie.

De gebruiker routeert twee unieke adressen, ziet nooit het dubbelzinnige prefix, en niets verandert in een van beide kantoren. Dat benoemt ook de grens eerlijk: u publiceert één HTTPS-dienst per site, u voegt geen twee netwerken samen. De regels hieronder blijven klein omdat de uitspraak smal is. Een bredere uitspraak zou bredere regels vragen, en zo worden deze ontwerpen ingewikkeld.

Geef elke site een alias die de gebruiker kan routeren

Kies adressen uit een reeks die met niets op de machine van de gebruiker, de hub of een van beide LAN's botst. Hier is de hub 10.66.0.1, de gebruiker 10.66.0.10, de gateways 10.66.0.21 en 10.66.0.22, en de twee aliassen 10.77.1.20 en 10.77.2.20. De hub publiceert elke alias via de peer die hem bezit, zodat een uitgaand pakket naar één alias alleen via de bijbehorende site kan vertrekken:

[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

De gebruikerskant heeft alleen de twee aliassen nodig, wat de clientconfiguratie vrijhoudt van beide LAN-prefixen. Niets in die configuratie noemt een van de echte LAN's:

[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

Elke gateway kondigt de hub en de bron van de gebruiker aan, niets anders, zodat een site nooit het LAN van de andere leert. Keepalive houdt een NAT-mapping in stand op de uplink van de site; het autoriseert geen verkeer, en de firewall bepaalt nog steeds wat wordt toegelaten. De configuratie van de ene gateway naar de andere kopiëren is prima zolang de privésleutel, het interfaceadres en de alias allemaal veranderen.

Wat de hub tussen twee van zijn peers moet toestaan

De hub stuurt pakketten door tussen twee van zijn eigen peers, wat een beslissing in de forward-keten is en geen invoerbeslissing. Schakel IPv4-forwarding in via het gebruikelijke mechanisme van het platform en sta daarna precies de paren toe die het ontwerp nodig heeft.

De regel hieronder staat de gebruiker toe naar één alias en één poort, en staat retourverkeer toe via connection tracking. Hij laat al het overige op het forward-pad vallen, en dat is het punt:

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

Twee details zijn het vermelden waard omdat ze stille fouten veroorzaken. Een accept in de ene basisketen heft geen drop in een andere op, dus voeg dit samen met het bestaande beleid in plaats van het ernaast te laden. En het bronadres identificeert het apparaat, niet de persoon; houd applicatieauthenticatie gescheiden van netwerktoelating.

Waar een alias een echt adres wordt

Site A ontvangt een verzoek voor 10.77.1.20, herschrijft de bestemming naar de echte applicatie en herschrijft de bron naar zijn eigen LAN-adres zodat het antwoord kan terugkeren zonder een route naar de tunnel. Beide vertalingen op één plek doen houdt de rest van het netwerk onwetend van de alias. De regels hieronder zijn het hele mechanisme:

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

Het forward-beleid van site A moet dan de vertaalde stroom van de tunnelinterface naar de LAN-interface toestaan, plus de retourrichting. De forward-hook ziet de bestemming na de bestemmingsvertaling en vóór het herschrijven van de bron, daarom noemt de regel het adres van de echte applicatie. Lees die twee hooks in die volgorde wanneer een regel nergens op lijkt te passen. Een forward-regel die tegen de alias is geschreven kan nooit passen, omdat de alias op die hook niet meer bestaat.

Site B herhaalt dit met zijn eigen alias en zijn eigen sleutel. Hij mag de privésleutel van site A niet hergebruiken, omdat twee peers die één identiteit delen een configuratiefout is die moeilijk te zien en gemakkelijk te maken is door een bestand te kopiëren. Houd beide gatewaydocumenten identiek behalve de waarden die moeten verschillen, zodat het verschil opvalt bij de beoordeling. Een gekopieerd bestand is de gebruikelijke oorzaak van die fout.

Het herschrijven van de bron heeft een prijs. De applicatie ziet de gateway als haar client, dus haar logs tonen niet meer welke gebruiker verbinding maakte. Bewaar het auditspoor van de gateway, en verzwak de applicatielogin niet om een netwerkidentiteit te compenseren die de vertaling heeft verwijderd.

Hoe u bewijst dat beide gepubliceerde namen antwoorden

Geef elke alias een DNS-naam en configureer de applicatie en het certificaat voor die naam, omdat vertaling verwijzingen of ingebedde absolute URL's niet herschrijft. Gebruik één naam per site zodat een certificaatafwijking nooit voor een routeringsfout wordt aangezien.

Test vanaf de echte client, bevestig welke site heeft geantwoord, en test ook een niet-toegestane poort. Gebruik nieuwe verbindingen na elke NAT-wijziging, omdat gevestigde toestand de oude mapping behoudt:

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

Een lege of onverwachte alias in de eerste opdracht betekent dat de peerkeuze verkeerd is voordat enige firewallregel ertoe doet. Als de alias juist is en de naam toch faalt, is het probleem naar DNS en certificaten verschoven. Zodra beide namen antwoorden en de derde poort gesloten blijft, doet het ontwerp wat het beweert: twee smal gepubliceerde diensten, geen twee samengevoegde LAN's.