WireGuard Roaming: виправлення, яке припиняє розриви мобільного VPN

February 10, 2026 • February 10, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ваш телефон переключається з офісного Wi‑Fi на LTE, VPN обривається, Slack перепідключається, сесія SSH зависає, і ваш мозок на чергуванні починає рахувати те, на що не підписувався.
Якщо ви це переживали — ви не марите: більшість VPN було спроектовано з романтичною ідеєю, що IP‑адреси лишаються на місці.

WireGuard — один із небагатьох VPN, які сприймають роумінг як первинну реальність. Це не «мобільний» у маркетинговому сенсі.
Це «мобільний» у сенсі «я можу вийти з будівлі під час інциденту і мій тунель не згориться».

Справжня проблема роумінгу: мережі брешуть

«Роумінг» звучить чемно. Наче ваш ноутбук прогулюється луком і неквапливо перемикається між точками доступу.
У виробничому середовищі роумінг означає, що ваш вихідний IP і порт змінюються, NAT‑мапінги зникають, шляхи дивнішають, а стан UDP трактують як одноразовий стаканчик.

Більшість болю мобільних VPN — не в криптографії. Це стан. Зокрема: хто вважає, що peer «знаходиться» за якою IP:порт зараз, і чи погоджуються проміжні пристрої досить довго, щоб пакети доходили.
Мобільні мережі додають хаосу: carrier‑grade NAT, агресивні таймаути бездіяльності та енергозбереження, яке призупиняє ваш додаток і сокети.

Класичні VPN‑стеки часто прив’язують ідентичність до сесії, що припускає стабільний транспорт. Коли транспорт змінюється, сесію потрібно переобговорити.
Переговори займають час. Деякі реалізації роблять це погано. Деякі роблять «правильно», але вимагають настільки частих keepalive, що згоряє батарея і все одно втрачають звʼязок.

Підхід WireGuard грубий: ваша ідентичність — це ваш публічний ключ. Деталі транспорту замінні.
Якщо сервер отримує автентифікований пакет від peer з нової IP:порт адреси, він оновлює уявлення про те, де цей peer «живе».
Оце і є роумінг. Це не магія; це проєктне рішення, яке втілює очевидне: телефони рухаються.

Чому мобільні VPN «відключаються», навіть коли тунель живий

Багато інцидентів помилково класифікують як «відключення VPN». Тунель може бути сконфігурований, інтерфейс існувати, клієнт показувати «підключено».
Насправді трапляється одне з цього:

Завершився NAT‑мапінг: сервер відповідає на адресу/порт, що вже не відповідає клієнту.
Змінився Path MTU: LTE‑шлях звузився; пакети зникають у чорній дірі; TCP стоїть; користувачі кажуть «відключило».
Змінився DNS: ви перейшли в мережу з іншими резолверами; DNS VPN не застосовано; пошук імен падає.
Змінилася політика маршрутизації: ОС вирішила, що маршрутом за замовчуванням став інший інтерфейс; правила split tunnel конфліктують; частина трафіку виходить локально або зациклюється.
Невідповідність стану файрвола: UDP‑«сесії» — це рекомендація; під час роумінгу ви втрачаєте зворотний трафік.

WireGuard не вирішує кожну з цих проблем сам по собі. Але він чисто вирішує базове питання ідентичності/ендпойнта, що усуває велику класу нестабільності.

Як WireGuard насправді обробляє роумінг

WireGuard — тунель рівня 3 з невеликим протоколом і жорсткою ідеєю: пакети мають бути автентифіковані.
Якщо сервер отримує автентифікований пакет для peer з нової IP:порт адреси, він оновлює ендпойнт цього peer і відповідає туди.
Жодної «церемонії перепідключення» не потрібно.

Це оновлення ендпойнта відбувається з обох боків. Клієнт теж може роумити: якщо він бачить відповідь від сервера за новою адресою (менш поширено, але актуально для anycast чи multi‑homed серверів),
він також оновлює свій ендпойнт.

Handshake vs data packets: що що оновлює

WireGuard використовує handshake на основі Noise. Handshake‑пакет автентифікований. Дані також автентифіковані.
Навчання ендпойнта відбувається, коли пакет успішно автентифікований і роздешифрований.
Це критична деталь: випадковий UDP‑спам не може перемістити ваш ендпойнт. Тільки peer, який має правильні ключі, може.

