VPN: один параметр, що робить ваш тунель швидким… і небезпечним

Налаштування: split tunneling — код для обману продуктивності

Split tunneling — це вибір відправляти частину трафіку через VPN, а решту — напряму в інтернет (або в інші мережі) за допомогою локального маршруту за замовчуванням. Full-tunnel (іноді «force tunnel») надсилає фактично все через VPN: інтернет, SaaS, оновлення, DNS — усе.

З точки зору користувача split tunneling виглядає як магія. Менше буферизації Netflix. Zoom працює краще. «VPN» перестає бути винуватцем усього — від затримок до екзистенційного страху.

З точки зору оператора split tunneling — це політичне рішення, заховане за вимикач продуктивності. Ви не «прискорюєте тунель». Ви зменшуєте залежність від нього. Це може бути розумно. Це також може стати моментом, коли ви непомітно дозволяєте недовірені мережі стати частиною вашої моделі загроз.

Який саме регулятор ви крутите

• Область маршрутизації: Чи встановлюють клієнти маршрути 0.0.0.0/0 (та ::/0) на інтерфейс VPN, чи тільки маршрути для корпоративних підмереж?
• Область DNS: Чи використовують клієнти корпоративні резолвери для всіх запитів, чи тільки для внутрішніх доменів? Чи ви це контролюєте?
• Контроль виходу: Чи виконуються моніторинг безпеки, DLP, TLS-інспекція та логування на корпоративному egress… чи ні?

Якщо запам’ятати одне: split tunneling — це не лише маршрутизація; це відповідальність. Full-tunnel робить корпоративну мережу відповідальною за трафік клієнта. Split tunneling робить локальну мережу клієнта частиною шляху. Це інший світ.

Чому split tunneling швидший (і чому звинувачують full-tunnel)

Продуктивність — це конвеєр. Накладні витрати VPN — лише один етап. Full-tunnel часто повільніший, бо змушує трафік проходити через додаткові вузькі місця:

1) Hairpinning і подовження шляху

Full-tunnel означає, що ваш користувач у Берліні, що звертається до SaaS у Франкфурті, може маршрутизуватися так: Берлін → корпоративний VPN-концентратор у Вірджинії → назад у Франкфурт. Це не «накладні витрати шифрування». Це географія карає погану топологію.

2) Безпекові посередники стають вузьким місцем

Коли ви використовуєте full-tunnel, зазвичай ви також застосовуєте:

• Центральне DNS-фільтрування
• Політики проксі
• CASB-шлюзи
• Перевірку DLP
• Перехоплення SSL/TLS (де дозволено)

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

3) Проблеми MTU/MSS з’являються першими при full-tunnel

Капсулювання VPN зменшує ефективний MTU. Якщо ви не обмежите MSS або не встановите розумний MTU, отримаєте фрагментацію або «чорні діри» PMTUD. Симптоми: деякі сайти завантажуються, інші зависають; великі завантаження обриваються; SMB працює погано; «працює на хотспоті» стає діагностичним інструментом проклятих.

4) Ваш VPN-концентратор тепер ваш інтернет-шлюз

З full-tunnel ви створили централізований egress. Це концентрує пропускну здатність, NAT-стан, conntrack, CPU для шифрування і логи. Якщо планування ємності було оптимістичним, користувачі відчують це негайно.

Split tunneling відчувається швидким, тому що уникaє цих вузьких місць для не-корпоративного трафіку. Він не робить VPN по суті швидшим; він робить VPN менш задіяним.

Жарт №1: Увімкнути split tunneling, щоб виправити затори — це як прибрати дорожні знаки, щоб рух став швидшим. Так, речі рухаються — доки не доведеться пояснювати аварію.

Як split tunneling порушує припущення безпеки

Моделі безпеки спираються на припущення. Split tunneling непомітно анулює кілька поширених з них.

Припущення A: «Якщо ви в VPN, ви в довіреній мережі»

З split tunneling ви одночасно перебуваєте в двох мережах: корпоративній і локальній. Ваш ноутбук стає двосумісним (dual-homed) пристроєм. Якщо локальний мережевий трафік може досягати вашої машини, а ваша машина може досягати корпоративних ресурсів, ви створили міст. Чи це експлуатується — залежить від брандмауера хоста, стану кінцевої точки та сегментації. Але саме припущення вже зламане.

