Офісний VPN + VLAN: підключайте сегменти без зрівнювання мережі

November 26, 2025 • February 3, 2026 • Читання: 5 хв • Views: 9

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

Офіс розбитий на сегменти. VPN поміщає користувачів «всередину». Раптом сегментація стає… декларативною.
Ви думали, що даєте бухгалтерії доступ до фінансового додатка; насправді ви дали їм найкраще місце для сканування принтерів, гіпервізорів і всього, що має IP.

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

Ментальна модель: VPN — це маршрутизатор, а не чарівний коридор

VLAN призначені для розділення широкомовних доменів і створення адміністративних меж. VPN — для транспортування трафіку через недовірену або незручну мережу.
Погано поєднавши їх, ви не отримаєте «безпечний віддалений доступ». Ви отримаєте «ще один шлях до всього» з меншим контролем.

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

Як зазвичай виглядає «зрівнювання»

VPN‑клієнти отримують адресу в «довіреній» підмережі, яка може маршрутизуватися до всіх VLAN.
Правила фаєрвола кажуть «VPN → LAN дозволити», бо в тікеті вимагали «щоб працювало».
Розділення тунелю відключене «заради безпеки», тож кожен віддалений користувач стає ретранслятором через офіс.
Ніхто не може відповісти «який VPN‑користувач звертався до якої служби VLAN», без гадань.

Мета не в тому, щоб зробити VPN‑користувачів нещасними. Мета — зробити їхній доступ навмисним: конкретні мережі, конкретні порти, конкретні ідентичності з логами, що витримують перевірку.

Кілька фактів (і трохи історії), що змінюють рішення

VLAN походять із IEEE 802.1Q (кінець 1990‑х) як спосіб логічної сегментації на загальному комутуючому обладнанні. Вони ніколи не були самостійною системою контролю доступу.
IPsec спроєктували для ворожих мереж, але в підприємствах часто застосовують політики «дозволити все», бо узгодити «що дозволяти» соціально складніше, ніж криптографію.
Ранні VPN віддаленого доступу часто мостили рівень 2 (TAP‑пристрої, «bridge mode»), що робило Windows browsing і застарілі протоколи щасливими — і команди безпеки незадоволеними пізніше.
NAT став випадковим стандартом для домашніх мереж, тому VPN часто борються з накладенням простору RFC1918 у 2025 році.
Split tunneling існує задовго до “Zero Trust”. Це не автоматично небезпечно; воно небезпечне, коли ви не контролюєте стан пристрою та політику виходу.
Історично сегментація мереж виникла не лише з міркувань безпеки: обмеження широкомовних бур та ізоляція збоїв були практичними драйверами задовго до появи програм на кшталт ransomware.
802.1X NAC (портова автентифікація) намагалася зробити питання «хто на цьому порту?» першокласним. Багато організацій досі не впровадили його через необхідну операційну дисципліну.
Мислення «VPN всередині периметра» — це релікт з епохи, коли «всередині» означало «співробітники на корпоративних десктопах». BYOD і SaaS перетворили це на фольклор.

Висновок: VLAN — це межі, VPN — транспорт. Безпека відбувається в політиці маршрутизації, правилах фаєрвола, ідентичності та логуванні. Не в інтуїції.

Цілі проєктування, які зупиняють «пласку мережу випадково»

1) Явна доступність: менше маршрутів, а не більше надій

Ваш VPN має рекламувати лише те, що потрібно конкретній групі користувачів. Якщо клієнт може маршрутизуватися до кожного VLAN, хтось колись спробує. Іноді випадково, іноді — ні.
Чистий дизайн використовує пуші маршрутів для груп, або per‑peer AllowedIPs (WireGuard), або принаймні фаєрволінг за пулом адрес.

2) Застосовуйте сегментацію на рівні 3/4 (а іноді й 7)

VLAN тримають комутацію під контролем. Фаєрволи тримають бізнес під контролем. Розміщуйте примус там, де можна це логувати, переглядати і тестувати: на межі між VLAN та на вході VPN.
«Але комутатор підтримує ACL» — правда, і це також шлях до правил, які ніхто не може аудитувати.