Отже роумінг — це не «приймати пакети звідусіль». Це «приймати пакети звідусіль якщо вони доводять, хто вони є».
Саме тому ви безпечно можете дозволити мобільним клієнтам переходити між Wi‑Fi, LTE, готельними мережами і час від часу застрягати в древньому captive portal.

Навіщо потрібні keepalive, якщо роумінг такий чудовий

Роумінг вирішує проблему зміни ендпойнта. Він не скасовує таймаути NAT силою волі.
Якщо клієнт за NAT і перебуває в режимі очікування, мапінг може завершитися. Сервер все ще відправлятиме відповіді на останній відомий ендпойнт, який тепер вказує ні на кого.

Виправлення — використання PersistentKeepalive на боці за NAT (зазвичай мобільний клієнт).
Він періодично відправляє порожні пакети, щоб підтримувати NAT‑мапінг живим.
Використовуйте його обдумано, а не через суєту.

Keepalive мають свою вартість: батарея, пробудження радіо і іноді більший трафік даних.
Але альтернатива — ваш тунель, що тихо перетворюється на декоративний елемент інтерфейсу.

Одна цитата, яку операційники повинні вивісити в runbook

«Hope is not a strategy.» — General Gordon R. Sullivan

Якщо ваш мобільний VPN залежить від «NAT зазвичай тримає UDP‑мапінги деякий час», ви працюєте на надії. Надія викличе вас о 2 ранку.

Факти та історія, що пояснюють дизайн

WireGuard не зʼявився як «кращий інтерфейс OpenVPN». Він виник через конкретне розчарування: VPN‑стеки були великі, важкі для аудиту і надто толерантні до поганих значень за замовчуванням.
Ось кілька фактів і контексту, які роблять роумінг неминучим, а не дивним:

WireGuard почався близько 2015 року як проєкт для побудови простішого, більш аудитованого VPN з сучасними крипто‑налаштуваннями.
Він використовує фреймворк Noise (конкретно варіант патерну Noise IK) для структурування handshake з міцними властивостями безпеки.
Мета — невелика кодова база порівняно зі спадковими VPN‑реалізаціями, що зменшує поверхню атак і полегшує аудит.
Спочатку був out‑of‑tree для Linux і пізніше потрапив у mainline ядра Linux у 2020 році — великий голос довіри і фактор пришвидшення розгортання.
Використовує UDP за замовчуванням щоб уникнути TCP‑over‑TCP та тому, що UDP краще терпить зміну умов мережі.
Ідентичність — це публічний ключ, а не IP‑адреса; IPи всередині тунелю маршрутизуються як «AllowedIPs».
Роумінг — першокласна поведінка: ендпойнти вивчаються динамічно на основі автентифікованих пакетів, а не фіксуються назавжди.
Уникнення конфігураційних опцій у крипто: немає меню «вибрати з 17 шифрів». Це запобігає іграм із пониженням рівня та конфіг‑дрейфу.
Часто реалізується на мобільних платформах з використанням нативних стеків ОС (наприклад, tunnel providers), що допомагає стабільності, але успадковує політику енергозбереження ОС.

Що налаштувати (а що не треба)

Роумінг «просто працює» лише якщо ви не саботуєте його хибними припущеннями.
WireGuard простий, але ця простота означає, що ви ближчі до «заліза». Ви цілком можете вистрілити собі в ногу.
Пістолет маленький. Він все одно працює.

Визначте намір тунелю: повний тунель чи split tunnel

Для мобільних користувачів split tunnel зазвичай є розумним дефолтом, якщо у вас немає конкретних вимог відповідності.
Повний тунель привабливий, поки ви не пропустите через свій дата‑центр відеодзвінки, випадково не станете провайдером і не дізнаєтеся, що користувачі судять вас за фізику.

Повний тунель: AllowedIPs клієнта включає 0.0.0.0/0, ::/0. Ви повинні забезпечити DNS, egress NAT і ретельно обробляти MTU.
Split tunnel: AllowedIPs клієнта включає лише внутрішні підмережі (і, можливо, кілька діапазонів сервісів). Менше збоїв, менше витрат трафіку.

Використовуйте PersistentKeepalive на клієнтах за NAT (зазвичай мобільні)

Якщо мобільний клієнт за NAT і вам потрібно, щоб його можна було дістати (для відповідей, push‑трафіку або просто надійних сесій), встановіть:
PersistentKeepalive = 25 секунд в записі peer клієнта для сервера.

Чому 25? Це прагматичне значення, яке перемагає багато таймаутів NAT без абсурду. Але не треба його обожнювати. Вимірюйте свої мережі.