Припущення B: «Корпоративний моніторинг бачить ваш вихідний трафік»

Full-tunnel дає підстави вважати, що веб-трафік, DNS і певна телеметрія проходять через корпоративні контролі. З split tunneling користувач може «бути в VPN», але їх інтернет-трафік обходить ваші egress-логи цілком. Це впливає на:

• Час реагування на інциденти
• Застосування DLP
• Виявлення C2 (command-and-control)
• Контроль розташування даних / регуляторні вимоги

Припущення C: «DNS централізований, отже ми можемо контролювати і виявляти»

Split tunneling часто супроводжується split DNS: внутрішні імена — до корпоративних резолверів, зовнішні — локально. Якщо реалізація погана, ви випадково витікатимете внутрішні запити на публічні резолвери або створите неоднозначність резолюції, що ламає додатки і виглядає як «нестабільний VPN».

Припущення D: «Політи клієнта VPN можна застосувати»

На керованих пристроях ви можете примусово встановлювати маршрути, DNS і брандмауерні політики. На BYOD контроль слабший. Split tunneling на BYOD — це політика, яку ви не можете надійно аудіювати. Це погане поєднання.

Припущення E: «Латеральний рух починається всередині корпоративної мережі»

З split tunneling поверхня атаки включає локальні мережі: кав’ярні, готелі, домашній хаос IoT. Якщо кінцева точка скомпрометована через локальне ураження (evil twin AP, локальні broadcast-атаки, відкриті сервіси), атакуючий тепер має VPN-шлях у корпоративну мережу.

Що робити з цією реальністю

Якщо ви обираєте split tunneling — поводьтеся так, наче ви його обрали. Не робіть вигляд, що у вас все ще повноцінний full-tunnel-підхід до безпеки. Натомість:

• Зміцніть кінцеві точки: брандмауер хоста з політикою за замовчуванням блокувати вхідні з’єднання, жорсткі перевірки стану, швидке патчування.
• Зробіть доступ до корпоративних ресурсів «нульовою довірою»: доступ за додатком, політики на основі ідентичності, найменші привілеї, короткоживучі облікові дані.
• Сегментуйте внутрішні мережі так, щоб «користувач у VPN» не означав «бачить усе».
• Логуйте те, що має значення: ідентичність, рішення про доступ, сигнали від кінцевої точки — а не лише egress-логи.

І якщо вам потрібен full-tunnel для відповідності або моніторингу — то дотримуйтеся цього й інженерно забезпечте: регіональні egress, планування ємності, правильний MTU і раціональний DNS.

Цікаві факти та історичний контекст (коротко й корисно)

1. IPsec (IKE) став масовим наприкінці 1990-х, коли підприємствам потрібні були захищені site-to-site зв’язки без виділених приватних ліній.
2. PPTP широко використовувався в 1990-х через простоту, а не через якість. Згодом він асоціювався з «не використовуйте це».
3. SSL VPN виник у початку 2000-х, коли NAT і фаєрволи ускладнили класичні IPsec-клієнти; тунелі, дружні до HTTPS, перемогли політичні битви.
4. NAT traversal змінив ергономіку VPN: IPsec NAT-T (UDP-каскулювання) зробив VPN більш життєздатними за домашніми роутерами та Wi‑Fi готелів.
5. «Full tunnel» став за замовчуванням із ростом централізованих стеків безпеки; це поєднувалося з веб-проксі, централізованим DNS-фільтром і пізніше DLP/CASB.
6. Split tunneling дискутується десятиліттями, бо це питання політики: чи довіряєте ви кінцевій точці та локальній мережі?
7. Проблеми MTU загострилися при додаванні шарів інкапсуляції (VPN + VLAN + хмарні оверлеї). PMTUD у реальному світі ламкий.
8. WireGuard (середина–кінець 2010-х) популяризував простішу модель з легким крипто та конфігурацією, роблячи «швидкий VPN» реалістичнішим очікуванням.
9. Період віддаленої роботи під час COVID перетворив VPN-концентратори на інтернет-масштабні сервіси за одну ніч, оголивши помилки в плануванні ємності та змушуючи швидкі рішення, як-от split tunneling.

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

Міні-історія 1: Інцидент, викликаний хибним припущенням