3) Не робіть VPN транзитом для всього інтернету, якщо ви цього не плануєте

Full‑tunnel VPN іноді потрібен (регульовані середовища, суворий контроль виходу, небезпечні подорожі). Але це дорога опція:
пропускна спроможність, затримки, навантаження на офісний фаєрвол і неминучі тікети «Zoom лагає».
Якщо ви обираєте full‑tunnel, проектуйте його: ємність, QoS та чіткі еґрез‑контролі.

4) Робіть ідентичність видимою в логах

«10.9.0.23 звертався до 10.20.30.40» — це слабкий рівень. Ви хочете «alice@corp на пристрої X звернулась до finance‑api на порті 443».
Для цього потрібна автентифікація VPN, пов’язана з ідентичністю (SAML/OIDC/RADIUS) та логи, що містять користувача, призначений IP і час сесії.

5) Зробіть накладення та ріст нудними

Розростання VLAN трапляється. Так само й злиття/поглинання. Плануйте адресний простір так, щоб можна було додавати сегменти без перевизначення адрес і уникайте накладення з типовими домашніми мережами.
Якщо ваша офісна LAN — 192.168.0.0/16, ви заслужили той біль, який надалі отримаєте.

Жарт №1: «Поки що просто дозволимо VPN → LAN» — це як «я пожонглую бензопилами, поки аудитор поруч». Працює, поки не зламається.

Маршрутизація + фаєрвол: правила, які справді мають значення

Визначте, де відбувається між‑VLAN маршрутизація

Виберіть одне: ядровий комутатор (SVI) або фаєрвол/маршрутизатор. Якщо ви маршрутизуєте на комутаторі, вам все одно потрібне застосування політик десь.
Найчистіша операційна модель: комутатор робить L2/L3 переадресацію, фаєрвол реалізує політику на межах (через маршрутизовані лінки, ACL або дизайн «firewall‑on‑a‑stick»).

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

Політика входу VPN: трактуйте її як ворожий VLAN

Віддалені пристрої — різні. Навіть корпоративні ноутбуки проводять час у готельному Wi‑Fi, домашніх мережах та кав’ярнях із каптивними порталами, створеними хаосом.
Тому ваш пул VPN варто вважати ближчим до «напівдовіреного», ніж до «корпоративної LAN».

Дозволяйте VPN → DNS (ваші резолвери), NTP і необхідні внутрішні додатки.
За замовчуванням блокувати VPN → мережі управління (комутатор, фаєрвол, управління гіпервізором).
Блокувати VPN → користувацькі VLAN, якщо немає виправданого випадку використання (напр., інструменти підтримки).
Логуйте відмови для раннього попередження. Потім налаштовуйте, щоб зменшити шум.

Реклама маршрутів — це механізм контролю безпеки

Фаєрволи — ваша остання лінія. Маршрутизація — ваша перша лінія. Якщо ви штовхаєте маршрути для кожної підмережі кожному клієнту, ви запрошуєте бічний рух.
У WireGuard, AllowedIPs одночасно «які маршрути клієнт встановлює» і «з яких вихідних підмереж сервер приймає». Це потужно. Використовуйте це.

Будьте цілеспрямовані щодо split tunneling

Split tunnel означає: лише внутрішні підмережі йдуть через VPN; усе інше — напряму. Ризик не в «інтернеті». Ризик — скомпрометований кінцевий пристрій, який може спілкуватися з обома світами.
Ви зменшуєте ризик перевіркою статусу пристрою, endpoint‑безпекою та обмеженням того, до чого VPN може дістатися.

Full tunnel означає, що все йде через ваш офіс. Ризик у тому, що ваш офіс стає вузьким місцем для всіх і ваші логи перетворюються на поле приватності та комплаєнсу.
Обирайте на основі вимог до контролю egress, а не на основі страху.

Одна цитата, бо вона досі актуальна

Надія — це не стратегія. — перефразована думка, яку часто приписують інженерам і операторам у кругах надійності

(Ні, я не ставлю безпеку продакшну на походження слогану. І вам не варто.)

DNS, ідентичність і чому мислення «тільки IP» провалюється