MTU: тихий вбивця квитків «воно відключається»

Роумінг змінює шляхи. Шляхи змінюють MTU. LTE і деякі Wi‑Fi‑налаштування можуть бути алергічні до фрагментації.
Коли MTU неправильний, ви отримуєте затори, часткову доступність, і користувачі описують це як «VPN ненадійний».

Мій дефолт для мобільного WireGuard — починати десь з 1280 для дружності до IPv6 і менше сюрпризів.
На чистіших мережах можна підвищувати (1420 — поширене). Але якщо ви шукаєте мобільні обриви — зменшіть MTU раніше, ніж торкатиметесь крипто.

DNS: оберіть одну історію і розповідайте її послідовно

Багато «відключень» — це насправді збої резолюції імен після роумінгу.
Вирішіть, чи DNS буде:

Всередині тунелю: вкажіть DNS у конфігурації клієнта; переконайтеся, що DNS‑сервер досяжний через AllowedIPs; переконайтеся, що сервер переадресовує/відповідає.
Позаду тунелю: погодьтеся на локальний DNS; тоді не обіцяйте, що внутрішні імена працюватимуть всюди.

Файрвол: дозвольте те, що ви побудували

WireGuard використовує UDP. Якщо ваш периметр підозріло ставиться до UDP (а таке часто буває), ви маєте дозволити його явно.
Також: якщо ви запускаєте WireGuard на нестандартному порту, щоб «сховати», будьте чесні щодо того, що ви оптимізуєте.
Безпека шляхом прикриття — як одягати маску на нараду співробітників; це більше плутає колег.

Практичні задачі: команди, виводи, рішення

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

Задача 1: Підтвердити стан інтерфейсу WireGuard на сервері

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 6E9q...yZ0=
  private key: (hidden)
  listening port: 51820

peer: oYt9...r3Q=
  allowed ips: 10.6.0.2/32
  latest handshake: 14 seconds ago
  transfer: 22.34 MiB received, 48.11 MiB sent
  persistent keepalive: every 25 seconds

Значення: Peer нещодавно зробив handshake; відбуваються передачі; keepalive налаштовано.

Рішення: Якщо latest handshake — «never» або дуже старий, припиніть звинувачувати MTU або DNS і зосередьтеся на досяжності (UDP/порт/NAT).

Задача 2: Перевірити, чи сервер слухає очікуваний UDP‑порт

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0            0.0.0.0:51820      0.0.0.0:*    users:(("wg",pid=1143,fd=6))

Значення: Ядро слухає на UDP/51820.

Рішення: Якщо ніхто не слухає, ваша проблема — локальна служба/конфігурація, а не «роумінг». Спочатку виправте systemd‑юніт або конфіг.

Задача 3: Перевірити, чи файрвол дозволяє UDP для WireGuard

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport 51820 accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }
}

Значення: Політика за замовчуванням — drop, але UDP/51820 явно дозволено.

Рішення: Якщо ви не бачите правила accept — додайте його. Якщо ви покладаєтесь на «security group, мабуть, дозволяє», ви делегуєте доступність на удачу.

Задача 4: Спостерігати живі handshake, щоб підтвердити зміни ендпойнта

cr0x@server:~$ sudo wg show wg0 latest-handshakes endpoints
peer: oYt9...r3Q=
  endpoint: 203.0.113.50:49213
  latest handshake: 1707142421

peer: 2xK1...a9c=
  endpoint: 198.51.100.77:61102
  latest handshake: 1707142414

Значення: Ви бачите поточні ендпойнти кожного peer (IP:порт). На мобільних пристроях порт часто змінюється при роумінгу.

Рішення: Якщо ендпойнт ніколи не змінюється, навіть коли користувач роумить, можливо, трафік привʼязано через проксі, або клієнт нічого не відправляє після роуму (сплячий режим/політика енергозбереження).

Задача 5: Підтвердити IP‑форвардінг на сервері (для маршрутизації трафіку)

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Значення: Сервер маршрутизуватиме пакети між інтерфейсами.

Рішення: Якщо forwarding = 0, клієнти можуть коректно handshake, але не дістатися далі сервера. Виправте forwarding перед тим, як гнатися за «роумінговими багами».

Задача 6: Підтвердити NAT (для повного тунелю або виходу в інтернет)

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oifname "eth0" ip saddr 10.6.0.0/24 masquerade
  }
}

Значення: Трафік із підмережі VPN маскується через eth0.

