Две локације, једна подмрежа, једно WireGuard чвориште: покрените то

Обе LAN мреже су на 10.10.7.0/24, зато чвориште не може да изабере локацију према одредишту. Дајте свакој услузи alias и преводите на њеној капији.

Обе локације користе исти 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 мреже.

Повезани чланци