DNS: зробіть його нудним і послідовним

VPN‑користувачам потрібне розв’язання імен, яке відповідає on‑prem реальності, інакше з’являться тіньові hosts‑файли та загадкові IP у закладках.
Використовуйте split DNS: внутрішні домени розв’язуються через внутрішні резолвери; публічні імена — через звичайні резолвери (або ваш контрольований egress при full‑tunnel).

Також: вирішіть, чи можуть VPN‑клієнти розв’язувати внутрішні імена, до яких вони не мають доступу. У суворих середовищах ви можете навмисно це заборонити, щоб зменшити розвідку.

Ідентичність: прив’язуйте доступ до того, хто, а не лише де

VLAN сегментація — це «де». VPN додає «як ви сюди потрапили». Але вам все ще потрібне «хто».
Якщо аутентифікація VPN — просто спільний PSK, у вас закладена бомба. Використовуйте автентифікацію на користувача з MFA, короткострокові сертифікати/ключі та авторизацію за групами.

Наблюваність: логи, що відповідають на питання безпеки

Ви повинні мати змогу відповісти на:

Який користувач мав IP 10.90.0.14 о 14:32?
До яких внутрішніх призначень ця сесія зверталась?
Чи були вони відхилені політикою, і чому?
Чи був цей трафік нормальним для їхньої ролі?

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

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

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

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

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24
vlan20@eth1      UP             10.20.0.1/24
vlan30@eth1      UP             10.30.0.1/24
wg0              UP             10.90.0.1/24

Значення: wg0 — ваш VPN‑інтерфейс; пул VPN‑клієнтів — 10.90.0.0/24.

Рішення: Розглядайте 10.90.0.0/24 як окремий сегмент у політиці фаєрвола. Не об’єднуйте його з «LAN».

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

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.20.0.0/24 dev vlan20 proto kernel scope link src 10.20.0.1
10.30.0.0/24 dev vlan30 proto kernel scope link src 10.30.0.1
10.90.0.0/24 dev wg0 proto kernel scope link src 10.90.0.1

Значення: Шлюз маршрутизує між VLAN20, VLAN30 і підмережею VPN.

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

Завдання 3: Перевірте peers WireGuard і AllowedIPs (обсяг маршрутів)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: Jkq...redacted...
  listening port: 51820

peer: w9h...redacted...
  preshared key: (hidden)
  endpoint: 198.51.100.25:53644
  allowed ips: 10.90.0.23/32, 10.20.10.0/24
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.23 GiB received, 5.44 GiB sent

Значення: Цей користувач може джерелити трафік як 10.90.0.23 і має дозвіл на доступ (і/або маршрутизацію) до 10.20.10.0/24, залежно від топології.

Рішення: Звузьте allowed ips лише до того, що їм потрібно. Уникайте надання peers широких підмереж «зручно».

Завдання 4: Підтвердіть, що IP‑форвардінг увімкнено на шлюзі

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

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

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

Завдання 5: Перегляньте політику фаєрвола за замовчуванням (nftables)

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
    iif "eth0" tcp dport 22 accept
    iif "eth0" udp dport 51820 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "vlan20" tcp dport { 443, 5432 } accept
    iif "wg0" oif "vlan20" udp dport 53 accept
    iif "wg0" oif "vlan30" drop
  }
}

Значення: За замовчуванням — drop. VPN може досягати конкретних TCP‑портів на VLAN20, робити DNS і явно заблокований від VLAN30.

Рішення: Це та форма, яку ви хочете: явні біл‑списки дозволів, явні заборони там, де потрібно, і політика default‑deny, яку можна пояснити.

Завдання 6: Підтвердіть, що VPN випадково не NAT‑ує в «довірену» LAN

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

Значення: НАТ є лише для трафіку в інтернет через eth0. Внутрішній трафік VLAN не маскується.

Рішення: Уникайте NAT між VPN і внутрішніми VLAN, якщо вас не змушує накладення підмереж. NAT ховає ідентичність і ускладнює логування.

Завдання 7: Перевірте, що між‑VLAN доступ справді заблоковано (з VPN‑клієнта)