Середня компанія впровадила split tunneling, щоб зменшити навантаження на перевантажені VPN-шлюзи. Це спрацювало. Квитки з темою «VPN повільний» зменшилися за тиждень, і керівництво назвало це перемогою.

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

Не було гаразд. Кінцева точка була скомпрометована в домашній мережі через звичайний інфостілер, який потім ескалював через кешовані сесії браузера. Через split tunneling C2-трафік ніколи не проходив через корпоративний egress. Першою реальною підказкою стала телеметрія ідентичності, а не мережеві логи.

Найболючіше було не саме порушення, а таймлайн. Команда витратила дні, шукаючи в неправильному місці: в проксі-логах і фаєрвол-логах, які ніколи не бачили цього трафіку.

Виправлення не було «заборонити split tunneling». Його залишили, але змінили модель: жорсткіша умовна авторизація, повторна автентифікація для адмін-порталів, тригери ізоляції кінцевих точок і явне навчання для реагування: «бути в VPN» не означає «ми бачили трафік».

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

Інженерний підрозділ вирішив прискорити віддалені розробницькі робочі процеси. Вони включили split tunneling і також звільнили кілька підмереж хмарних сервісів від VPN, щоб «зменшити затримку» до CI. Це зекономило кілька секунд на деяких збірках. Усі раділи.

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

Коренем була нудна й жорстока річ: їх внутрішній домен артефактів мав split-horizon DNS, але split-конфігурація іноді резолвила зовнішні кінцеві точки через локальний резолвер, коли корпоративний DNS відповідав повільно. Частина трафіку йшла не через VPN, потрапляла на публічний mirror і повертала артефакти, що не відповідали внутрішнім очікуванням. Перевірки цілісності врятували їх від постачальницької ланцюгової проблеми, але продуктивність впала.

Вони виправили це меншою кмітливістю: внутрішні домени завжди використовували корпоративний DNS, і ті сервери зробилися доступні та швидкі звідусіль. Також звузили правила маршрутизації, щоб внутрішні піддомени ніколи не витікали на локальні резолвери.

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

Фінансова фірма мала політику full-tunnel для керованих ноутбуків. Вони також мали звичку, що здавалася надмірною: кожна зміна VPN вимагала плану відкату і «smoke test list», виконаного з трьох мереж (домашній fiber, мобільний хотспот і ворожий гостьовий Wi‑Fi).

Під час рутинного оновлення клієнта VPN з’явилася тонка регресія MTU на одному провайдері. Великі HTTPS-відповіді застопорювалися; маленькі — працювали. Розробники могли увійти, але клонування великих репозиторіїв провалювалося, і деякі внутрішні веб-додатки частково завантажувалися, а потім зависали.

Smoke-тести зловили це в стейджингу з точною картиною симптомів: «працює на хотспоті, не працює на fiber». Команда відкотилася до загального впливу, потім протестувала з пакетними знімками. Проблема була в тому, що MSS не був обмежений після зміни на клієнті.

Без героїзму. Без багатогодинних ночей. Просто чеклист, потворна тестова матриця і людина, яку вже обпікало. Така практика окупилася в уникненому інциденті.

Швидкий план діагностики: що перевірити першим/другим/третім

Це послідовність «перестаньте гадати». Виконуйте її в порядку. Кожен крок покаже, куди дивитися далі.

Перший: визначте, чи проблема в області маршрутизації або в здоров’ї тунелю

• Чи повинен повільний пункт призначення бути доступним через тунель чи ні?
• Чи маршрут за замовчуванням йде через VPN (full-tunnel) або локально (split-tunnel)?
• Чи DNS для цього призначення надходить від корпоративних резолверів або локально?

Якщо трафік іде не туди, куди ви думаєте — всі інші виміри будуть шумом.

Другий: перевірте MTU/MSS і патерни «деякі сайти зависають»

• Малі сторінки завантажуються, великі завантаження зупиняються: підозрюйте MTU/PMTUD/MSS.
• Працює на хотспоті, але не на домашньому ISP: підозрюйте MTU або фільтрацію з боку провайдера.

Третій: локальний CPU і криптообмеження проти мережевих обмежень

• Високе навантаження CPU на клієнті під час передачі: накладні витрати шифрування або проблеми зі стеком ядра/мережі.
• Низьке завантаження CPU, але мала пропускна здатність: шлях/затримка, втрата пакетів або вузьке місце на шлюзі.

