Рукостискання 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

Правила, додані вручну, зникають під час перезавантаження, тому прив'яжіть їх до інтерфейсу командами-перехоплювачами в конфігурації сервера. Набір правил, що переживає свій інтерфейс, — це спосіб, у який машина зрештою транслює трафік для тунелю, якого більше немає.

Коли локальна мережа переїхала, а правило ні

Заміна маршрутизатора, що перенумеровує офісну підмережу, — класична версія цього збою. Тунель залишається піднятим, рукостискання залишається свіжим, і ніщо за сервером не відповідає, бо правило трансляції досі називає стару адресу. Інсталяційні скрипти часто вписують локальну адресу сервера в правило 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 або на маршрут клієнта. Ці два результати потребують різних виправлень, і саме захоплення дозволяє їх розрізнити.