cr0x@server:~$ nc -vz 10.30.0.10 22
nc: connect to 10.30.0.10 port 22 (tcp) failed: Operation timed out

Значення: З’єднання не вдалося; ймовірно заблоковане політикою фаєрвола (або немає маршруту/хост відключений).

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

Завдання 8: Перевірте, що дозволений доступ до додатку працює (і не ширший, ніж потрібно)

cr0x@server:~$ nc -vz 10.20.0.50 5432
Connection to 10.20.0.50 5432 port [tcp/postgresql] succeeded!

Значення: VPN‑клієнт має доступ до Postgres на погодженому порті.

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

Завдання 9: Перевірте MTU і ризик фрагментації (класичний вбивця продуктивності VPN)

cr0x@server:~$ ping -M do -s 1360 10.90.0.1 -c 3
PING 10.90.0.1 (10.90.0.1) 1360(1388) bytes of data.
1368 bytes from 10.90.0.1: icmp_seq=1 ttl=64 time=22.1 ms
1368 bytes from 10.90.0.1: icmp_seq=2 ttl=64 time=21.7 ms
1368 bytes from 10.90.0.1: icmp_seq=3 ttl=64 time=21.9 ms

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

Значення: DF‑пінг із payload 1360 проходить. Це означає, що ефективний MTU на шляху щонайменше ~1388.

Рішення: Якщо це не проходить — зменшіть MTU інтерфейсу VPN (або виправте PMTUD). Не «оптимізуйте», ігноруючи MTU; це оптимізує вас у потік тікетів.

Завдання 10: Захопіть трафік на VPN‑інтерфейсі, щоб побачити, що реально відбувається

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.90.0.23 and tcp port 5432 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:44:01.121901 IP 10.90.0.23.49212 > 10.20.0.50.5432: Flags [S], seq 381909112, win 64240, options [mss 1360,sackOK,TS val 101 ecr 0,nop,wscale 7], length 0
12:44:01.138221 IP 10.20.0.50.5432 > 10.90.0.23.49212: Flags [S.], seq 21188218, ack 381909113, win 65160, options [mss 1460,sackOK,TS val 55 ecr 101,nop,wscale 7], length 0
12:44:01.138309 IP 10.90.0.23.49212 > 10.20.0.50.5432: Flags [.], ack 1, win 502, options [nop,nop,TS val 102 ecr 55], length 0

Значення: SYN/SYN‑ACK/ACK завершуються. Мережевий шлях працює; якщо додаток досі «падає», ймовірно проблема в автентифікації додатку, DNS або помилка користувача — не маршрутизація.

Рішення: Перестаньте міняти правила фаєрвола. Ескалюйте до власників додатку/сервісу з доказами.

Завдання 11: Підтвердіть шлях розв’язування DNS для внутрішніх імен

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

Link 3 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: corp.example

Значення: DNS для VPN‑інтерфейсу вказує на внутрішній резолвер і встановлено search domain.

Рішення: Якщо VPN‑користувачі не можуть розв’язати *.corp.example, виправте DHCP‑опції для VPN або конфіг клієнта VPN. Не кажіть користувачам «просто використовуй IP». Такі помилки виростають у відмови.

Завдання 12: Перевірте активні з’єднання і чи застрягли вони

cr0x@server:~$ ss -tnp | sed -n '1,12p'
State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process
ESTAB   0       0        10.90.0.1:5432        10.90.0.23:49212   users:(("postgres",pid=2214,fd=7))
SYN-RECV 0      0        10.20.0.50:443        10.90.0.23:51044   users:(("nginx",pid=1893,fd=15))

Значення: Встановлена DB‑сесія здорова. SYN‑RECV вказує на напів‑відкриті TCP‑хендшейки — часто асиметрія фаєрвола, проблеми з маршрутами повернення або MTU.

Рішення: Дослідіть симетрію шляху та відстеження стану фаєрвола; перевірте маршрути повернення з 10.20.0.50 до 10.90.0.0/24.

Завдання 13: Підтвердіть маршрути повернення з внутрішнього серверного VLAN

