Повний тунель WireGuard: AllowedIPs 0.0.0.0/0 недостатньо

Записати 0.0.0.0/0, ::/0 в AllowedIPs партнера — це крок, який пам’ятають усі, і він вирішує лише те, який трафік партнерові дозволено нести. Ці префікси не створюють маршрутів, нічого не пересилають на іншому боці й залишають резолвер кожної програми рівно там, де він був. Чотири окремі речі мають виконуватися одночасно, щоб повний тунель був справді повним, і перевіряти їх краще в порядку нижче, бо пізніша перевірка не може врятувати ранішу. Кожна перевірка нижче — це факт, який можна прочитати з машини, а не налаштування, на застосування якого ви сподіваєтеся.

Що вибирає префікс партнера, а що ні

AllowedIPs водночас є селектором і дозволом. Він повідомляє локальній стороні, які призначення можна надсилати цьому партнерові, а стороні, що приймає, — які адреси джерела цей партнер може подавати. Це вся робота. Ніщо в цьому описі не створює маршрут на хості, не вмикає пересилання на віддаленому боці й не торкається розв’язання імен.

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

Маршрутизувати клієнта, а не лише список партнерів

Менеджери на кшталт wg-quick програмують таблицю маршрутів хоста за вас, тому два однакові конфігураційні файли поводяться по-різному залежно від того, як піднявся інтерфейс. Мінімальний профіль достатньо короткий, щоб прочитати його за один раз:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Роботу несуть дві деталі. Поле Address — це один префікс хоста, а не підмережа, яку клієнт вважає своєю, і саме менеджер перетворює типові AllowedIPs на справжній типовий маршрут. Підніміть той самий файл за допомогою ip link і wg setconf і не з’явиться жодного маршруту, що виглядає як зламаний тунель, а насправді є здоровим тунелем із пропущеним кроком маршрутизації. Посібник wg-quick документує маршрутизацію та Table поведінку, яку додають ці менеджери.

Читайте результат, а не файл: ip route get 1.1.1.1 має назвати інтерфейс тунелю, а wg show має повідомити про нещодавнє рукостискання з рухомим лічильником передавання. Рукостискання без маршруту означає, що менеджер ніколи не запускався, і повторне редагування профілю цього не виправить. Запускайте інтерфейс так, як його запустить користувач, інакше тест вимірює вашу оболонку замість розгортання.

Тримати кінцеву точку поза тунелем

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

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

Той самий механізм пояснює, чому повний тунель і перехоплювальний портал воюють. Портал очікує перехопити трафік, який ваш тунель тепер захоплює, тому в готельних і аеропортових мережах тунель піднімають після входу в портал і ніколи до нього.

Пересилання та зворотний шлях на шлюзі

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS і стан відмови, перевірені окремо

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

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

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