WireGuard працює на мобільних даних, але не в тій самій wifi-мережі
Запит зсередини LAN до публічної адреси роутера йде іншим шляхом, ніж запит з мобільних даних. Перевірте ззовні, потім виберіть локальний шлях.
Тунель піднімається на мобільних даних і потім залишається на підключенні вдома, з тим самим профілем, тим самим ключем peer і без змін конфігурації між ними. Різниця в маршруті: запит зсередини LAN до публічної адреси роутера — не та сама подорож, що запит, який надходить з інтернету. Більшість домашніх шлюзів або взагалі не реалізують зворотний шлях, або реалізують його лише для певних протоколів. Через це симптом виглядає як зламаний ключ, хоча з ключем нічого не сталося. Визначте, який шлях відмовив, перш ніж чіпати ключ, проброс порту або профіль клієнта.
Одна адреса, два різні шляхи
Ззовні пакет досягає публічної адреси роутера, і правило пробросу порту передає його слухачеві WireGuard на внутрішньому хості. Зсередини клієнт набирає ту саму публічну адресу, тому пакет виходить від клієнта, приходить на роутер і має бути розвернутий назад у бік LAN. Саме на цьому розвороті два шляхи розходяться, бо роутер має транслювати потік, який одночасно виходить і знову входить через той самий інтерфейс. Багато реалізацій відкидають його замість трансляції, і клієнт тоді чекає рукостискання, яке так і не було надіслане.
Таку поведінку зазвичай називають NAT loopback або hairpinning, і вона належить роутеру, а не WireGuard; RFC 4787 описує випадки трансляції, у яких шлюз може підтримувати її або ні. Сам WireGuard не має думки про шлях, бо бачить лише пакети, що досягають його інтерфейсу. Коли роутер відкидає потік, демон не отримує нічого, клієнт повідомляє про тайм-аут рукостискання, а журнал сервера залишається порожнім. Порожній журнал тому підказує, де зупинився пакет, а не доводить, що сервер упав. Це ж причина, чому перевстановлення нічого не змінює.
Зворотне теж важливе: журнал сервера, що показує спробу рукостискання з адреси LAN, доводить, що пакет дійшов і шлях гаразд, а це переводить розслідування до ключів і дозволених адрес. Читайте журнал заради того, що він доводить, а не заради того, що ви сподівалися побачити.
Спочатку відтворіть, потім змінюйте
Перевірте з авторизованої зовнішньої мережі з тим самим пристроєм і тим самим профілем, потім повторіть перевірку всередині LAN, нічого не редагуючи. Завершене рукостискання ззовні й клієнт, який зсередини ніколи не покидає пристрій, відтворюють стан замість здогадок. Обидві спроби мають використовувати один профіль, інакше порівняння нічого не доводить.
Потім подивіться, у що розв’язується ім’я кінцевої точки для цього пристрою. Три наступні команди також показують, яку адресу клієнт насправді набрав:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netПерша команда повідомляє кінцеву точку, яку інтерфейс використовує зараз, а дві інші показують, у що ім’я розв’язується на цій машині. Клієнт, що набирає публічну адресу, перебуваючи в тій самій мережі, що й сервер, використовує шлях hairpin. Клієнт, що набирає адресу LAN, цього не робить, і збій там належить до іншого розслідування. Ця різниця вирішує, чи застосовний наступний розділ узагалі.
Підтримувані способи дістатися до близького сервера
Найчистіша схема — відповідь із розділенням горизонту: публічне ім’я розв’язується в публічну адресу для інтернету і в адресу LAN сервера для клієнтів усередині. Профіль зберігає одне ім’я кінцевої точки, а резолвер вибирає шлях. Для цього потрібен контроль над внутрішньою відповіддю DNS, який домашній роутер зазвичай пропонує, а організація може влаштувати навмисно. Без такого контролю залишаються функція роутера або другий профіль.
Функція роутера — відображення: шлюз транслює потік зсередини назовні й надсилає його назад усередину. Там, де вона працює, зміни клієнта не потрібні, а там, де не працює, жодне налаштування клієнта її не врятує. Перевірте її, спостерігаючи за журналом сервера під час внутрішньої спроби, а не читаючи список функцій роутера.
Правка профілю на приватну адресу — це діагностика, а не проєкт. Вона доводить, що сервер відповідає в LAN, і ламає той самий профіль тієї миті, коли ноутбук виїжджає з дому.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Тримайте профіль придатним поза домом
Який би шлях ви не обрали, не чіпайте перевірку автентичності. Адреса кінцевої точки — не ідентичність peer, і зміна адреси ніколи не виправдовує прийняття стороннього публічного ключа, який випадково відповідає. WireGuard автентифікує за ключем, тому неправильний хост провалює рукостискання замість того, щоб дати доступ до чогось неочікуваного.
Якщо публічна адреса змінюється, саме динамічний DNS зберігає ім’я корисним, а поведінка оновлення клієнта вирішує, як швидко зміна доїде. Перевірте це ззовні після зміни адреси, бо випадок LAN цього не підтвердить. Стежте за резолвером, який кешує стару відповідь довше за час життя запису. Ім’я, що досі вказує на попередню адресу, виглядає точно як сервер, що впав.
Запишіть, яке ім’я використовує профіль і в що воно розв’язується з кожного боку межі. Профіль, що залежить від функції роутера, яку ніхто не зафіксував, — це дзвінок до підтримки в очікуванні наступного оновлення прошивки. Запис також каже наступній людині, чи внутрішній збій є відомим випадком hairpin, чи чимось новим.