cr0x@server:~$ ip route get 10.90.0.23 from 10.20.0.50 iif vlan20
10.90.0.23 from 10.20.0.50 iif vlan20
  via 10.20.0.1 dev vlan20 src 10.20.0.50 uid 0
    cache

Значення: Відповіді з VLAN20 підуть через шлюз 10.20.0.1 dev vlan20 src 10.20.0.50, який може маршрутизуватися до wg0.

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

Завдання 14: Перевірте лічильники фаєрвола, щоб дізнатися, що відкидається

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "vlan20" tcp dport { 443, 5432 } accept
    iif "wg0" oif "vlan20" udp dport 53 accept
    iif "wg0" oif "vlan30" drop counter packets 1842 bytes 122004
  }
}

Значення: Трафік від VPN до VLAN30 відкидається, і це не гіпотетично — є лічильники.

Рішення: Вирішіть, чи це очікувано (добре: ви запобігаєте бічному руху), чи вказує на задокументовану залежність (погано: додатку насправді потрібен VLAN30). У будь‑якому разі тепер у вас є доказ.

Завдання 15: Виміряйте CPU шлюзу VPN і криптоботтлнеки

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (vpn-gw)  12/28/2025  _x86_64_  (8 CPU)

01:02:11 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
01:02:12 PM  all  12.5  0.0  38.1   0.0    0.0  31.4    0.0    0.0    0.0   18.0
01:02:12 PM    3  10.0  0.0  44.0   0.0    0.0  42.0    0.0    0.0    0.0    4.0

Значення: Високі %soft і %sys вказують на інтенсивну обробку пакетів; один CPU практично завантажений. Це може обмежувати пропускну здатність.

Рішення: Розгляньте multiqueue/tuning NIC, перенесення термінації VPN на потужніше обладнання або використання реалізації в ядрі. Не списуйте на «ISP», поки не подивитесь сюди.

Завдання 16: Перевірте навантаження conntrack (проблема stateful‑фаєрволів)

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

Значення: Ви близько ~70% від потужності conntrack. Сплески можуть викликати відкидання і дивні стани.

Рішення: Збільшіть розмір conntrack і/або зменшіть непотрібні потоки (особливо при full‑tunnel). Якщо ви робите full‑tunnel для усіх, ви платите за стани.

Плейбук швидкої діагностики

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

Перше: ізолюйте клас відмов

Це доступність? Чи може клієнт пропінгувати IP шлюзу VPN? Чи може він дістатися відомого внутрішнього сервісу за відомим портом?
Це розв’язування імен? Чи внутрішній DNS розв’язується? Чи він повертає правильний IP для сегмента користувача?
Це політика? Чи показують лічильники/логи фаєрвола відмови для цього джерела і призначення?
Це продуктивність? Чи працюють малі пінги, але великі трансфери зупиняються? Думайте MTU, CPU, conntrack і асиметричні маршрути.

Друге: перевірте симетрію маршрутизації

Зі шлюзу: існує маршрут до призначення VLAN.
З призначеної VLAN: маршрут повернення до підмережі VPN існує через той самий шлюз.
На фаєрволах: state‑tracking бачить обидва напрямки на тій самій коробці.

Третє: підтвердіть, які маршрути встановив клієнт VPN

Більшість тікетів «VPN не може дістатися підмережі X» — це «клієнт ніколи не встановив маршрут до X» або «клієнт має більш специфічний маршрут до локальної мережі».
Саме тут кусає RFC1918.

Четверте: тестуйте MTU рано

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

П’яте: подивіться на ємність у точці термінації

Високе CPU softirq, conntrack майже на максимумі, NIC ring drops або однопотоковий user‑space VPN‑процес можуть обмежувати пропускну здатність.
Якщо ви робите full‑tunnel — припускайте, що ви тепер працюєте як ISP. Дійте відповідно.

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

1) «VPN‑користувачі можуть дістатися всього на кожному VLAN»

Симптом: Рев’ю безпеки виявляє, що пул VPN може дістатися принтерів, гіпервізорів і випадкових IP управління.

Корінь: Пул VPN сприйнято як «довірена LAN» і дозволено через правила між‑VLAN маршрутизації.