Рішення: Якщо ви робите повний тунель і NAT відсутній, клієнти підключаться, але не дійдуть до інтернету. Це звітують як «VPN відпадає сайти».

Задача 7: Перевірити таблицю маршрутизації для підмережі WireGuard

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1

Значення: Сервер знає, що VPN‑підмережа безпосередньо на wg0.

Рішення: Якщо маршрут до VPN‑підмережі відсутній, інтерфейс може бути не вгору або має неправильну адресу. Виправте це спочатку.

Задача 8: Перевірити MTU на wg0 і симптоми path MTU

cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Значення: MTU інтерфейсу — 1420 (поширений дефолт).

Рішення: Якщо мобільні користувачі повідомляють про затори на LTE, спробуйте зменшити MTU (наприклад, 1280) на клієнті і/або сервері. Потім протестуйте. Виправлення MTU виглядають як дива, бо вони нудні.

Задача 9: Тест «не фрагментувати» ping через тунель (виявлення MTU)

cr0x@server:~$ ping -M do -s 1380 10.6.0.2 -c 3
PING 10.6.0.2 (10.6.0.2) 1380(1408) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.6.0.2 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2046ms

Значення: Розмір пакета перевищує обмеження MTU інтерфейсу; це може вказувати, що ваш тунельний MTU не підтримує потрібний payload без фрагментації.

Рішення: Зменшіть MTU і повторіть, поки тест не пройде. Якщо не вдається знайти стабільний розмір «do not fragment», підозрюйте проміжну чорну діру або фільтрацію ICMP.

Задача 10: Захопити трафік WireGuard, щоб побачити, чи пакети приходять під час роумінгу

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:13:01.112233 IP 203.0.113.50.49213 > 203.0.113.10.51820: UDP, length 148
12:13:01.113005 IP 203.0.113.10.51820 > 203.0.113.50.49213: UDP, length 92
12:13:26.144990 IP 198.51.100.22.60133 > 203.0.113.10.51820: UDP, length 148
12:13:26.145701 IP 203.0.113.10.51820 > 198.51.100.22.60133: UDP, length 92

Значення: Ви бачите пакети з кількох джерелних IP/портів. Це саме те, як виглядає роумінг на краю: той самий peer‑ключ, різні ендпойнти з плином часу.

Рішення: Якщо ви бачите вхідні пакети, але wg show ніколи не оновлює часи handshake, підозрюйте неправильні ключі або проблеми з replay/годинником. Якщо нічого не бачите — проблема в мережі/файрволі/carrier NAT.

Задача 11: Підтвердити налаштування peer клієнта (на Linux‑клієнті)

cr0x@server:~$ sudo wg showconf wg0
[Interface]
PrivateKey = (hidden)
Address = 10.6.0.2/32
DNS = 10.6.0.1

[Peer]
PublicKey = 6E9q...yZ0=
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

Значення: Налаштовано split tunnel (лише RFC1918 діапазони), DNS вказує всередині тунелю, keepalive увімкнено.

Рішення: Якщо AllowedIPs надто широкі, ви можете перехопити локальні мережі (принтери, captive portal). Якщо занадто вузькі — внутрішні сервіси не будуть доступні.

Задача 12: Перевірити конфліктні маршрути і політику маршрутизації на клієнті

cr0x@server:~$ ip rule show
0:      from all lookup local
32764:  from all lookup main
32765:  from all lookup default

cr0x@server:~$ ip route show table main | sed -n '1,12p'
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
10.0.0.0/8 dev wg0 scope link
172.16.0.0/12 dev wg0 scope link

Значення: Маршрути для внутрішніх підмереж йдуть через wg0; маршрут за замовчуванням лишається на Wi‑Fi. Це поведінка split tunnel.

Рішення: Якщо маршрут за замовчуванням вказує на wg0 несподівано, ви налаштували повний тунель. Підтвердьте, чи це було вашим наміром, перед тим як звинувачувати «нестабільність роумінгу».

Задача 13: Підтвердити, який резолвер DNS діє (приклад systemd-resolved)

cr0x@server:~$ resolvectl status | sed -n '1,80p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 5 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.6.0.1
       DNS Servers: 10.6.0.1

Значення: DNS привʼязаний до VPN‑DNS сервера на WireGuard‑лінку.

Рішення: Якщо DNS‑сервери все ще локальні для Wi‑Fi, хоча ви очікуєте внутрішній DNS — виправте конфіг клієнта. Багато «VPN впав» — це насправді «DNS не той».

