L2TP/IPsec підключається, але інтернет не працює: чому так відбувається і як це виправити

Що насправді означає «підключено» в L2TP/IPsec

L2TP/IPsec — це, по суті, два протоколи під одним капотом:

• IPsec забезпечує шифрування та транспорт пакетів, зазвичай з IKEv1 (часто в UI клієнтів відображається як «L2TP/IPsec PSK»). Він погоджує ключі та встановлює SA (Security Associations). Якщо це працює, можна чесно сказати «тунель піднято».
• L2TP працює всередині IPsec і встановлює PPP-сеанс. Саме PPP надає IP-адресу, DNS-сервери та іноді маршрут за замовчуванням або інші призначені маршрути.

Отже, «підключено» може означати будь-що з наступного:

1. IKE пройшов; IPsec SA існують; L2TP так і не запустився. UI все одно може показати успіх залежно від клієнта.
2. L2TP піднявся; PPP аутентифікувався; клієнт отримав IP; але маршрути не змінилися так, як ви очікували.
3. Маршрути змінилися; пакети йдуть; але NAT/брандмауер на сервері блокує зворотний трафік.
4. Все «в порядку», окрім того, що DNS вказує на резольвер, до якого клієнт не може дістатися через VPN.
5. Все «в порядку», поки MTU/фрагментація не вбивають великі пакети і веб-серфінг не перетворюється на танець у стилі інтерпретацій.

Правило перше: сприймайте «підключено» як підказку, а не як діагноз.

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

Цікаві факти та контекст (чому цей стек так поводиться)

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

1. L2TP має коріння в L2F і PPTP. Його стандартизували в кінці 1990‑х як спосіб тунелювання PPP через IP-мережі. Припущення PPP усе ще просочуються скрізь.
2. L2TP не забезпечує шифрування. Тому зазвичай використовують «L2TP/IPsec». L2TP — це рівень сесії; IPsec — рівень безпеки.
3. Більшість клієнтів використовують IKEv1 для L2TP/IPsec. Сучасні розгортання IPsec віддають перевагу IKEv2, але стеки L2TP часто лишаються на IKEv1 заради сумісності.
4. NAT‑Traversal став реальністю за замовчуванням. Спершу IPsec погано уживався з NAT. NAT‑T інкапсулює ESP в UDP/4500, щоб вижити за звичайними роутерами споживача.
5. L2TP використовує UDP/1701. В L2TP/IPsec UDP/1701 зазвичай захищений IPsec; якщо ви бачите його у відкритому вигляді в інтернеті, швидше за все це неправильна конфігурація.
6. Windows «підключено» не гарантує зміну маршруту за замовчуванням. Залежно від налаштувань (split tunneling, метрики, «use default gateway on remote network») ваш інтернет-маршрут може лишитися локальним.
7. Опції PPP мають значення. Такі речі, як MRU/MTU, призначення DNS і параметри «defaultroute», можуть зламати зручність використання.
8. Багато серверів L2TP побудовані зі старих компонентів. Типові Linux-стеки: strongSwan/Libreswan + xl2tpd + pppd — у кожного свої логи, таймери та режими відмов.
9. ESP — це IP‑протокол 50, не TCP/UDP. Брандмауери, які «дозволяють IPsec», але забувають протокол 50, створюють специфічні напівробочі ситуації (або примушують NAT‑T несподівано).

Швидкий план діагностики (перевірте 1, 2, 3)

Якщо ви на чергуванні, у вас немає часу заново відкривати мережі. Ось найшвидший шлях до вузького місця.

1) Це маршрутизація чи DNS?

• Перевірте доступність по IP (ping до публічної IP, наприклад 1.1.1.1 або до вашого публічного кінцевого вузла).
• Перевірте DNS окремо (розвʼяжіть імʼя, використовуючи DNS-сервери, які ви вважаєте налаштованими).

Якщо IP працює, а DNS ні: перестаньте чіпати IPsec. Виправляйте призначення DNS або доступність резольвера.

2) Чи йде трафік з клієнта через тунель?

• Перегляньте таблицю маршрутизації на клієнті. Шукайте маршрут за замовчуванням через PPP/інтерфейс тунелю (full tunnel) або конкретні маршрути (split tunnel).
• Перевірте метрики інтерфейсів: «правильний маршрут, неправильний пріоритет» — класика.

3) Чи повертається трафік?

• На сервері знімайте пакети на VPN-інтерфейсі та на аплінку. Якщо бачите пакети від клієнтів, що йдуть назовні, але немає зворотного перетворення — це NAT/брандмауер.
• Перевірте IP‑форвардинг і правила NAT/MASQUERADE.

4) Помилка відбувається лише для деяких сайтів або великих передач?