Виправлення: Помістіть VPN‑користувачів у виділену політичну зону; переключіться на політику forward default‑deny; allowlist лише потрібні порти і призначення.

2) «Деякі внутрішні додатки працюють, інші зависають або повільні»

Симптом: SSH працює, але передача файлів зависає; HTTPS частково завантажується; RDP фризить.

Корінь: Відмова MTU/PMTUD через накладення інкапсуляції і блокування ICMP fragmentation‑needed.

Виправлення: Дозвольте релевантні типи ICMP; зменшіть MTU інтерфейсу VPN; тестуйте DF‑пінгами; уникайте подвійної інкапсуляції де можливо.

3) «Учора працювало; сьогодні тільки один VLAN недоступний з VPN»

Симптом: VPN може дістатися серверного VLAN, але не corp VLAN або навпаки.

Корінь: Змінено шлях повернення (новий core switch маршрут, VRRP переміщення, статичний маршрут видалено). Асиметрична маршрутизація ламає stateful‑фаєрволи.

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

4) «Після активації full‑tunnel інтернет в офісі став жахливим»

Симптом: Усі скаржаться, графіки показують сплески CPU фаєрвола та кількостей сесій.

Корінь: Full‑tunnel перетворив концентратор VPN на шлюз еґрезу без планування ємності; conntrack та NAT таблиці під завантаженням.

Виправлення: Поверніться до split‑tunnel з перевіркою стану пристрою або масштабування концентратору та шляху еґрезу; додайте QoS; контролюйте, що може транзити.

5) «VPN‑клієнти не можуть дістатися внутрішніх підмереж з дому»

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

Корінь: Колізія планування адрес (наприклад, офіс використовує 192.168.1.0/24).

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

6) «DNS розв’язує, але користувачі потрапляють не на ту службу»

Симптом: Ім’я дає IP, який досяжний, але не цільове середовище (prod vs staging, офіс vs cloud).

Корінь: Неправильна конфігурація split DNS; search domains штовхають неочікуване FQDN‑результат; кілька внутрішніх зон з несумісними записами.

Виправлення: Стандартизувати внутрішні DNS‑зони; явно налаштувати DNS для VPN; аудитуйте search domains; логувати DNS‑запити з пулу VPN для раннього виявлення.

7) «Додали статичний маршрут і тепер щось інше зламалося»

Симптом: Після зміни маршрутів з’явилися дивні проблеми доступності між VLAN.

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

Виправлення: Тримайте маршрути простими; документуйте наміри маршрутів; використовуйте фільтри маршрутів; перевіряйте traceroute і лічильники фаєрвола.

Три корпоративні міні‑історії з реального життя

Міні‑історія 1: Інцидент, спричинений неправильною гіпотезою

Середня компанія мала «гарну сегментацію»: окремі VLAN для користувачів, серверів, управління, VoIP і гостьового Wi‑Fi.
Віддалені працівники підключалися через VPN, отримували IP, і «усе просто працювало». Це святкували як успіх.

Неправильна гіпотеза була тонкою: «VPN‑користувачі по суті в user VLAN». Вони не були. Вони були в пулі VPN, який фаєрвол трактував як «LAN», бо хтось колись скопіював набір правил.
Тож VPN‑клієнти могли маршрутизуватися до VLAN управління, який існував переважно для краси діаграми перед аудиторами.

Потім ноутбук підрядника заразився поза офісом. Нічого кінематографічного — просто звичайний інформаційний стібер із вбудованим network discovery.
Коли ноутбук підключився до VPN, він почав сканувати. Інтерфейс управління гіпервізора відповів. Потім комутатор. Потім backup‑пристрій з веб‑UI.

Наслідок не був «миттєвим ransomware‑апокаліпсисом», але й не був добрим: повторне використання облікових даних переросло в несанкціоновані спроби доступу, а шумне сканування викликало IDS‑сигнали, які команда ніколи не тестувала на такому обсязі.
Реагування на інцидент обернулося одним питанням: «Чому VPN‑користувач взагалі може це бачити?»

