Руковање WireGuard-а ради, али канцеларијска подмрежа не одговара

Руковање се завршава, wg show извештава о недавном преносу, и тунелска адреса сервера одговара на ping. Али домаћин на LAN-у сервера не. Три услова морају важити истовремено: клијент мора да усмери префикс LAN-а у тунел, сервер мора да проследи пакете, а одговору је потребна путања назад. Када недостаје један од три, симптом је исти.

AllowedIPs је и листа приступа и табела рутирања

На клијенту, листа AllowedIPs одлучује и шта сме да се пошаље том peer-у и које руте WireGuard инсталира. Унос peer-а који наводи само тунелску адресу сервера инсталира једну руту до домаћина, па LAN одредишта никада не улазе у тунел. Додавање префикса LAN-а је прво што треба проверити, а то је и промена која најчешће недостаје после копиране конфигурације. Peer проширен на подразумевану руту је други дизајн и преместиће и интернет саобраћај клијента.

Држите руту до домаћина и префикс LAN-а као одвојене уносе. Ако канцеларија има две подмреже, обе припадају листи, а префикс који недостаје ствара квар који изгледа селективно, а не потпуно.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Прослеђивање и превођење припадају серверу

Серверу је потребно омогућено IP прослеђивање, правило прослеђивања које прихвата саобраћај који долази из тунела, и правило превођења ка његовом LAN интерфејсу. Управо превођење чини дизајн функционалним без дирања сваког домаћина на канцеларијској мрежи. Онда се одговори враћају на сервер, а не на адресу за коју LAN никада није чуо. Без тога, сваком домаћину је потребна рута до подмреже тунела и правило заштитног зида које је дозвољава, што је ретко прихватљиво на мрежи којом управља неко други.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Правила додата ручно нестају при поновном покретању, зато их повежите са интерфејсом hook командама у конфигурацији сервера. Скуп правила који надживи свој интерфејс је начин на који машина на крају преводи саобраћај за тунел који више не постоји.

Када се LAN преселио, а правило није

Замена рутера која пренумерише канцеларијску подмрежу је класична верзија овог квара. Тунел остаје активан, руковање остаје свеже, и ништа иза сервера не одговара, јер правило превођења још увек наводи стару адресу. Инсталационе скрипте често уграђују LAN адресу сервера у правило POSTROUTING, а после пренумерације та адреса не постоји ни на једном интерфејсу. Пакети се затим преписују ка одредишту које не може да одговори.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Упоредите два излаза. Циљ превођења који се не појављује на листи интерфејса је грешка, а њено исправљање је промена једне линије када је једном видите. Правило може да живи у генерисаном unit-у, а не у конфигурацији WireGuard-а, зато поново учитајте тај unit после измене и потврдите да следеће покретање неће преписати вашу промену.

Две локације иза NAT-а имају потребу за местом сусрета

Када ниједна страна не прихвата долазне везе, практичан одговор је мали домаћин са јавном адресом и два WireGuard интерфејса. Свака локација се повезује напоље, средњи домаћин наводи LAN сваког peer-а у свом AllowedIPs, а прослеђивање преноси пакете између два тунела. Ништа на заштитном зиду ниједне локације не мора да се промени, и зато се овај дизајн лако шири.

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

Одвојите слојеве са четири провере

Урадите једну проверу по слоју, уместо да мењате три ствари и надате се. Прва показује старост руковања и бројаче за сваки peer. Друга показује да ли клијент заиста усмерава то одредиште у тунел. Трећа и четврта говоре да ли је захтев стигао и да ли га је нека политика одбацила по доласку.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Захтев који стигне и не изазове одговор указује на путању одговора или на домаћина на LAN-у. Захтев који никада не стигне указује на AllowedIPs или на руту клијента. Ова два исхода захтевају различите исправке, а снимак је оно што их разликује.