• Це MTU/фрагментація, поки не доведено протилежне. Тестуйте «don’t fragment» ping і обмежуйте MSS.

5) Це періодично?

• Шукайте проблеми з тайм‑аутами UDP/NAT state, перегенерацією ключів або кількома клієнтами за одним NAT з однаковими ідентифікаторами.

Реальні режими відмов: маршрутизація, NAT, DNS, MTU, брандмауер і політика

Режим відмов A: Клієнт ніколи не надсилає інтернет‑трафік у тунель (маршрути/метрики)

L2TP/IPsec часто розгортають як «full tunnel» (весь трафік через VPN), але клієнти часто налаштовані як split tunnel випадково — або через стару «оптимізацію», яку ніхто не документував.

Типові патерни:

• Маршрут за замовчуванням все ще вказує на локальний шлюз, а не на PPP.
• Існує маршрут за замовчуванням через VPN, але має вищу метрику, ніж локальний.
• Через тунель маршрутизуються лише корпоративні підмережі; інтернет залишається локальним. Користувачі сприймають це як «немає інтернету», бо корпоративний DNS змушує внутрішні шляхи розвʼязання імен.

Рішення: вирішіть, чи потрібен вам split tunnel або full tunnel. Після цього приведiть таблицю маршрутизації у відповідність із цим наміром.

Режим відмов B: Трафік заходить у тунель, але вмирає на сервері (відсутній форвардінг, NAT або брандмауер)

Це найпоширеніша корінна причина «підключено, але немає інтернету» на Linux‑концентраторах L2TP. PPP-сеанс піднятий. Клієнт має IP. Пакети приходять. Потім сервер просто ігнорує їх, бо:

• net.ipv4.ip_forward вимкнено.
• Не встановлено NAT‑маскараду для пулу клієнтів VPN до аплінка.
• Правила брандмауера дозволяють IKE/ESP/L2TP, але блокують форвардований трафік.
• Фільтрація зворотного шляху (rp_filter) відкидає асиметричні потоки.

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

Режим відмов C: Неправильний DNS (і все «виглядає відключеним»)

«Інтернет» через VPN часто зводиться до DNS. Браузеру потрібен DNS, щоб перетворити імена у IP. Якщо PPP підсовує DNS‑сервери, доступні лише в внутрішній мережі, яку ви не маршрутизували, отримуєте:

• Ping до 1.1.1.1 працює.
• Ping до example.com не працює.
• Додатки з жорстко вбудованими IP працюють; все інше — ні.

Рішення: узгодьте DNS з маршрутизацією. Full tunnel може використовувати внутрішні резольвери; split tunnel повинен використовувати доступні резольвери (публічні або DNS‑форвардер, доступний через split‑маршрути).

Режим відмов D: MTU та фрагментація (класичне «деякі сайти завантажуються, інші ні»)

L2TP + IPsec додають оверхед. Потім NAT‑T додає ще. PPP теж додає своє. Якщо ваш path MTU невеликий (поширено при PPPoE, LTE, готельному Wi‑Fi або «допоміжних» middlebox), великі пакети пропадають у чорну діру.

Симптоми включають:

• SSH працює, сторінки частково завантажуються, TLS‑з’єднання перериваються час від часу.
• Малі ping‑и успішні; великі — провалюються при встановленому DF.
• Тести швидкості починаються, а потім падають.

Виправлення: обмежте TCP MSS на сервері (а інколи й на клієнтах) і/або встановіть PPP MTU/MRU на консервативне значення (часто близько 1400, але перевіряйте).

Режим відмов E: Брандмауер і крайові випадки NAT‑T (UDP 4500, ESP і «стан»)

IPsec чутливий до брандмауерів, які налаштовані «майже правильно». Дозвіл UDP/500 та UDP/4500, але відсутність ESP (протокол 50) може примусити NAT‑T або зламати з’єднання в не‑NAT середовищі. Деякі мережі блокують UDP/4500 повністю. Інші дозволяють його, але видаляють довгоживучі UDP‑мапи, що спричиняє «підключився, а через кілька хвилин — тиша».

Рішення: вирішіть, чи потрібен вам NAT‑T, і налаштуйте keepalives/таймери рекідів відповідно до реальних тайм‑аутів NAT.

Режим відмов F: Перекривання підмереж (ви загнали себе в парадокс маршрутизації)

Якщо локальна LAN клієнта використовує ту саму підмережу, що й корпоративна мережа (наприклад: обидві 192.168.1.0/24), клієнт відправлятиме трафік у локальну мережу замість тунелю. VPN може бути ідеальний; рішення — ні.

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

Жарт #2: Перекривання підмереж — це як назвати двох співробітників «Кріс» і потім звинувачувати пошту, коли відповідає не той.