Задача 14: Перевірити таймаути conntrack (чому ваш UDP зникає)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Значення: UDP‑потоки можуть завершуватись дуже швидко (30s). На деяких файрволах/NAT це ще коротше.

Рішення: Якщо ви бачите відключення близько 30 секунд, keepalive 25 секунд зазвичай стабілізує це. Якщо батарея важлива — настройте після вимірювання таймаутів.

Задача 15: Підтвердити синхронізацію часу (handshake ненавидять розбіжність часу)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-04 12:21:42 UTC
           Universal time: Tue 2026-02-04 12:21:42 UTC
                 RTC time: Tue 2026-02-04 12:21:42
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Годинник синхронізований. Добре.

Рішення: Якщо системний годинник не синхронізований, ви можете бачити дивні handshake та відмови через replay‑захист. Виправте NTP перш ніж вигадувати нові теорії.

Задача 16: Перевірити, чи пакети маршрутизуються між VPN‑клієнтом і внутрішньою підмережею

cr0x@server:~$ ip route get 10.20.30.40 from 10.6.0.2 iif wg0
10.20.30.40 from 10.6.0.2 iif wg0
    via 10.0.0.1 dev eth0

Значення: Ядро маршрутизувало б трафік від VPN‑клієнта до внутрішньої мережі через eth0 (приклад).

Рішення: Якщо це вказує назад на wg0 або куди‑небудь ще невідомо, у вас асиметрія маршрутизації. Роумінг вас не врятує від поганої маршрутизації.

Швидкий план діагностики

Коли мобільний користувач WireGuard каже «VPN відключається, коли я виходжу з Wi‑Fi», не починайте з ідеології.
Почніть з найкоротшого шляху ізоляції вузького місця: транспорт, handshake, маршрутизація, MTU, DNS.

По‑перше: Чи доходить UDP до сервера взагалі?

На сервері: запустіть короткий захват на порт WireGuard, поки користувач перемикає Wi‑Fi → LTE.

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 20
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:15:01.100001 IP 198.51.100.22.60133 > 203.0.113.10.51820: UDP, length 148
12:15:01.100550 IP 203.0.113.10.51820 > 198.51.100.22.60133: UDP, length 92

Якщо нічого не бачите: файрвол, security group, фільтрація ISP, неправильний ендпойнт/порт або клієнт не надсилає через призупинення ОС. Виправляйте досяжність.

Якщо бачите пакети: переходьте до перевірки handshake.

По‑друге: Чи WireGuard їх приймає (оновлення handshake)?

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 6E9q...yZ0=
  listening port: 51820

peer: oYt9...r3Q=
  endpoint: 198.51.100.22:60133
  latest handshake: 6 seconds ago
  transfer: 4.12 MiB received, 6.88 MiB sent

Якщо handshake нещодавній: тунель живий. «Відключення» — ймовірно, проблема маршрутизації/MTU/DNS/поведінки додатка.

Якщо handshake старий/ніколи не був: неправильні ключі, неправильна конфігурація peer або пакети не є дійсним WireGuard‑трафіком для цього інтерфейсу. Перевірте конфіги.

По‑третє: Проблема лише з певним трафіком (MTU/DNS/маршрути)?

Тестуйте ping по IP (щоб обійти DNS).
Тестуйте резолюцію імен через DNS сервера VPN.
Тестуйте TCP‑зʼєднання з малим payload, потім з більшими.

Якщо малі запити працюють, а великі завантаження зависають — MTU ваш головний підозрюваний.
Якщо IP працює, а імена — ні — DNS.
Якщо лише деякі підмережі падають — AllowedIPs або маршрутизація.

Поширені помилки: симптом → причина → вирішення

Це повторювані шаблони, які стоять за «WireGuard роумінг не працює», що зазвичай означає «ми побудували ідеальний тунель в ідеальну мережу».

1) Симптом: «Працює на Wi‑Fi, падає на LTE»

Причина: Carrier NAT і короткі таймаути бездіяльності UDP; мапінг закінчується під час простою, сервер відповідає на мертвий ендпойнт.

Вирішення: Встановіть PersistentKeepalive = 25 на записі peer мобільних клієнтів; за потреби зменшіть (наприклад, до 15) якщо оператор особливо агресивний. Підтверджуйте за штампами handshake.

2) Симптом: «Підключено, але після роумінгу нічого не завантажується»

Причина: Handshake в порядку, але MTU‑чорна діра після зміни шляху.