Виправлення було майже нудним: створити виділену зону VPN, default‑deny forward, allowlist лише потрібних портів додатків і додати явні відмови до управління.
Соромно було те, що в постмортемі написали: сегментація існувала на папері, але VPN її повністю обходив.

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

Інша організація вирішила, що split tunneling «небезпечний», тож перейшла на full‑tunnel віддаленого доступу.
Весь інтернет‑трафік з віддалених ноутбуків йшов через офісний фаєрвол, фільтрувався, логувався і NAT‑ився через одну ISP‑лінію.

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

Фаєрвол не впав. Він просто став найдорожчими годинними пісковими годинниками у світі. CPU підскочив у softirq, conntrack підповз до максимуму, а затримки стали щоденною темою.
Користувачі почали вимикати VPN, щоб працювати, що зруйнувало ту саму контрольну мету, яку хотіла команда безпеки.

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

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

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

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

Одного ранку внутрішній серверний VLAN почав бачити дивні епізоди схід‑захід трафіку. Не величезні, але постійні.
Моніторинг зафіксував нові шаблони підключень з пулу VPN у серверні діапазони, які не входили до жодного затвердженого списку доступів.

On‑call не довелося гадати. Логи фаєрвола зіставили джерело VPN IP з ідентичністю користувача, лічильники відмов показали повторні блокування до підмереж управління, і матриця доступів показала, що для цього користувача немає жодної легітимної причини бути там.
Вони відключили доступ цього користувача до VPN і перевірили кілька облікових даних як пересторог.

Пізніший аналіз вказав на скомпрометований кінцевий пристрій. Важливий момент: сегментація й логування зробили радіус ураження малим і виявлення раннім.
Команді не знадобилися героїчні дії. Потрібні були нудні папірці і політика default‑deny, яку всі закочували очі.

Жарт №2: Матриця доступів була настільки непопулярна, що, можливо, кваліфікується як розподілений denial‑of‑service для терпіння розробників.

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

Крок 1: Намалюйте сегменти, що мають значення (не ті, яких вам хотілося б)

Перерахуйте VLAN і підмережі: користувачі, сервери, управління, принтери, IoT, гості, OT.
Перерахуйте, де завершується VPN: фаєрвол, маршрутизатор, Linux‑шлюз, cloud.
Визначте точки між‑VLAN маршрутизації і де живе застосування політик.

Тиск на рішення: Якщо маршрутизація відбувається в трьох місцях — у вас не сегментація, а пазл.

Крок 2: Оберіть пул адрес для клієнтів VPN так, ніби ви житимете з ним роками

Використовуйте виділений RFC1918 діапазон, що не накладається на типові домашні мережі.
Зробіть його достатньо великим для росту (не вибирайте /24, якщо у вас буде 800 користувачів).
Документуйте його як зону безпеки: «VPN‑Users».

Крок 3: Визначте доступ за ролями і сервісами

Групуйте користувачів за потребами: dev, finance, IT, vendors, support.
Для кожної групи перелічіть призначення (підмережі/хости) і порти.
Віддавайте перевагу сервісним призначенням (VIP, load balancer), а не цілим підмережам.

Крок 4: Впровадьте «least routes» плюс «least firewall rules»

Пуште лише необхідні маршрути кожній групі.
Default‑deny між зоною VPN і внутрішніми зонами.
Allowlist портів з обґрунтуванням і контролем змін.
Явно блокувати мережі управління і чутливі схід‑захід трафіки за замовчуванням.

Крок 5: Зробіть DNS і час адекватними

Налаштуйте DNS‑сервери і внутрішні search domains для VPN навмисно.
Забезпечте доступність NTP; автентифікація і логи залежать від часу.
Вирішіть split DNS vs повну внутрішню рекурсію залежно від політики.

Крок 6: Логування і аудит, що не приведуть до сорому

Логувати події автентифікації VPN з ідентичністю користувача і призначеним IP.
Логувати відмови фаєрвола з зони VPN (принаймні спочатку).
Зберігати дані достатньо довго, щоб відповісти «хто до чого звертався» для потреб комплаєнсу.

Крок 7: Тестуйте як песиміст

