Две локации, една подмрежа, еден WireGuard центар: направете го да работи

Двете локации користат ист LAN опсег, а дизајнот всушност не го расипува преклопувањето. Центарот мора да избере локација само според адресата на одредиштето, а две идентични одредишта не му даваат ништо за избор. Пренумерувањето на канцеларија што работи за да се задоволи тунел обично е полоша размена отколку да се даде на секоја објавена услуга посебна адреса што тунелот може да ја носи. Дизајнот подолу објавува една HTTPS услуга по локација и ништо друго.

Зошто преклопувањето не е вистинскиот проблем

WireGuard препраќа според одредиште: AllowedIPs на еден peer одлучуваат кој peer ќе го прими пакетот. Два peer не можат двата да објавуваат 10.10.7.0/24 без еден од нив да победи во секое пребарување. Тоа е својство на табелата со peer, а не на тунелот, затоа решение овде е план за адреси, а не трик со рутирање.

Планот е целосно да се престане со објавување на LAN. Наместо тоа објавете alias за секоја услуга, по една адреса на локација, и нека портата на секоја локација го преведе тој alias во својата вистинска апликација.

Корисникот рутира две единствени адреси, никогаш не го гледа двосмислениот префикс, и ништо не се менува во ниту една од двете канцеларии. Ова исто така чесно ја кажува границата: објавувате една HTTPS услуга од секоја локација, а не спојувате две мрежи. Правилата што следат остануваат мали затоа што тврдењето е тесно. Пошироко тврдење би барало пошироки правила, и токму така овие дизајни стануваат комплицирани.

Дајте на секоја локација alias што корисникот може да го рутира

Изберете адреси од опсег што не се судира со ништо на машината на корисникот, центарот или која било од двете LAN. Овде центарот е 10.66.0.1, корисникот е 10.66.0.10, портите се 10.66.0.21 и 10.66.0.22, а двата alias се 10.77.1.20 и 10.77.2.20. Центарот го објавува секој alias преку peer што го поседува, па излезниот пакет упатен на еден alias може да излезе само преку соодветната локација:

[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

Страната на корисникот и требаат само двата alias, што ја држи клиентската конфигурација слободна од двата LAN префикса. Ништо во таа конфигурација не спомнува ниту една вистинска 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

Секоја порта го објавува центарот и изворот на корисникот, ништо друго, така што локацијата никогаш не ја дознава LAN на другата локација. Keepalive одржува NAT мапирање на uplink на локацијата; тоа не го овластува сообраќајот, и огнениот ѕид сѐ уште одлучува што се прима. Копирањето на конфигурацијата на една порта во друга е во ред додека приватниот клуч, адресата на интерфејсот и alias сите се менуваат.

Што мора центарот да дозволи помеѓу два негови peer

Центарот препраќа пакети помеѓу два свои peer, што е одлука во forward синџирот, а не влезна одлука. Овозможете IPv4 препраќање преку нормалниот механизам на платформата, потоа дозволете точно оние парови што му се потребни на дизајнот.

Правилото подолу му дозволува на корисникот еден alias и еден порт, и дозволува повратен сообраќај преку следење на врски. Го отфрла сето друго на forward патот, и тоа е поентата:

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

Два детали вреди да се споменат зашто предизвикуваат тивки дефекти. Accept во еден основен синџир не го поништува drop во друг, затоа спојте го ова со постоечката политика наместо да го вчитувате покрај неа. И изворната адреса го идентификува уредот, не личноста; држете ја автентикацијата на апликацијата одвоена од мрежното дозволување.

Каде alias станува вистинска адреса

Локацијата A прима барање за 10.77.1.20, ја препишува одредиштето во вистинската апликација и го препишува изворот во својата LAN адреса за да може одговорот да се врати без рута до тунелот. Вршењето на двата превода на едно место го држи остатокот од мрежата во незнаење за alias. Правилата подолу се целиот механизам:

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

Потоа forward политиката на локацијата A мора да го дозволи преведениот тек од интерфејсот на тунелот кон LAN интерфејсот, плус насоката на враќање. forward hook-от го гледа одредиштето по преводот на одредиштето и пред препишувањето на изворот, затоа правилото ја именува адресата на вистинската апликација. Читајте ги тие два hook-а по тој редослед кога правило изгледа дека не одговара на ништо. forward правило напишано против alias никогаш не може да се совпадне, зашто alias веќе не постои на тој hook.

Локацијата B го повторува ова со свој alias и свој клуч. Таа не смее повторно да го користи приватниот клуч на локацијата A, зашто два peer што делат еден идентитет се конфигурациска грешка што е тешко да се види и лесно да се создаде со копирање датотека. Држете ги двата документи на портата идентични освен вредностите што мора да се разликуваат, за да отскокнува разликата при преглед. Копирана датотека е вообичаениот извор на таа грешка.

Препишувањето на изворот има цена. Апликацијата ја гледа портата како свој клиент, затоа нејзините дневници веќе не покажуваат кој корисник се поврзал. Чувајте ја ревизорската трага на портата и не ја ослабувајте најавата во апликацијата за да компензирате мрежен идентитет што преводот го отстранил.

Како да докажете дека двете објавени имиња одговараат

Дајте на секој alias DNS име и конфигурирајте ја апликацијата и сертификатот за тоа име, зашто преводот не препишува пренасочувања или вградени апсолутни URL-а. Користете едно име по локација за несовпаѓањето на сертификатот никогаш да не се помеша со рутирачки дефект.

Тестирајте од вистинскиот клиент, потврдете која локација одговори и тестирајте и неовластен порт. Користете нови врски по секоја промена на NAT, зашто воспоставената состојба го задржува старото мапирање:

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

Празен или неочекуван alias во првата команда значи дека изборот на peer е погрешен пред да биде важно кое било правило на огнениот ѕид. Ако alias е точен, а името сѐ уште не работи, проблемот се преселил во DNS и сертификати. Штом двете имиња одговорат и третиот порт остане затворен, дизајнот го прави тоа што го тврди: две тесно објавени услуги, а не две споени LAN.