Четвертий: ємність шлюзу та middlebox-обладнання

• Перевірте CPU шлюзу VPN, пам’ять, conntrack, помилки NIC.
• Перевірте фаєрволи/проксі, що виконують інспекцію або формування.

П’ятий: виміряйте, де з’являється затримка

• Затримка виникає в рукопотисканнях VPN? DNS? Налаштуванні TCP? TLS? На рівні додатка?
• Використовуйте traceroute і пакетні знімки, щоб вибрати шар, якому дорікати.

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

Це ті завдання, які я реально виконую, коли хтось каже «VPN повільний» або «split tunneling це виправило». Налаштуйте імена інтерфейсів і адреси під своє оточення.

Завдання 1: Підтвердіть інтерфейс VPN і призначену адресу

cr0x@server:~$ ip -brief addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.10.20.15/24 fe80::5054:ff:fe12:3456/64
wg0              UP             10.99.0.12/32

Значення: wg0 існує і працює; адреса VPN — 10.99.0.12/32.

Рішення: Якщо інтерфейс VPN відсутній або DOWN — зупиніться. Виправте підключення клієнта перед налаштуванням продуктивності.

Завдання 2: Визначте, чи ви full-tunnel або split-tunnel

cr0x@server:~$ ip route show default
default via 10.10.20.1 dev eth0 proto dhcp src 10.10.20.15 metric 100

Значення: Маршрут за замовчуванням локальний через eth0. Це split tunneling (принаймні для IPv4 default).

Рішення: Якщо ви очікували full-tunnel, ваша політика не застосована або її перекривають. Виправте маршрути перш ніж ганятися за пропускною здатністю.

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

cr0x@server:~$ ip route | grep -E '10\.50\.|172\.16\.|192\.168\.200'
10.50.0.0/16 dev wg0 proto static
192.168.200.0/24 dev wg0 proto static

Значення: Тільки конкретні префікси йдуть через VPN. Це split tunneling за дизайном.

Рішення: Підтвердіть, що список префіксів відповідає реальності. Відсутня підмережа виглядає як «VPN не може дістатися до додатка» і неправильно діагностується як повільність.

Завдання 4: Підтвердіть фактичний вибір шляху до пункту призначення

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 dev wg0 src 10.99.0.12 uid 1000
    cache

Значення: Трафік до 10.50.12.34 використає wg0.

Рішення: Якщо він маршрутує через eth0 або інший інтерфейс — ваша split-політика неправильна (або є конфлікт маршрутів).

