Ръкостискането на WireGuard работи, но офисната подмрежа не отговаря

Ръкостискането завършва, wg show съобщава за скорошен трансфер и тунелният адрес на сървъра отговаря на ping. Хост в локалната мрежа на сървъра обаче не. Три условия трябва да са изпълнени едновременно: клиентът трябва да маршрутизира префикса на локалната мрежа в тунела, сървърът трябва да препраща пакетите, а отговорът се нуждае от път обратно. Когато едно от трите липсва, симптомът е идентичен.

AllowedIPs е едновременно списък за достъп и таблица за маршрутизация

На клиента списъкът AllowedIPs решава както какво може да се изпраща към този партньор, така и кои маршрути инсталира WireGuard. Запис за партньор, който изброява само тунелния адрес на сървъра, инсталира един маршрут до хост, така че дестинациите в локалната мрежа никога не влизат в тунела. Добавянето на префикса на локалната мрежа е първото нещо за проверка и също най-вероятната липсваща промяна след копирана конфигурация. Партньор, разширен до маршрут по подразбиране, е различен дизайн и ще премести и интернет трафика на клиента.

Дръжте маршрута до хоста и префикса на локалната мрежа като отделни записи. Ако офисът има две подмрежи, и двете принадлежат в списъка, а липсващият втори префикс дава отказ, който изглежда избирателен, а не пълен.

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

Препращането и транслацията са на сървъра

Сървърът се нуждае от включено IP препращане, правило за препращане, което приема трафик, идващ от тунела, и правило за транслация към неговия интерфейс в локалната мрежа. Именно транслацията кара дизайна да работи, без да се пипа всеки хост в офисната мрежа. Тогава отговорите се връщат към сървъра, а не към адрес, за който локалната мрежа никога не е чувала. Без нея всеки хост се нуждае от маршрут към подмрежата на тунела и правило на защитната стена, което го разрешава, а това рядко е приемливо в мрежа, управлявана от някой друг.

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

Правилата, добавени на ръка, изчезват при рестарт, затова ги вържете към интерфейса с hook командите в конфигурацията на сървъра. Набор от правила, който надживява интерфейса си, е как машина започва да трансформира трафик за тунел, който вече не съществува.

Когато локалната мрежа се премести, а правилото не

Смяната на рутер, която преномерира офисната подмрежа, е класическата версия на този отказ. Тунелът остава включен, ръкостискането остава свежо и нищо зад сървъра не отговаря, защото правилото за транслация все още посочва стария адрес. Инсталационните скриптове често вграждат адреса на локалната мрежа на сървъра в правило POSTROUTING и след преномериране този адрес не съществува на нито един интерфейс. Тогава пакетите се пренаписват към дестинация, която не може да отговори.

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

Сравнете двата изхода. Цел за транслация, която не се появява в списъка на интерфейсите, е грешката и поправянето ѝ е промяна в един ред, след като я видите. Правилото може да живее в генериран unit, а не в конфигурацията на WireGuard, затова презаредете този unit след редактиране и потвърдете, че следващото зареждане няма да пренапише промяната ви.

Два обекта зад NAT се нуждаят от място за среща

Когато нито една страна не приема входящи връзки, практичният отговор е малък хост с публичен адрес и два интерфейса WireGuard. Всеки обект се свързва навън, средният хост изброява локалната мрежа на всеки партньор в своя AllowedIPs, а препращането пренася пакети между двата тунела. Нищо в защитната стена на нито един обект не трябва да се променя, затова този дизайн се разпространява лесно.

Маршрутизацията между обектите запазва оригиналните адреси на източника и следователно запазва смисъла на логването по хост. Транслацията на средния хост е по-проста, когато двете локални мрежи се застъпват, но на цената на загуба на идентичността на източника в логовете. Решете кое свойство е важно, преди да избирате.

Разделете слоевете с четири проверки

Правете една проверка на слой, вместо да променяте три неща и да се надявате. Първата показва възрастта на ръкостискането и броячите за всеки партньор. Втората показва дали клиентът наистина маршрутизира тази дестинация в тунела. Третата и четвъртата ви казват дали заявката е пристигнала и дали политика я е изпуснала след пристигането.

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

Заявка, която пристига и не предизвиква отговор, сочи към пътя за отговор или към хоста в локалната мрежа. Заявка, която изобщо не пристига, сочи към AllowedIPs или към маршрута на клиента. Тези два изхода изискват различни поправки и точно заснемането ги различава.