Вирішення: Зменшіть MTU на клієнті (почніть з 1280) і/або сервері. Перевірте ping -M do і реальні передачі додатків.

3) Симптом: «Деякі внутрішні сервіси працюють, інші таймаутяться»

Причина: Missing AllowedIPs‑маршрути, або перекриття приватних діапазонів з локальною мережею (кафе теж використовує 10.0.0.0/8).

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

4) Симптом: «VPN каже підключено, але DNS не працює»

Причина: DNS не застосовано ОС клієнта, або DNS‑сервер недосяжний через AllowedIPs, або DNS‑сервер слухає лише в LAN.

Вирішення: Переконайтеся, що IP DNS‑сервера входить у AllowedIPs і доступний; налаштуйте інтеграцію резолвера (systemd-resolved, NetworkManager, поле DNS у мобільному клієнті). Перевірте статус резолвера.

5) Симптом: «Роумінг викликає новий handshake, а сесії все одно помирають»

Причина: Сесії на рівні додатків не переносять зміну шляху (деякі TCP сесії падають), або stateful файрволи скидають потоки.

Вирішення: Віддавайте перевагу протоколам, що коректно повторюють підключення; уникайте stateful middlebox між клієнтом і сервером коли можливо; тримайте WireGuard‑сервер ближче до краю мережі.

6) Симптом: «Кілька клієнтів «крадуть» підключення один у одного»

Причина: Дубльовані ключі peer або дубльовані AllowedIPs; WireGuard маршрутизує за AllowedIPs і очікує унікальності.

Вирішення: Один унікальний keypair на пристрій; одна унікальна AllowedIPs на peer (щонайменше /32 або призначена тунельна IP). Аудит конфігів і ротація ключів.

7) Симптом: «Handshake нещодавній, але пакети не доходять до внутрішньої мережі»

Причина: Відсутній IP‑форвардінг, відсутні маршрути, відсутній NAT, або асиметрична маршрутизація у внутрішній мережі (зворотний шлях не знає 10.6.0.0/24).

Вирішення: Увімкніть форвардінг; додайте внутрішній маршрут назад до VPN‑підмережі; або натуйте (менш елегантно, але ефективно) залежно від обмежень мережі.

8) Симптом: «Воно помирає, коли екран телефону вимикається»

Причина: Політика енергозбереження ОС призупиняє VPN‑процес або обмежує фонову мережу; cadence keepalive втрачає сенс, якщо процес не запускається.

Вирішення: Використовуйте платформено‑специфічні налаштування «always‑on VPN»; конфігуруйте правила on‑demand; на Android звільніть додаток від оптимізації батареї там, де політика дозволяє.

Три корпоративні історії з реальної практики

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула WireGuard для команди мобільних інженерів. Міграція пройшла гладко — поки не почала лаятися.
Користувачі скаржилися, що VPN «випадково відключається», коли вони виходять з офісу. Команда думала, що це баг WireGuard, бо UI все ще показував «підключено».

Перший респондент зробив те, що роблять усі під тиском: перезапустив сервіси. Це тимчасово допомогло.
Роумінг з Wi‑Fi на LTE створював нові вихідні порти. Сервер бачив пакети. Handshake оновлювався. Але додатковий трафік додатків помирав після хвилини простою.

Неправильне припущення було тонким: вони вірили, що NAT перед WireGuard‑сервером «достатньо stateful» і тримає UDP‑мапінги кілька хвилин.
У їхньому середовищі це не так. Таймаут UDP у NAT був короткий, а поведінка мобільного оператора ще коротша під час простою.

Виправлення було нудним і миттєвим: встановили PersistentKeepalive для мобільних клієнтів. «Відключення» зникли.
Постмортем не був «WireGuard потребує покращення». Це був висновок: «виміряйте мережу, яку маєте, а не ту, яку памʼятаєте».

Вони також оновили runbook: будь‑який звіт «відключення після простою» тепер спочатку тригерить перевірку conntrack/keepalive.
Інцидент не повторився — найвища похвала в операціях.

Міні‑історія 2: Оптимізація, що обернулась проти

Інша організація хотіла зменшити витрату батареї. Хтось помітив, що keepalive раз у 25 секунд і вирішив, що це «марнотратно».
Вони змінили keepalive на 120 секунд для мобільних пристроїв. В офісі виглядало нормально; вдома на Wi‑Fi теж.