Завдання 5: Перевірте, який резолвер DNS використовується (приклад systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1

Link 3 (wg0)
    Current Scopes: DNS
         Protocols: -DefaultRoute
       DNS Servers: 10.50.0.53
        DNS Domain: corp.example

Значення: Зовнішній DNS йде до 1.1.1.1, внутрішній домен corp.example — до 10.50.0.53 через VPN.

Рішення: Якщо внутрішні запити йдуть до публічних резолверів — у вас DNS-витік і ймовірні переривання резолюції. Виправте політику split DNS.

Завдання 6: Підтвердіть, що внутрішні імена резолюються корпоративним DNS

cr0x@server:~$ dig +short @10.50.0.53 intranet.corp.example
10.50.12.34

Значення: Корпоративний DNS резолвить внутрішнє ім’я.

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

Завдання 7: Виявити витік DNS, порівнявши резолвери

cr0x@server:~$ dig +time=1 +tries=1 @1.1.1.1 intranet.corp.example
; <<>> DiG 9.18.24-1 <<>> +time=1 +tries=1 @1.1.1.1 intranet.corp.example
;; connection timed out; no servers could be reached

Значення: Публічний резолвер не знає внутрішнього домену (добре). Якби відповідав — ви, ймовірно, опублікували щось випадково.

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

Завдання 8: Перевірте MTU на інтерфейсах

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

Значення: WireGuard MTU — 1420, типовий безпечний параметр.

Рішення: Якщо MTU занадто великий (наприклад, 1500 поверх інкапсульованого шляху), очікуйте чорні діри. Розгляньте зниження MTU або застосування MSS clamping.

Завдання 9: Відтворіть проблеми MTU/PMTUD за допомогою ping з «не фрагментувати»

cr0x@server:~$ ping -M do -s 1372 -c 3 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1372(1400) bytes of data.
1380 bytes from 10.50.12.34: icmp_seq=1 ttl=63 time=42.1 ms
1380 bytes from 10.50.12.34: icmp_seq=2 ttl=63 time=41.7 ms
1380 bytes from 10.50.12.34: icmp_seq=3 ttl=63 time=42.5 ms

--- 10.50.12.34 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Значення: Пакети такого розміру проходять без фрагментації.

Рішення: Якщо ви бачите «Frag needed» або тайм-аути на помірних розмірах — налаштуйте MTU/MSS. Часто це прихована причина «VPN повільний».

Завдання 10: Перевірте правила TCP MSS clamping (приклад iptables)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i mss
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Значення: MSS clamping увімкнено для TCP, що пересилається в тунель.

Рішення: Якщо відсутнє і ви бачите симптоми MTU — додайте MSS clamping (або виправте MTU). Якщо є, але неефективне — ваш трафік може не проходити через цей вузол.

Завдання 11: Виміряйте сире пропускання через тунель за допомогою iperf3

cr0x@server:~$ iperf3 -c 10.50.12.34 -t 10
Connecting to host 10.50.12.34, port 5201
[  5] local 10.99.0.12 port 53322 connected to 10.50.12.34 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.2 MBytes  94.0 Mbits/sec    0   1.12 MBytes
[  5]   1.00-2.00   sec  10.8 MBytes  90.4 Mbits/sec    3   1.02 MBytes
[  5]   2.00-3.00   sec  10.6 MBytes  88.8 Mbits/sec    1   1.05 MBytes
[  5]   3.00-4.00   sec  10.9 MBytes  91.2 Mbits/sec    0   1.09 MBytes
[  5]   4.00-5.00   sec  10.7 MBytes  89.6 Mbits/sec    2   1.01 MBytes
[  5]   5.00-6.00   sec  10.8 MBytes  90.4 Mbits/sec    0   1.08 MBytes
[  5]   6.00-7.00   sec  10.7 MBytes  89.6 Mbits/sec    1   1.03 MBytes
[  5]   7.00-8.00   sec  10.9 MBytes  91.2 Mbits/sec    0   1.10 MBytes
[  5]   8.00-9.00   sec  10.7 MBytes  89.6 Mbits/sec    2   1.00 MBytes
[  5]   9.00-10.00  sec  10.8 MBytes  90.4 Mbits/sec    0   1.06 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   108 MBytes  90.6 Mbits/sec   12             sender
[  5]   0.00-10.00  sec   107 MBytes  90.0 Mbits/sec                  receiver

Значення: ~90 Mbit/s через тунель, є деякі повторні передачі, але нічого катастрофічного.

Рішення: Якщо пропускна здатність низька і повторні передачі високі — підозрюйте втрати/MTU/шлях. Якщо пропускна здатність обмежена при низьких втратах — підозрюйте CPU/крипто або формування (shaping).

Завдання 12: Перевірте навантаження CPU на клієнті під час передачі

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0-21-generic (laptop) 	02/04/2026 	_x86_64_	(8 CPU)

02:11:30 PM  CPU    %usr   %nice    %sys %iowait   %irq  %soft  %steal  %guest  %gnice   %idle
02:11:31 PM  all   18.21    0.00    6.12    0.11   0.00   1.33    0.00    0.00    0.00   74.23
02:11:32 PM  all   19.02    0.00    6.41    0.00   0.00   1.58    0.00    0.00    0.00   72.99
02:11:33 PM  all   17.88    0.00    6.05    0.00   0.00   1.49    0.00    0.00    0.00   74.58

Значення: CPU не завантажений; ймовірно клієнт не обмежений криптою.

Рішення: Якщо CPU близький до 100% під час передачі — швидші шифри/апаратне оффлоад або інший протокол VPN можуть відігравати більшу роль, ніж політика маршрутизації.

Завдання 13: Визначте втрати пакетів і джиттер до VPN-шлюзу

cr0x@server:~$ mtr -rwzbc 50 vpn-gw.corp.example
Start: 2026-02-04T14:12:10+0000
HOST: laptop                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.20.1                  0.0%    50    1.2   1.3   0.9   3.9   0.5
  2.|-- 100.64.0.1                  0.0%    50    6.7   6.9   5.8  11.2   1.0
  3.|-- 203.0.113.10                0.0%    50   18.0  18.3  16.7  25.9   1.9
  4.|-- vpn-gw.corp.example         0.0%    50   42.8  43.1  40.9  52.0   2.1

Значення: Немає втрат, стабільна латентність. Добре.

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

Завдання 14: Підтвердіть, чи змінюється ваша публічна IP з VPN (швидка перевірка full-tunnel)

cr0x@server:~$ curl -4 ifconfig.me
198.51.100.44

Значення: Це ваша поточна IPv4-адреса egress. При full-tunnel вона має співпадати з корпоративним egress; при split-tunnel — з локальним ISP.

Рішення: Якщо політика вимагає корпоративного egress, а ви бачите адресу провайдера — ви не у full-tunnel (або є витік).

Завдання 15: Перевірте рукопотискання WireGuard і лічильники трафіку

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

peer: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
  endpoint: 203.0.113.50:51820
  allowed ips: 10.50.0.0/16, 192.168.200.0/24
  latest handshake: 23 seconds ago
  transfer: 1.92 GiB received, 336.45 MiB sent
  persistent keepalive: every 25 seconds

Значення: Рукопотискання недавнє; тунель живий; маршрути розділені через allowed ips.

Рішення: Якщо рукопотискання старе і трафік застопорився — підозрюйте таймаути NAT, блокування UDP або проблеми з роумінгом. Розгляньте keepalive або TCP-базований VPN як запасний варіант.

Завдання 16: Перевірте навантаження conntrack на Linux VPN-шлюзі

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 248912
net.netfilter.nf_conntrack_max = 262144

Значення: Conntrack близький до максимуму; нові з’єднання можуть скидатися або зависати. Користувачі називатимуть це «повільний VPN».

Рішення: Збільшіть conntrack max (з урахуванням RAM), зменшіть egress-навантаження full-tunnel або масштабуйте шлюзи.

Жарт №2: Налаштування продуктивності VPN — це мистецтво рухати пакети швидше, рухаючи менше пакетів. Бухгалтери називають це «оптимізацією витрат».

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

1) «VPN повільний, але тільки для деяких сайтів»

