Dalawang site, isang subnet, isang hub ng WireGuard: paganahin ito

Ginagamit ng dalawang site ang parehong saklaw ng LAN, at ang overlap ay hindi ang talagang sumisira sa disenyo. Dapat pumili ang hub ng site gamit lamang ang address ng destinasyon, at dalawang magkaparehong destinasyon ay walang ibinibigay na mapagpipilian. Ang muling pag-numero ng gumaganang opisina para masiyahan ang isang tunnel ay karaniwang mas masamang palitan kaysa bigyan ang bawat nailathalang serbisyo ng natatanging address na kayang dalhin ng tunnel. Ang disenyo sa ibaba ay naglalathala ng isang serbisyong HTTPS bawat site at wala nang iba.

Bakit ang overlap ay hindi ang tunay na problema

Nagpapasa ang WireGuard ayon sa destinasyon: ang AllowedIPs ng isang peer ang nagpapasya kung aling peer ang makakatanggap ng packet. Hindi maaaring parehong mag-anunsyo ang dalawang peer ng 10.10.7.0/24 nang walang isa sa kanilang nananalo sa bawat paghahanap. Iyon ay katangian ng talahanayan ng peer at hindi ng tunnel, kaya ang solusyon dito ay isang plano ng address at hindi isang pakulo sa routing.

Ang plano ay tigilan ang pag-anunsyo ng LAN nang lubusan. Sa halip, mag-anunsyo ng alias bawat serbisyo, isang address bawat site, at hayaang isalin ng gateway ng bawat site ang alias na iyon sa tunay nitong aplikasyon.

Ang gumagamit ay nagru-ruta ng dalawang natatanging address, hindi kailanman nakikita ang malabong prefix, at walang nagbabago sa alinman sa dalawang opisina. Sinasabi rin nito ang hangganan nang tapat: naglalathala ka ng isang serbisyong HTTPS mula sa bawat site, hindi ka naghahalo ng dalawang network. Ang mga patakarang sumusunod ay nananatiling maliit dahil makitid ang pahayag. Ang mas malawak na pahayag ay mangangailangan ng mas malawak na patakaran, at ganoon nagiging kumplikado ang mga disenyong ito.

Bigyan ang bawat site ng alias na kayang i-ruta ng gumagamit

Pumili ng address mula sa saklaw na hindi tumatama sa anuman sa makina ng gumagamit, sa hub o sa alinman sa dalawang LAN. Dito ang hub ay 10.66.0.1, ang gumagamit ay 10.66.0.10, ang mga gateway ay 10.66.0.21 at 10.66.0.22, at ang dalawang alias ay 10.77.1.20 at 10.77.2.20. Inilalathala ng hub ang bawat alias sa pamamagitan ng peer na nagmamay-ari nito, kaya ang palabas na packet na patungo sa isang alias ay makakalabas lamang sa katugmang site:

[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

Ang panig ng gumagamit ay kailangan lamang ang dalawang alias, na nagpapanatiling malaya ang configuration ng client mula sa dalawang prefix ng LAN. Walang anuman sa configuration na iyon ang nagbabanggit ng alinman sa tunay na 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

Ang bawat gateway ay nag-anunsyo ng hub at ng pinagmulan ng gumagamit, wala nang iba, kaya hindi kailanman natututuhan ng isang site ang LAN ng isa pa. Ang Keepalive ay nagpapanatili ng NAT mapping sa uplink ng site; hindi ito nagbibigay ng pahintulot sa trapiko, at ang firewall pa rin ang nagpapasya kung ano ang tatanggapin. Ang pagkopya ng configuration ng isang gateway sa isa pa ay maayos hangga't nagbabago ang pribadong susi, address ng interface at alias.

Ano ang dapat payagan ng hub sa pagitan ng dalawa nitong peer

Nagpapasa ang hub ng packet sa pagitan ng dalawa nitong peer, na desisyon sa forward chain at hindi desisyon sa input. Paganahin ang IPv4 forwarding sa karaniwang mekanismo ng platform, pagkatapos ay payagan ang eksaktong mga pares na kailangan ng disenyo.

Ang patakaran sa ibaba ay nagpapahintulot sa gumagamit patungo sa isang alias at isang port, at nagpapahintulot ng pabalik na trapiko sa pamamagitan ng pagsubaybay ng koneksyon. Itinatapon nito ang lahat ng iba pa sa forward path, at iyon ang punto:

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

Dalawang detalye ang dapat banggitin dahil nagdudulot sila ng tahimik na pagkabigo. Ang accept sa isang base chain ay hindi nanaig sa drop sa iba, kaya pagsamahin ito sa umiiral na patakaran sa halip na i-load ito sa tabi. At ang source address ay tumutukoy sa device, hindi sa tao; panatilihing hiwalay ang authentication ng aplikasyon sa pagtanggap ng network.

Kung saan nagiging tunay na address ang alias

Tumatanggap ang site A ng kahilingan para sa 10.77.1.20, muling isinulat ang destinasyon patungo sa tunay na aplikasyon, at muling isinulat ang pinagmulan patungo sa sarili nitong address ng LAN upang makabalik ang sagot nang walang ruta patungo sa tunnel. Ang paggawa ng dalawang pagsasalin sa isang lugar ay nagpapanatiling walang kaalaman ang natitirang network tungkol sa alias. Ang mga patakaran sa ibaba ang buong 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

Pagkatapos ay dapat payagan ng forward policy ng site A ang isinaling daloy mula sa interface ng tunnel patungo sa interface ng LAN, kasama ang direksyon ng pagbabalik. Nakikita ng forward hook ang destinasyon pagkatapos ng pagsasalin ng destinasyon at bago ang muling pagsulat ng pinagmulan, kaya binabanggit ng patakaran ang address ng tunay na aplikasyon. Basahin ang dalawang hook na iyon sa ganoong pagkakasunod-sunod sa tuwing may patakarang tila walang katugma. Ang forward rule na isinulat laban sa alias ay hindi kailanman maaaring tumugma, dahil wala nang alias sa hook na iyon.

Inuulit ito ng site B gamit ang sariling alias at sariling susi. Hindi nito dapat gamitin muli ang pribadong susi ng site A, dahil ang dalawang peer na nagbabahagi ng isang pagkakakilanlan ay error sa configuration na mahirap makita at madaling gawin sa pamamagitan ng pagkopya ng file. Panatilihing magkapareho ang dalawang dokumento ng gateway maliban sa mga value na dapat magkaiba, upang lumitaw ang pagkakaiba sa pagsusuri. Ang kinopyang file ang karaniwang pinagmulan ng depektong iyon.

May halaga ang muling pagsulat ng pinagmulan. Nakikita ng aplikasyon ang gateway bilang kliyente nito, kaya hindi na ipinapakita ng mga log nito kung sinong gumagamit ang kumonekta. Panatilihin ang audit trail ng gateway, at huwag pahinain ang pag-login ng aplikasyon para mabayaran ang pagkakakilanlan sa network na inalis ng pagsasalin.

Paano patunayan na tumutugon ang dalawang nailathalang pangalan

Bigyan ang bawat alias ng pangalang DNS at i-configure ang aplikasyon at sertipiko para sa pangalang iyon, dahil hindi muling isinusulat ng pagsasalin ang mga redirect o naka-embed na absolute URL. Gumamit ng isang pangalan bawat site upang ang hindi pagtutugma ng sertipiko ay hindi kailanman mapagkamalang sira sa routing.

Subukan mula sa tunay na kliyente, kumpirmahin kung aling site ang tumugon, at subukan din ang hindi awtorisadong port. Gumamit ng mga bagong koneksyon pagkatapos ng anumang pagbabago sa NAT, dahil pinapanatili ng established state ang lumang mapping:

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

Ang walang laman o hindi inaasahang alias sa unang utos ay nangangahulugang mali ang pagpili ng peer bago pa maging mahalaga ang anumang patakaran ng firewall. Kung tama ang alias at nabigo pa rin ang pangalan, lumipat na ang problema sa DNS at mga sertipiko. Kapag tumugon ang dalawang pangalan at nanatiling sarado ang ikatlong port, ginagawa ng disenyo ang sinasabi nito: dalawang serbisyong makitid ang paglalathala, hindi dalawang pinagsamang LAN.