Twa sites, ien subnet, ien WireGuard-hub: meitsje it oan 'e gong

Beide sites brûke deselde LAN-rige, en de oerlaap is net wat it ûntwerp echt brekt. De hub moat in site kieze op grûn fan allinnich it bestimmingsadres, en twa identike bestimmings jouwe him neat om mei te kiezen. In wurkjend kantoar fernûmerje om in tunnel te pas te meitsjen is meastentiids in minner ruil as it jaan fan in eigen adres oan elke publisearre tsjinst dat de tunnel drage kin. It ûntwerp hjirûnder publisearret ien HTTPS-tsjinst per site en fierder neat.

Wêrom't de oerlaap net it echte probleem is

WireGuard stjoert op basis fan bestimming: de AllowedIPs fan in peer beslisse hokker peer in pakket krijt. Twa peers kinne net beide 10.10.7.0/24 oankundigje sûnder dat ien fan har elke syktocht wint. Dat is in eigenskip fan de peertabel en net fan de tunnel, dêrom is de oplossing hjir in adresplan en net in trúk mei rûtes.

It plan is om hielendal op te hâlden mei it oankundigjen fan it LAN. Kundigje ynstee in alias per tsjinst oan, ien adres per site, en lit de poarte fan elke site dat alias oersette nei syn echte applikaasje.

De brûker rûteset twa unike adressen, sjocht nea it dûbelsinnige foarheaksel, en yn gjin fan beide kantoaren feroaret wat. Dat seit ek de grins earlik: jo publisearje ien HTTPS-tsjinst fan elke site, jo foegje net twa netwurken gear. De regels hjirûnder bliuwe lyts omdat de bewearing smel is. In bredere bewearing soe bredere regels nedich hawwe, en sa wurde dizze ûntwerpen yngewikkeld.

Jou elke site in alias dat de brûker rûtesje kin

Kies adressen út in berik dat net botset mei neat op de masine fan de brûker, de hub of ien fan beide LAN's. Hjir is de hub 10.66.0.1, de brûker 10.66.0.10, de poarten 10.66.0.21 en 10.66.0.22, en de twa aliassen 10.77.1.20 en 10.77.2.20. De hub publisearret elk alias fia de peer dy't it besit, sadat in útgeand pakket nei ien alias allinnich fia de oerienkommende site fuortgean kin:

[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 brûkerskant hat allinnich de twa aliassen nedich, wat de kliïntkonfiguraasje frij hâldt fan beide LAN-foarheaksels. Neat yn dy konfiguraasje neamt ien fan 'e 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 poarte kundiget de hub en de boarne fan de brûker oan, fierder neat, sadat in site nea it LAN fan de oare site leart. Keepalive hâldt in NAT-mapping yn stân op de uplink fan de site; it autorisearret gjin ferkear, en de firewall beslút noch hieltyd wat talitten wurdt. De konfiguraasje fan ien poarte nei de oare kopiearje is goed, salang't de priveekaai, it ynterface-adres en it alias allegear feroarje.

Wat de hub tusken twa fan syn peers talitte moat

De hub stjoert pakketten tusken twa fan syn eigen peers, dat is in beslút yn 'e forward-kettinge en net in ynfierbeslút. Skeakelje IPv4-foarstjoering yn fia it normale meganisme fan it platfoarm, en talit dan krekt de pearen dy't it ûntwerp nedich hat.

De regel hjirûnder lit de brûker ta nei ien alias en ien poarte, en lit weromferkear ta fia ferbiningsopspoaring. It smyt al it oare op it forward-paad fuort, en dat is it 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

Twa details binne it neamen wurdich, want se feroarsaakje stille flaters. In accept yn ien basisketting heftet gjin drop yn in oare op, dus smyt dit gear mei it besteande belied ynstee fan it derneist te laden. En it boarneradres identifisearret it apparaat, net de persoan; hâld applikaasje-autentikaasje skieden fan netwurktalitting.

Wêr't in alias in echt adres wurdt

Site A krijt in fersyk foar 10.77.1.20, skriuwt de bestimming oer nei de echte applikaasje, en skriuwt de boarne oer nei syn eigen LAN-adres sadat it antwurd weromkomme kin sûnder in rûte nei de tunnel. Beide oersettings op ien plak dwaan hâldt de rest fan it netwurk ûnwittend oer it alias. De regels hjirûnder binne it hiele meganisme:

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

It forward-belied fan site A moat dan de oersette stream fan 'e tunnel-ynterface nei de LAN-ynterface talitte, plus de weromrjochting. De forward-hook sjocht de bestimming nei de bestimmingsoersetting en foar it oerskriuwen fan 'e boarne, dêrom neamt de regel it adres fan de echte applikaasje. Lês dy twa hooks yn dy folchoarder as in regel liket dat er nearne by past. In forward-regel skreaun tsjin it alias kin nea passe, want it alias bestiet dêr net mear op dy hook.

Site B werhellet dit mei syn eigen alias en syn eigen kaai. It mei de priveekaai fan site A net opnij brûke, want twa peers dy't ien identiteit diele is in konfiguraasjeflake dy't dreech te sjen en maklik te meitsjen is troch in bestân te kopiearjen. Hâld beide poartedokuminten identyk útsein de wearden dy't ferskille moatte, sadat it ferskil by it neisjen opfalt. In kopiaerre bestân is de gewoane oarsprong fan dy flake.

It oerskriuwen fan 'e boarne hat in priis. De applikaasje sjocht de poarte as syn klant, dus syn logs litte net mear sjen hokker brûker ferbûn wie. Hâld it auditspoar fan 'e poarte, en ferswakje de oanmelding fan 'e applikaasje net om te kompensearjen foar in netwurkidentiteit dy't de oersetting fuorthelle hat.

Hoe't jo bewize dat beide publisearre nammen antwurdzje

Jou elk alias in DNS-namme en konfigurearje de applikaasje en it sertifikaat foar dy namme, want oersetting skriuwt gjin trochstjoeringen of ynbêde absolute URL's oer. Brûk ien namme per site, sadat in sertifikaatmisferstân nea foar in rûteflater oansjoen wurde kin.

Test fan 'e echte klant, befêstigje hokker site antwurde, en test ek in net-autorisearre poarte. Brûk nije ferbiningen nei elke NAT-feroaring, want fêstige steat hâldt de âlde mapping:

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

In leech of ûnferwachts alias yn 'e earste opdracht betsjut dat de peerkarring ferkeard is foardat ien firewall-regel fan belang is. As it alias goed is en de namme dochs mislearret, is it probleem nei DNS en sertifikaten ferhuze. Sadree't beide nammen antwurdzje en de tredde poarte ticht bliuwt, docht it ûntwerp wat it seit: twa smel publisearre tsjinsten, net twa gearfoege LAN's.