Симптом: Маленькі сторінки завантажуються; великі активи зависають; завантаження зупиняються; Slack працює, але ваш внутрішній дашборд не повністю рендериться.

Корінь проблеми: MTU/PMTUD чорна діра через інкапсуляцію або відсутність MSS clamping.

Виправлення: Знизьте MTU тунелю і/або обмежте MSS на шляху, який пересилає в тунель. Перевірте DF-пінгами і захопленням пакетів.

2) «Увімкнення split tunneling виправило все»

Симптом: Продуктивність суттєво покращилася при включенні split tunneling.

Корінь проблеми: Full-tunnel шлях робить hairpin через далекий egress або перевантажений стек інспекції/egress.

Виправлення: Додайте регіональні VPN-шлюзи/egress, обійдіть важку інспекцію для низькоризикових напрямків, або використовуйте per-app VPN замість «все або нічого».

3) «Внутрішній додаток повільний тільки через VPN; ping показує нормально»

Симптом: ICMP-латентність нормальна; додаток гальмує, особливо під час логіну або API-запитів.

Корінь проблеми: Затримки DNS, затримки TLS-рукопотискання, петлі автентифікації проксі або втрата пакетів, що більше впливає на TCP ніж на ICMP.

Виправлення: Виміряйте час DNS-запиту, TCP connect і TLS handshake. Не робіть з ping релігію продуктивності.

4) «Після ввімкнення split tunneling ми не можемо дістатися деяких внутрішніх підмереж»

Симптом: Доступні лише частини корпоративної мережі; деякі хости таймаутять.

Корінь проблеми: Відсутні маршрути/allowed IPs, перекриття RFC1918 з домашніми мережами або конфліктні метрики маршрутів.

Виправлення: Додайте явні маршрути, уникайте перекриття адресного простору де можливо, або використайте NAT/перетворення для віддаленого доступу. Перевірте з ip route get.

5) «Ми ввели full-tunnel заради безпеки, а Zoom став неюзабельним»

Симптом: Затримки відео/аудіо, втрата пакетів, погана якість дзвінка.

Корінь проблеми: Реальний час трафіку змушують йти через далекий egress і інспектувальні посередники; DSCP-позначки можуть губитися; NAT-стан перевантажений.