Потім команда продажів поїхала в дорогу. Готелі, аеропорти, роздача інтернету через телефон, LTE — саме там, де таймаути NAT найменш передбачувані.
Кількість заявок різко зросла: CRM не завантажувався, внутрішні панелі таймаутились, «VPN нестабільний». Хелпдеск почав радити вмикати/вимикати режим літака — це не рішення, це ритуал.

Фіаско мало дві частини. По‑перше, деякі мережі завершували стан UDP значно менше двох хвилин.
По‑друге, коли телефони засипали, перший пакет після пробудження мав долати нові NAT‑мапінги і іноді втрачався; без частих keepalive навчання ендпойнтів відставало від очікувань користувача.

Вони повернули 25 секунд для таких користувачів і ввели політику: значення keepalive ділять за профілями користувачів.
Пристрої з високою чутливістю до батареї отримали 40 секунд після тестування; користувачі з високою мобільністю — 25. Правильна відповідь не «завжди підвищити keepalive».
Це «не оптимізуйте без бюджету відмов».

Вони також навчилися тестувати роумінг поза офісом. VPN, що працює лише на корпоративному Wi‑Fi — це локальна мережа у костюмі.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Фінансова компанія використовувала WireGuard у стеку віддаленого доступу. Нічого ефектного: стабільний порт, явні правила файрволу, консервативний MTU і суворе управління peer.
Їхній change management був так само нудний: керовані версії конфігів, поетапний rollout і щотижневий аудит на дублікати AllowedIPs.

Одного понеділка нова партія пристроїв була надана іншою командою. Тонка помилка створила дубльовані тунельні IP для кількох клієнтів.
У WireGuard AllowedIPs — це не просто «що маршрутизувати до peer». Це також те, як WireGuard вирішує, якому peer віддати пакети.
Дублі створюють хаос. Не завжди одразу. Найгірший вид.

Саме тут нудні практики окупилися. Їхнє аудиторське завдання швидко виявило дублікати.
Логи і знімки wg show вже збиралися в одному місці, тож on‑call зміг корелювати «флапи peer» з прокомою налаштування.

Вони призупинили provisioning, перемінили ключі у постраждалих peer і відновилися до того, як це стало широким інцидентом.
Ніхто не написав переможного внутрішнього блогу. Гарно. Результат — не «героїчне відновлення». Результат — «клієнти не помітили».

В операціях нудне — це функція. Захоплення — провісник майбутньої паперової роботи.

Контрольні списки / покроковий план

Покроково: Розгорнути WireGuard для мобільних користувачів, що роумлять

Оберіть модель маршрутизації: split tunnel, якщо немає реальної причини для повного тунелю.
Призначте стабільну тунельну підмережу: наприклад, 10.6.0.0/24, по одному /32 на пристрій.
Забезпечте унікальність: унікальний keypair на пристрій; унікальна тунельна IP на пристрій; жодного спільного «мобільного ключа».
Встановіть консервативний MTU: почніть з 1280 для мобільного розгортання; підвищуйте лише після тестування через LTE.
Увімкніть keepalive для клієнтів за NAT: почніть з 25 секунд, налаштовуйте залежно від виміряних таймаутів і впливу на батарею.
Зробіть правила файрволу явними: дозволіть UDP на порт WireGuard; логуйтe дропи під час rollout.
Увімкніть форвардінг і маршрути: не покладайтесь на NAT, якщо не потрібно; якщо робите повний тунель — налаштуйте NAT навмисно.
Визначте поведінку DNS: якщо DNS всередині — переконайтеся у доступності резолвера і інтеграції клієнта.
Тестуйте роумінг у реальних умовах: Wi‑Fi → LTE, LTE → Wi‑Fi, sleep/wake, tethering, captive portal‑сценарії.
Інструментуйте базову телеметрію: зберігайте періодичні знімки wg show, віку handshake і статистику інтерфейсів; налаштуйте алерт на «handshake never» для активних користувачів.

Операційний чеклист: Коли хтось повідомляє «VPN відключається на мобільному»

Чи сервер отримує UDP під час вікна помилки? (tcpdump)
Чи змінюються штампи handshake? (wg show)
Чи змінюється ендпойнт, коли користувач роумить? (wg show endpoints)
Чи налаштований keepalive на боці за NAT? (wg showconf)
Чи можна пропінгувати по IP через тунель? (ping до тунельної IP / внутрішньої IP)
Чи проходить DNS‑резолюція через DNS VPN? (resolvectl / dig)
Чи зменшення MTU вирішує проблеми з великими передачами? (ip link + ping -M do)
Чи немає дубльованих AllowedIPs або тунельних IP? (аудит конфігів)