Практичні завдання з командами: що виконувати, що це означає, яке рішення прийняти

Нижче — перевірені завдання, які можна виконувати під час інциденту. Команди орієнтовані на Linux на боці сервера (strongSwan/xl2tpd/pppd), але логіка переноситься на інші платформи.

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

Завдання 1: Підтвердити існування IPsec SA (сервер)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.5.0, x86_64):
  uptime: 2 hours, since Dec 27 08:12:41 2025
  worker threads: 16 of 16 idle
Connections:
    l2tp-psk:  %any...%any  IKEv1
Security Associations (1 up, 0 connecting):
    l2tp-psk[3]: ESTABLISHED 6 minutes ago, 203.0.113.44[203.0.113.44]...198.51.100.10[198.51.100.10]
    l2tp-psk{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c2a3d8c4_i c8a1aa9b_o

Означає: IPsec піднято. Якщо користувачі все ще не мають інтернету, ймовірна причина — PPP/маршрутизація/NAT/DNS/MTU, а не IKE‑переговори.

Рішення: Перейдіть до перевірки PPP‑сеансів і форвардингу. Не витрачайте час на зміну PSK «про всяк випадок».

Завдання 2: Перевірити, що xl2tpd приймає сесії (сервер)

cr0x@server:~$ sudo journalctl -u xl2tpd -n 30 --no-pager
Dec 27 10:01:12 server xl2tpd[1290]: Connection established to 203.0.113.44, 1701, LNS session 4087
Dec 27 10:01:12 server xl2tpd[1290]: Call established with 203.0.113.44, Local: 53291, Remote: 22714, Serial: 1
Dec 27 10:01:13 server pppd[24410]: pppd 2.4.9 started by root, uid 0
Dec 27 10:01:13 server pppd[24410]: peer from calling number 203.0.113.44 authorized
Dec 27 10:01:13 server pppd[24410]: local  IP address 10.10.50.1
Dec 27 10:01:13 server pppd[24410]: remote IP address 10.10.50.101
Dec 27 10:01:13 server pppd[24410]: primary   DNS address 10.10.0.53

Означає: PPP піднятий і клієнт отримав 10.10.50.101 з DNS 10.10.0.53. Добре. Тепер перевірте маршрути і доступність 10.10.0.53 (і інтернету) із сервера.

Рішення: Якщо DNS внутрішній (10.10.0.53), переконайтесь, що клієнт може маршрутизуватися до 10.10.0.0/16 через VPN або що використовувався full tunnel.

Завдання 3: Підтвердити існування PPP‑інтерфейсу та адрес (сервер)

cr0x@server:~$ ip -br addr show | egrep 'ppp|eth0|ens'
ens3             UP             198.51.100.10/24
ppp0             UP             10.10.50.1/32

Означає: ppp0 піднятий з локальним /32. Це нормально для PPP. Клієнти по іншу сторону мають власні /32.

Рішення: Переконайтесь, що у вас є маршрут до пулу клієнтів через ppp‑інтерфейси або що правила брандмауера відповідають ppp+. Багато людей помилково пишуть правила для «10.10.50.0/24 через ppp0» і потім дивуються.

Завдання 4: Перевірити IP‑форвардинг (сервер)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Означає: Сервер не форвардить пакети між інтерфейсами. VPN‑клієнти підключаться, але не дістануться нічого за межами сервера.

Рішення: Увімкніть його стійко й негайно, якщо цей хост призначений для маршрутизації.

Завдання 5: Увімкнути IP‑форвардинг (сервер)

cr0x@server:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Означає: Форвардінг увімкнений тепер. Але все ще потрібні коректні правила брандмауера/NAT.

Рішення: Якщо це виправило проблему, зробіть це постійним через /etc/sysctl.d/*.conf і продовжуйте читати: форвардінг без правил брандмауера — шлях до несподіванок.

Завдання 6: Перевірити NAT (MASQUERADE) для пулу клієнтів VPN (сервер)

cr0x@server:~$ sudo iptables -t nat -S | egrep 'MASQUERADE|10\.10\.50'
-A POSTROUTING -s 10.10.50.0/24 -o ens3 -j MASQUERADE

Означає: Є outbound NAT для пулу клієнтів 10.10.50.0/24 до ens3 (аплінк в інтернет). Це зазвичай необхідно, щоб «VPN давав інтернет».

Рішення: Якщо цього рядка немає — додайте його. Якщо є, але трафік все одно падає — перевірте правила filter і rp_filter.

Завдання 7: Перевірити політику FORWARD і лічильники (сервер)

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i ppp+ -o ens3 -j ACCEPT
-A FORWARD -i ens3 -o ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT

Означає: Політика FORWARD — DROP (добра практика). Ви дозволяєте форвард ppp→інтернет і зворотний ESTABLISHED трафік. Також добре.

Рішення: Якщо у вас DROP без цих accept‑правил — додайте їх. Якщо вони є, але трафік не йде — перевірте, чи імена інтерфейсів відповідають реальності (ppp+ допомагає) і чи nftables не керує справою.

Завдання 8: Визначити, чи nftables — реальний брандмауер (сервер)

cr0x@server:~$ sudo nft list ruleset | head -n 25
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    udp dport {500, 4500, 1701} accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    iifname "ppp0" oifname "ens3" accept
    iifname "ens3" oifname "ppp0" ct state established,related accept
  }
}

Означає: nftables активний і має конкретні правила для ppp0. Якщо клієнти зʼявляються на ppp1/ppp2 — форвард може не працювати.

Рішення: Замість порівнянь з ppp0 використовуйте шаблон ppp+ або множини. Інакше перший клієнт працюватиме, а другий подзвонить вам опівночі.

Завдання 9: Переконатися, що сервер може дістатися інтернету (сервер)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=12.1 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Означає: Концентратор має базову звʼязність. Якщо VPN‑клієнти не мають інтернету, це не «інтернет впав».

Рішення: Сфокусуйтеся на форвардингу/NAT/виборі маршруту для клієнтського трафіку.

Завдання 10: Побачити, чи проходять пакети клієнта через сервер (tcpdump)

cr0x@server:~$ sudo tcpdump -ni ppp0 icmp or udp port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type PPP, snapshot length 262144 bytes
10:04:21.112233 IP 10.10.50.101 > 1.1.1.1: ICMP echo request, id 4112, seq 1, length 64
10:04:22.114455 IP 10.10.50.101 > 1.1.1.1: ICMP echo request, id 4112, seq 2, length 64

Означає: Клієнт надсилає трафік через тунель до сервера. Якщо ви не бачите відповідей — проблема в зворотному шляху: NAT, брандмауер або upstream‑маршрутизація.

Рішення: Зніміть трафік на ens3, щоб побачити, чи пакети виходять і чи приходять відповіді.

Завдання 11: Підтвердити, що здійснюється NAT‑перетворення (сервер, зйомка на аплінку)

cr0x@server:~$ sudo tcpdump -ni ens3 icmp and host 1.1.1.1
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:04:21.112900 IP 198.51.100.10 > 1.1.1.1: ICMP echo request, id 4112, seq 1, length 64
10:04:21.125001 IP 1.1.1.1 > 198.51.100.10: ICMP echo reply, id 4112, seq 1, length 64

Означає: NAT працює: джерело пакета — публічна IP сервера (198.51.100.10), і відповіді повертають. Якщо клієнти все одно не отримують відповіді, ваш FORWARD‑ланцюг назад до PPP може блокувати, або rp_filter відкидає.

Рішення: Перевірте правила форварда і rp_filter, потім перевірте, чи відповіді доходять до ppp0.

Завдання 12: Перевірити фільтрацію зворотного шляху (rp_filter) (сервер)

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.ens3.rp_filter net.ipv4.conf.ppp0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.ens3.rp_filter = 1
net.ipv4.conf.ppp0.rp_filter = 1

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

Рішення: Встановіть rp_filter на 0 (вимкнено) або 2 (loose) на відповідних інтерфейсах. Для VPN‑концентраторів loose‑режим часто є розумним компромісом.

Завдання 13: Протестувати розвʼязування DNS через підсунуті DNS‑сервери (перевірка на боці сервера)

cr0x@server:~$ dig @10.10.0.53 example.com +short
93.184.216.34

Означає: Внутрішній резольвер відповідає. Це не доводить, що клієнт може його дістати, але виключає одну змінну.

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

Завдання 14: Перевірити, що PPP підсовує потрібні DNS і маршрути (конфіг сервера)

cr0x@server:~$ sudo sed -n '1,120p' /etc/ppp/options.xl2tpd
ipcp-accept-local
ipcp-accept-remote
ms-dns 10.10.0.53
ms-dns 10.10.0.54
noccp
auth
mtu 1400
mru 1400
proxyarp

Означає: DNS підсунуті і MTU задано. Якщо користувачі скаржаться «деякі сайти завантажуються», MTU тут — добрий знак. Якщо MTU за замовчуванням (часто 1500), може знадобитися корекція.

Рішення: Якщо ви не контролюєте MTU/MRU тут — додайте їх і обмежте MSS на брандмауері.

Завдання 15: Виявити MTU‑чорну діру за допомогою DF ping (з сервера у бік шляху клієнта)

cr0x@server:~$ ping -M do -s 1472 -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1476
ping: local error: message too long, mtu=1476

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1024ms

Означає: Path MTU нижчий за 1500 (тут близько 1476 на цьому хопі), і якщо ICMP fragmentation‑needed блокується десь, клієнти відчують «випадкові» відмови.

Рішення: Обмежте MSS (наприклад, до 1360–1410 залежно від оверхеду) і/або знизьте PPP MTU/MRU. Перевірте ітеративно.

Завдання 16: Обмежити TCP MSS для форвардованого VPN‑трафіку (сервер)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -i ppp+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 2
-A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Означає: SYN‑пакети погоджуватимуть MSS, який вміщується в реальний path MTU, що зменшить проблеми з фрагментацією.

Рішення: Якщо це миттєво покращить надійність веб/TLS — збережіть правило й зробіть його постійним. Все одно перевірте, що PMTUD (ICMP) не блокується upstream.

Завдання 17: Перевірити наявність маршрутів до пулу клієнтів (маршрутизація сервера)

cr0x@server:~$ ip route show | egrep '10\.10\.50|default'
default via 198.51.100.1 dev ens3
10.10.50.101 dev ppp0 scope link

Означає: Для PPP часто виникають маршрути по‑клієнтські /32. Якщо ви очікували /24 — це ваша помилка, а не ядра.

Рішення: Переконайтесь, що правила брандмауера і моніторинг це розуміють. Використовуйте матчі по ppp+ інтерфейсу, а не покладайтесь на акуратні мережеві підмережі.

Завдання 18: Підтвердити, що UDP/4500 і ESP дозволені на периметрі (сервер)

cr0x@server:~$ sudo iptables -S INPUT | egrep 'udp.*(500|4500|1701)|esp'
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j ACCEPT
-A INPUT -p esp -j ACCEPT

Означає: Звичні порти і ESP дозволені. Якщо ESP відсутній і NAT‑T не використовується, ви отримаєте «іноді підключається» залежно від NAT‑умов клієнта.

Рішення: Дозвольте ESP, коли це можливо. Якщо не можете — вимагайте NAT‑T і забезпечте надійність 4500 end‑to‑end.

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

Історія 1: Інцидент через хибне припущення

Компанія мала старий концентратор L2TP/IPsec, який «завжди працював». Невелика міграція перемістила його з одного VM‑хоста на інший. Та сама IP. Ті самі правила брандмауера. Ті самі файли конфігурації. Запит на зміну був нудний — це зазвичай хороший знак.

Понеділком служба підтримки отримала потік викликів: VPN підключається, але «інтернет помер». Люди могли дістатися деяких внутрішніх сервісів, але не всіх, а більшість зовнішніх сайтів була недоступна. Мережевий відділ одразу звинуватив провайдера, бо так зазвичай роблять, коли браузер крутиться.

Хибне припущення: «якщо тунель піднятий, маршрутизація правильна». Насправді на новому гіпервізорі мережа використовувала іншу назву інтерфейсу (ens192 замість ens3). Правила NAT все ще посилалися на старий пристрій. Пакети приходили по ppp0, заходили в POSTROUTING, і… нічого не підходило. Нема маскараду. Нема інтернету.

Було ще гірше: кілька інженерів могли дістатися внутрішніх сервісів, бо split‑tunnel маршрути ще працювали для внутрішніх підмереж, тож симптоми виглядали непослідовно. Ця непослідовність витратила години. Вони шукали нестабільну мережу, коли причина була детермінована невідповідністю.

Фікс був брутально простий: оновити правило NAT, щоб воно відповідало реальному uplink‑інтерфейсу (або краще — орієнтуватися на таблицю маршрутизації / використовувати множини nftables). Потім додали перевірку на завантаженні, яка стверджує «якщо існує ppp+, правило NAT має бути». Урок закарбувався: ніколи не привʼязуйте критичну маршрутизацію/NAT до імені інтерфейсу, яким ви не керуєте.

Історія 2: Оптимізація, яка обернулася проти

Огляд безпеки вказав, що VPN‑користувачі відправляють увесь інтернет‑трафік через дата‑центр. Хтось запропонував split tunneling як оптимізацію: «Маршруйте через VPN лише корпоративні підмережі; все інше — локально. Менше навантаження, краща продуктивність». На папері — правильно. В продукції — комедія.

Вони підсунули split‑tunnel маршрути, але не узгодили DNS. PPP продовжував підсовувати внутрішні DNS, бо «так завжди робили». Тепер віддалені ноутбуки розвʼязували публічні домени через внутрішні резольвери, доступні лише через VPN, але запити йшли в тунель, а відповіді приходили локально — або взагалі не приходили через станфул брандмауери та асиметричну маршрутизацію на клієнті.

Симптом був гучним: «VPN підключено, інтернет не працює». Насправді проблема була вже в DNS: немає резолювання імен, переривчастий внутрішній доступ, деякі додатки (з жорстко вбудованими IP) ще працювали. Користувачі рідко повідомляють «проблеми з DNS»; вони кажуть «нічого не працює». Справедливо.

Тимчасово «вирішили» це, попросивши користувачів вказати публічні DNS. Це створило іншу проблему: внутрішні імена перестали резолюватися, і безпекові люди були незадоволені витоком внутрішніх запитів. Зрештою зробили правильно: надали DNS‑форвардер у VPN, який відповідає на внутрішні зони і рекурсивно для зовнішніх, і переконалися, що DNS‑запити слідують тій самій маршрутизаційній політиці, що й інший трафік.

Оптимізація — ок. Але split tunneling — це зміна політики маршрутизації, а не апгрейд CPU. Ставтеся до цього з тією ж уважністю, як до зміни рівня ізоляції в базі даних: краще виявите крайові випадки на практиці.

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

Інша організація використовувала L2TP/IPsec для парку промислових ноутбуків. Не гламурно. Але SRE‑команда мала звичку: кожна зміна VPN вимагала сценарію smoke test з зовнішнього раннера. Він робив: підключитися, перевірити виділений IP, пропингувати публічну IP, розвʼязати імʼя, завантажити невелику HTTPS‑сторінку і завантажити більший файл для тесту MTU/MSS.

Одного пʼятничного дня звичайне прибирання правил брандмауера видалило «дивні» застарілі правила. Наступний pipeline запустив smoke test і впав на «fetch HTTPS page». Ping працював. DNS працював. HTTP іноді працював. HTTPS падав. Тут більшість команд починають випадково перезапускати служби. Вони — ні.

Скрипт мав MTU‑пробу і позначив відмову фрагментації. Очищення брандмауера також видалило дозвіл на ICMP «fragmentation‑needed» і правило обмеження MSS. Без MSS‑clamp TLS‑пакети чорно вимерли на певних шляхах. Тест зловив це до того, як люди прокинулися.

Rollback був негайний. Вони повернули контрольований MSS‑clamp правило, задокументували, навіщо воно, і додали юніт‑тест брандмауера: «VPN‑клієнти повинні завершити TLS‑хендшейк до публічного кінцевого вузла». Нудно. Правильно. Це врятувало вихідні.

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

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

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

• Корінна причина: Клієнтський трафік не маршрутизується в тунель; або PPP-сеанс фактично не передає дані; або сервер блокує форвардінг.
• Виправлення: На клієнті перевірте маршрут за замовчуванням і метрики інтерфейсів. На сервері увімкніть IP‑форвардинг і дозвольте FORWARD трафік з ppp+ до uplink з NAT, якщо інтернет‑вихід через VPN потрібен.

2) Симптом: Можна пінгувати публічні IP, але сайти не завантажуються

• Корінна причина: Помилка в DNS (недоступні DNS‑сервери або клієнт не використовує підсунуті DNS).
• Виправлення: Підсовуйте доступні DNS через PPP‑опції (ms‑dns). Переконайтесь, що маршрути дозволяють доступ до цих резольверів. Для split tunnel використовуйте DNS‑форвардер, доступний через тунель.

3) Симптом: Завантажуються лише деякі сайти; HTTPS нестабільний; великі завантаження падають

• Корінна причина: MTU‑чорна діра або проблеми фрагментації через оверхед L2TP/IPsec і блокування ICMP.
• Виправлення: Обмежте TCP MSS на сервері для форвардованого VPN‑трафіку. Встановіть PPP MTU/MRU (наприклад, 1400) і протестуйте. Дозвольте потрібні типи ICMP, якщо контролюєте брандмауер.

4) Симптом: Внутрішні ресурси працюють; інтернет — ні

• Корінна причина: Split tunnel за дизайном або випадково; відсутній NAT для інтернет‑виходу; або політика забороняє інтернет через VPN.
• Виправлення: Визначте політику. Якщо потрібен full tunnel — пуште маршрут за замовчуванням (налаштування на клієнті) і налаштуйте NAT/форвардинг. Якщо потрібен split tunnel — пуште лише корпоративні маршрути і забезпечте адекватний DNS.

5) Симптом: Інтернет працює лише для першого підключеного клієнта

• Корінна причина: Правила брандмауера співставляють один інтерфейс (ppp0) замість усіх PPP‑інтерфейсів (ppp+), або NAT привʼязаний до конкретного інтерфейсу, що змінюється.
• Виправлення: Використовуйте шаблони ppp+ (iptables) або iifname/oifname патерни/множини (nftables). Уникайте крихких припущень про назви інтерфейсів.

6) Симптом: Підключення вдається в деяких мережах, але не в інших (готельний Wi‑Fi, LTE)

• Корінна причина: UDP 4500 блокується або дуже швидко тайм‑аутить; проблеми NAT‑T; проміжні пристрої пошкоджують ESP/UDP.
• Виправлення: Переконайтесь, що NAT‑T увімкнено і налаштовані keepalive. Якщо UDP ненадійний, розгляньте перехід з L2TP/IPsec на IKEv2 або TLS‑базований VPN, де це можливо.

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

• Корінна причина: Перекривання адрес RFC1918; клієнт віддає перевагу локальній LAN.
• Виправлення: Змініть корпоративну адресацію (найкраще), або зробіть NAT для VPN‑клієнтів на концентраторі, або використовуйте політичну маршрутизацію на клієнті. Мінімум — перестаньте використовувати 192.168.0.0/24 чи 192.168.1.0/24 для ресурсів, до яких мають доступ роумінгові клієнти.

8) Симптом: Учора працювало; сьогодні підключається, але після зміни брандмауера немає трафіку

• Корінна причина: Дозволені порти IKE/L2TP, але заблоковано форвард, DNS, ICMP fragmentation‑needed або зворотній стан трафіку.
• Виправлення: Аудит правил для: UDP/500, UDP/4500, UDP/1701 (як потрібно), ESP, плюс FORWARD і NAT. Поверніть MSS clamp і потрібні ICMP, якщо зʼявилися MTU‑проблеми.

Чеклісти / покроковий план

Чекліст 1: Визначте політику (full tunnel vs split tunnel)

• Full tunnel: Маршрут за замовчуванням клієнта іде через VPN. Потрібно налаштувати NAT і форвард на сервері. DNS може бути внутрішнім.
• Split tunnel: Через VPN йдуть лише корпоративні префікси. Потрібно пушити ці маршрути. DNS не має створювати залежність від недоступних внутрішніх резольверів (використовуйте форвардер, доступний через тунель).

Якщо ви не визначите це явно, система вирішить за вас — і вибір буде хаосом.

Чекліст 2: Необхідне на боці сервера (Linux L2TP/IPsec концентратор)

1. IPsec SA встановлені (strongSwan/libreswan показує INSTALLED).
2. xl2tpd бачить сесії; pppd аутентифікує; призначає IP клієнтам; підсовує DNS, якщо потрібно.
3. net.ipv4.ip_forward=1.
4. NAT‑masquerade для пулу клієнтів в напрямку аплінку (якщо full tunnel/internet egress).
5. Правила FORWARD дозволяють ppp+→uplink і повертають ESTABLISHED трафік.
6. Обмеження MSS для форвардованих TCP SYN або консервативний PPP MTU/MRU.
7. rp_filter встановлений у loose/off там, де потрібно.
8. Логи: strongSwan, xl2tpd, pppd збираються й доступні для пошуку.

Чекліст 3: Необхідне на боці клієнта (загальне)

1. Підтвердьте, що отримали IP на VPN‑інтерфейсі і розумієте налаштування DNS.
2. Перевірте таблицю маршрутів: у вас є маршрут за замовчуванням через VPN (full tunnel) або конкретні маршрути (split tunnel)?
3. Тестуйте: ping публічної IP, розвʼязування імені, curl HTTPS‑endpoint.
4. Якщо лише HTTPS падає: підозрюйте MTU/MSS і фрагментаційні чорні діри.
5. Якщо корпоративні ресурси недоступні з дому: підозрюйте перекривання підмереж.

Покроковий план відновлення під час відмови

1. Встановіть обсяг. Один користувач чи всі; конкретні мережі або всі; конкретна ОС клієнта чи всі.
2. Доведіть, що IPsec піднято. Якщо IPsec не працює — спочатку виправляйте IKE/PSK/сертифікати/порти. Якщо піднято — припиніть звинувачувати IKE.
3. Доведіть, що PPP піднято. Знайдіть призначену IP і DNS у логах pppd.
4. Доведіть намір щодо маршрутизації. Full tunnel чи split tunnel? Переконайтесь, що маршрути на клієнті відповідають політиці.
5. Доведіть форвард/NAT на сервері. tcpdump на ppp+ і uplink; перевірте MASQUERADE і правила FORWARD.
6. Доведіть DNS. Розвʼяжіть через DNS, який ви підсовуєте; підтвердьте доступність по маршрутах.
7. Доведіть MTU. Якщо симптоми «деякі сайти» — увімкніть MSS clamp і встановіть PPP MTU/MRU.
8. Стабілізуйте. Зробіть зміни постійними, додайте моніторинг і запишіть, що змінили й чому.

Операційний принцип (цитата)

«Сподівання — не стратегія.» — парафраз думки, приписуваної лідерам операцій та надійності

Переклад: якщо ваш VPN працює лише коли «мережа добра», він не працює. Зробіть його детермінованим.

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

1) Чому L2TP/IPsec показує «підключено», коли нічого не працює?

Бо «підключено» часто означає, що IKE пройшов і SA встановлені. Фактична придатність залежить від PPP, маршрутизації, NAT, брандмауера, DNS і MTU. Різні шари можуть завершитися успішно незалежно один від одного.

2) Це зазвичай проблема клієнта чи сервера?

Зазвичай це проблема на боці сервера: форвардінг/NAT/брандмауер або невідповідність політики (split vs full). Далі — клієнтські метрики маршруту і вибір DNS.

3) Якщо внутрішні ресурси працюють, а інтернет — ні, яка найімовірніша причина?

Або активний split tunnel (за дизайном або випадково), або відсутній NAT‑masquerade для пулу VPN. Визначте, чи VPN має забезпечувати інтернет‑вихід, і впровадьте це явно.

4) Якщо пінг до 1.1.1.1 працює, але сайти не працюють, що робити перш за все?

Перевірте DNS. Подивіться, які резольвери використовує клієнт і чи доступні вони через маршрути VPN. DNS‑проблеми — найшвидший спосіб отримати ілюзію «вимкнення» інтернету.

5) Який MTU варто використовувати для L2TP/IPsec?

Однозначного значення немає, але 1400 — поширена відправна точка для PPP MTU/MRU в L2TP/IPsec з NAT‑T. Краще: обмежити MSS до PMTU і верифікувати через DF ping і реальні HTTPS‑трансфери.

6) Чи потрібно дозволяти UDP/1701 через брандмауер?

Для L2TP/IPsec UDP/1701 використовується для контролю/даних L2TP і зазвичай захищений IPsec. Практично часто дозволяють UDP/1701 до VPN‑сервера, плюс UDP/500, UDP/4500 і ESP. Конкретний набір правил залежить від режиму IPsec і використання NAT‑T.

7) Що з клієнтами за одним NAT? Чи може це ламати зʼєднання?

Так. Кілька клієнтів за одним NAT можуть викликати крайові випадки NAT‑T, особливо з IKEv1 та однаковими ідентифікаторами. Переконайтесь, що конфігурація IPsec підтримує кількох peer’ів і використовує унікальні ID/логіни, та налаштуйте keepalive, щоб UDP‑мапи не втрачалися.

8) Чи може перекривання підмереж справді спричинити «немає інтернету»?

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

9) Чи варто продовжувати використовувати L2TP/IPsec?

Якщо вам потрібна максимальна сумісність з вбудованими клієнтами — так, воно залишиться. Якщо є вибір — віддавайте перевагу IKEv2 або сучасним TLS‑базованим VPN, які краще поводяться через NAT і мають чистіший клієнтський досвід. Але якщо ви мусите залишатися на L2TP/IPsec — зробіть його надійним: явно налаштуйте маршрути, DNS і MTU.

10) Який найефективніший моніторинговий чек для цього?

Запустіть зовнішній синтетичний тест, який встановлює VPN‑сесію і виконує: ping публічної IP, DNS‑lookup і HTTPS GET маленької сторінки плюс більший файл для завантаження. Це швидко виявляє регресії маршрутизації, DNS і MTU.

Наступні кроки (що змінити, щоб не повторюватися)

Виправити сьогоднішній інцидент — добре. Запобігти наступному — краще і, чесно кажучи, менш виснажливо.

1. Запишіть намір. Full tunnel чи split tunnel. Який DNS. Який пул клієнтів. Які підмережі. Зробіть це односторінковим runbook, що відповідає реальності.
2. Зробіть форвардінг/NAT детермінованим. Увімкніть ip_forward стійко, використовуйте шаблони інтерфейсів або маршрутизаційні відповідності, і зберігайте правила брандмауера під контролем версій.
3. Стандартизувати обробку MTU. Додайте MSS‑clamping для форвардованого трафіку і навмисно встановіть PPP MTU/MRU. Розглядайте PMTUD‑відмови як відомий ризик.
4. Припиніть відлагодження за статусом UI. Моніторьте IPsec SA, PPP‑сесії і end‑to‑end data‑plane тести окремо.
5. Додайте smoke test. Один скрипт зовні, що перевіряє підключення так, як це роблять користувачі. Запускайте після кожної зміни.
6. Плануйте міграцію. Якщо L2TP/IPsec — застарілий якір, визначте шлях до IKEv2 або іншого сучасного рішення. Не через моду — через операційну простоту.

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