Виправлення: Використайте split tunneling для дозволених служб реального часу (якщо політика дозволяє), або впровадьте локальний breakout/SD-WAN-стиль egress ближче до користувачів. Пріоритизуйте UDP-шляхи.

6) «Користувачі «в VPN», але внутрішній DNS рандомно падає»

Симптом: Внутрішні імена інколи резолюються, інколи таймаутять; переключення мереж «вирішує» проблему.

Корінь проблеми: Налаштування split DNS, DNS-сервери доступні тільки через конкретний тунель, або флапінг вибору резолвера.

Виправлення: Зробіть корпоративний DNS доступним і резервним, закріпіть внутрішні зони на корпоративних резолверах і встановіть явні правила маршрутизації DNS-трафіку.

7) «Безпека хоче full-tunnel, мережі хочуть split tunneling, ніхто не задоволений»

Симптом: Безкінечні дебати, немає рішення, багато виключень.

Корінь проблеми: Ви намагаєтесь використовувати мережевий тунель як універсальний засіб безпеки.

Виправлення: Перенесіть контролі вгору по стеку: стан пристрою, проксі з авторизацією за ідентичністю, доступ на рівні додатка і сегментація. Потім обирайте split або full на основі вимірюваних вимог, а не відчуттів.

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

Чеклист прийняття рішення: чи дозволяти split tunneling?

1. Відповідність: Чи є вимоги, що зобов’язують корпоративний egress для всього трафіку? Якщо так — віддайте перевагу full-tunnel і інженеруйте це.
2. Контроль пристрою: Чи керуються кінцеві пристрої з примусом брандмауера та перевіркою стану? Якщо ні — будьте дуже обережні зі split tunneling.
3. Внутрішня сегментація: Якщо пристрій скомпрометовано, чи може він дістатися «всього» через VPN? Якщо так — ви покладаєтеся на тунель як на рів захисту. Спочатку виправте сегментацію.
4. Стратегія моніторингу: Чи зможе IR працювати з ідентичністю + телеметрією кінцевої точки, якщо видимість egress зменшиться? Якщо ні — не прикидайтеся, що split tunneling нешкідливий.
5. Топологія: Чи маєте регіональні шлюзи/egress? Якщо ні — ваш досвід full-tunnel буде повільним для віддалених користувачів; або інвестуйте, або прийміть split tunneling з запобіжними заходами.

Чеклист продуктивності: зробіть full-tunnel терпимим

1. Розміщуйте шлюзи поруч із користувачами (регіонально) та регулярно тестуйте failover.
2. Підберіть пропускну здатність, conntrack/NAT-стан і CPU для шифрування.
3. Навмисно виправте MTU/MSS; не сподівайтеся, що PMTUD працюватиме.
4. Зробіть DNS швидким, резервним і доступним; вимірюйте його.
5. Визначте, що інспектується, а що ні; документуйте винятки як політику, а не як племінне знання.
6. Вимірюйте досвід користувача синтетичними тестами з типових last-mile мереж.

Чеклист безпеки: якщо ви використовуєте split tunneling, робіть це свідомо

1. За замовчуванням забороняйте вхідні з’єднання на кінцевих точках; блокуйте локальний підмережевий вхід, якщо він не потрібен.
2. Використовуйте доступ на рівні додатка або проксі з авторизацією за ідентичністю для критичних додатків.
3. Застосовуйте MFA і підвищену автентифікацію для чутливих операцій.
4. Скорочуйте життєвий термін облікових даних; зменшуйте використання довгоживучих сесій.
5. Зміцнюйте DNS: внутрішні зони — до корпоративних резолверів; запобігайте витокам внутрішніх запитів.
6. Інструментуйте кінцеві точки та ідентичність; припускайте меншу мережеву видимість.
7. Обмежуйте маршрути VPN лише тим, що потрібно; «весь RFC1918» — це ліниве і небезпечне рішення.

План змін: розгортання split tunneling без хаосу