Позитивні тести: потрібні додатки доступні з VPN.
Негативні тести: VLAN управління недоступний; користувацький VLAN недоступний (якщо не потрібно).
Тести продуктивності: MTU, пропускна здатність, конкурентність, failover.

Крок 8: Експлуатуйте без паніки при кожній зміні

Помістіть правила фаєрвола і конфігурацію VPN під контроль версій.
Майте план відкату, що не потребує «єдиної людини, яка все знає».
Використовуйте поетапні розгортання політик.

FAQ

1) Чи мають клієнти VPN бути в тій самій VLAN/підмережі, що й офісні користувачі?

Ні. Дайте клієнтам VPN їхню власну маршрутизовану підмережу (або еквівалент зони VLAN) і застосуйте суворішу політику.
Якщо потрібен «той самий досвід», вирішіть це через DNS і дозволи, а не через спільне рівень‑2 суміжності.

2) Чи небезпечний split tunneling?

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

3) Чому не дозволити VPN‑користувачам дістатися цілих серверних VLAN?

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

4) Який найчистіший спосіб блокувати VPN‑доступ до мереж управління?

Помістіть управління в виділені підмережі/VLAN і додайте явні відмови від зони VPN до цих підмереж.
Також не рекламуйте маршрути до цих підмереж VPN‑клієнтам, якщо профіль адміністратора їх не потребує.

5) Чи забезпечують VLAN самі по собі безпеку сегментації?

VLAN дають розділення на рівні 2. Без контрольованої маршрутизації і політик фаєрвола вони не є межами безпеки.
Припускайте, що будь‑яка маршрутизована суміжність без політики — це «можливий шлях порушення».

6) Як вирішувати накладення IP‑простору між віддаленими користувачами та офісними VLAN?

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

7) Чому я бачу стани SYN‑RECV, коли VPN‑користувачі підключаються до внутрішніх сервісів?

Часто це асиметрична маршрутизація: сервер відповідає через інший шлюз, ніж той, що бачив SYN. Stateful‑фаєрволи тоді відкидають повернений трафік.
Виправте маршрут повернення через VPN‑шлюз/фаєрвол або переконайтесь, що фаєрвол бачить обидва напрямки.

8) Де краще маршрутизувати між VLAN — на core‑комутаторі чи на фаєрволі?

Для чистої продуктивності комутатори чудові. Для безпеки з аудит‑слідами — фаєрволи кращі.
Багато середовищ роблять обидва: комутація для базового forwarding, фаєрвол як точка примусу з явними політиками зон.

9) Як довести, що сегментація працює?

Проведіть негативні тести з VPN‑клієнтів (спробуйте доступ до управлінської підмережі, проскануйте відомі заблоковані порти), перевірте лічильники/логи фаєрвола на відмови і задокументуйте очікувані блокування.
Сегментація, яку не можна протестувати, — це просто архітектурна казка перед сном.

Висновок: наступні кроки, що не плавлять вашу мережу

Офісний VPN разом із сегментацією VLAN непрості не через технологію. Вони складні, бо «зробіть, щоб працювало» легко, а «зробіть безпечним, обмеженим і підтримуваним» — дисципліна.
Добра новина: дисципліна — це переважно обсяг маршрутів, політика default‑deny і логи, якими можна користуватися.

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

Створіть виділену підмережу/зону VPN‑користувачів і припиніть трактувати її як «LAN».
Проведіть інвентаризацію внутрішніх сервісів, які дійсно потрібні віддаленим користувачам (призначення + порти), і впровадьте allowlist‑и.
Видаліть широкі пуші маршрутів; рекламируйте лише потрібні підмережі для кожної групи.
Запустіть плейбук швидкої діагностики на одному «відомо нестабільному» додатку і виправте MTU/маршрути повернення до того, як це стане культурою.
Увімкніть логування, що зв’язує VPN‑IP з ідентичностями, і зберігайте його достатньо довго, щоб відповісти на незручні питання.

Вам не потрібна пласка мережа для продуктивності. Потрібна мережа, де доступ — навмисний, а режими відмови — передбачувані, а не загадкові.