Жарт №1: Якщо ваш план усунення несправностей починається з «перевстановіть VPN‑додаток», ви по суті вимикаєте і вмикаєте ще з додатковими кроками.

Поширені питання (FAQ)

1) Чи означає WireGuard roaming, що мені не потрібні keepalive?

Ні. Роумінг обробляє зміну ендпойнта під час потоку пакетів. Keepalive вирішують таймаути NAT під час простою, щоб пакети могли текти, коли ви відновите активність.
Якщо ваш клієнт бездіяльний за NAT, keepalive часто є різницею між «стабільно» і «таємниче померло».

2) Чому мій клієнт WireGuard каже «підключено», коли нічого не працює?

Тому що «підключено» часто означає «інтерфейс існує і конфіг завантажено», а не «зараз пакети течуть».
Перевірте latest handshake. Якщо він старий — ви насправді не підключені. Якщо нещодавній — дивіться MTU, маршрути і DNS.

3) Яке хороше значення PersistentKeepalive для телефонів?

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

4) Чи перепідключається WireGuard швидше за IPsec/IKE при роумінгу?

Часто так — бо він не вимагає важкої церемонії повторних переговорів просто щоб прийняти новий ендпойнт.
Але сприйняття користувача також залежить від DNS, MTU і здатності додатків повторно підключатися. WireGuard усуває одну велику перешкоду; він не перекладає всю дорогу.

5) Чи переривається SSH‑сесія, якщо мережа змінюється посеред сесії?

Це можливо. WireGuard може зберегти тунель, але TCP‑сесії можуть скидатись, якщо пакети втрачаються або якщо проміжні пристрої скидають стан.
Для віддалених шелів використовуйте mosh, якщо очікуєте роумінг, або переконайтеся, що шлях не містить stateful‑пристроїв, які панікують при зміні.

6) Чи варто запускати WireGuard на портах 53/123/443, щоб «пройти крізь мережі»?

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

7) Чому деякі внутрішні IP‑діапазони ламаються на публічному Wi‑Fi?

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

8) Чи справді MTU така поширена проблема з WireGuard?

Так. Особливо на мобільних пристроях. Роумінг змінює базовий шлях, і path MTU discovery не завжди надійно працює в усіх мережах.
Якщо великі завантаження зависають або деякі сайти вантажаться, а інші ні — MTU серед головних підозрюваних.

9) Чи підтримує WireGuard «multi‑endpoint» сервери для резильєнтності?

Не в сенсі переліку кількох ендпойнтів для одного peer. Ви можете побудувати резильєнтність через DNS, anycast, failover‑інструменти або кілька тунелів,
але сам WireGuard очікує один поточний ендпойнт на peer, який оновлюється під час навчання.

10) Чи WireGuard «безстанний»?

Ні. Він зберігає стан для peer: ключі, лічильники, ендпойнти, handshake‑часи. Просто він менш церемоніальний, ніж багато інших VPN.
Головне — стан оновлюється швидко і безпечно при зміні ендпойнта.

Жарт №2: NAT‑пристрої мають два хобі: завершувати UDP‑мапінги та навчати вас смиренності.

Наступні кроки, які ви можете зробити цього тижня

Якщо ви хочете менше квитків на мобільний VPN і менше скарг «воно знову відключилося», зробіть це в порядку:

Виміряйте здоровʼя handshake: збирайте віки handshake з wg show для активних користувачів; ставте алерт на «never» або застарілі handshake у робочий час.
Стандартизуйтеп keepalive для мобільних: встановіть PersistentKeepalive для клієнтів за NAT і документуйте відхилення від дефолту.
Встановіть консервативний MTU‑базовий рівень: оберіть 1280 для мобільного фокусу; підвищуйте тільки після реальних LTE‑тестів.
Зробіть DNS‑поведінку явною: або володійте DNS всередині тунелю наскрізно, або припиніть обіцяти внутрішні імена поза мережею.
Аудит конфігів peer: виявляйте дублікати ключів і AllowedIPs; негайно ротируйте все підозріле.
Попрактикуйте швидкий план діагностики: tcpdump → handshake → MTU/DNS/маршрути. Тренуйте це, поки не стане мʼязовою памʼяттю.

WireGuard roaming — це виправлення, яке усуває цілу категорію мобільних розривів VPN.
Але ви все одно маєте експлуатувати його як production‑систему: вимірювати, тестувати у ворожих мережах і свідомо робити конфігурацію нудною.