1. Визначте масштаб: Який трафік виключається (маршрут за замовчуванням в інтернет? конкретні SaaS? медіа в реальному часі?) і чому.
2. Омоделюйте загрози: Ризики двостороннього підключення, шляхи витоку даних, DNS-витоки і прогалини видимості для реагування.
3. Пілот: Почніть з контрольної групи на керованих пристроях; збирайте телеметрію продуктивності та безпеки.
4. Запобіжні заходи: Застосуйте брандмауер хоста, перевірки стану та внутрішню сегментацію перед широким розгортанням.
5. Виміряйте: Використовуйте iperf3, затримку DNS і синтетичні тести додатків до/після.
6. Документуйте: Оновіть runbook-и реагування: де є логи, а де їх немає.
7. Відкат: Залиште кнопку повернення до full-tunnel на випадок інцидентів.

Інженерна цитата (бо це насправді проблема операцій)

Парафразована ідея — Werner Vogels: «Усе ламається, весь час.»

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

FAQ

1) Що саме за «одне налаштування», що робить VPN швидким і небезпечним?

Split tunneling. Воно покращує відчутну швидкість, дозволяючи некорпоративному трафіку обминати шлях VPN і корпоративні egress-контролі. Це також зменшує централізовану видимість і може створити ризики двостороннього підключення.

2) Чи завжди split tunneling небезпечний?

Ні. Воно менш безпечне відносно моделі, яка припускає «VPN = довірена, моніторована мережа». З міцною безпекою кінцевих точок, сегментацією та контролем доступу на основі ідентичності split tunneling може бути прийнятним компромісом.

3) Чому full-tunnel так сильно пригальмовує SaaS?

Зазвичай через топологію і middlebox-и: hairpin-маршрути через далекі шлюзи плюс проксі/DLP/стек інспекції. Накладні витрати на крипто рідко є основною причиною на сучасному обладнанні.

4) Чи можу я зберегти full-tunnel, але покращити продуктивність?

Так: регіональні шлюзи, локальний breakout з політикою, ресурси для NAT/conntrack, правильний MTU/MSS і швидкий DNS. Full-tunnel не приречений; просто часто недобудований.

5) Який найшвидший спосіб підтвердити, чи трафік іде через VPN?

Перевірте маршрут за замовчуванням і lookup маршруту до цілі через ip route get. Для інтернет-egress порівняйте публічну IP-адресу підключення.

6) Яка найпоширеніша «повільність VPN», що насправді не про пропускну здатність?

Проблеми MTU/MSS. Вони створюють затримки і повторні передачі, що відчуваються як повільність і з’являються тільки для певних сайтів чи розмірів корисного навантаження.

7) Чи викликає split tunneling витоки DNS?

Може, особливо при налаштуванні split DNS, що не закріплене правильно. Якщо внутрішні запити йдуть до локальних резолверів — ви витікаєте метадані і отримуєте нестабільну поведінку додатків.

8) Чи WireGuard по суті швидший за OpenVPN?

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

9) Як перекриття домашніх мереж ламає split tunneling?

Якщо корпоративна мережа використовує ті ж приватні діапазони, що й домашня (звично 192.168.1.0/24), маршрути можуть надавати перевагу локальній мережі і «внутрішній» трафік ніколи не потрапляє в VPN. Виправляйте невідповідним адресуванням, NAT або явними маршрутами/перетвореннями.

10) Що ми маємо логувати, якщо split tunneling зменшує видимість мережі?

Події ідентичності, сигнали стану пристрою, метадані сесії VPN і логи доступу додатків. Слідкуйте за кінцевою точкою та додатком як за новим периметром — бо так воно і є.

Практичні кроки далі

Якщо ви вагаєтесь між «швидко» і «безпечно», ви вже втрачаєте час. Зробіть так:

1. Виміряйте поточне вузьке місце за допомогою швидкого плану діагностики. Доведіть, чи проблема в маршрутизації, MTU, втратах, ємності шлюзу чи інспекції.
2. Якщо потрібен full-tunnel — інженеруйте його: регіональні шлюзи, правильний MTU/MSS, достатньо conntrack/NAT-стану і DNS, що не хитнеться під навантаженням.
3. Якщо ви обираєте split tunneling — змініть модель безпеки: зміцнені кінцеві точки, сегментація і контроль на основі ідентичності. Оновіть runbook-и реагування відповідно.
4. Запишіть політику простою мовою: що обходить тунель, що ніколи не обходить, і які винятки. Потім протестуйте це в реальних мережах, а не тільки в офісному Wi‑Fi.

Тунель — не ваш продукт. Надійний доступ — це. Split tunneling може бути інструментом, але це не безкоштовний обід — скоріше обід із сюрпризом від аудиту.