Груповий доступ через одну VPN: бухгалтерія, склад, ІТ — різні права

Модель: одна VPN, багато прав

«Одна VPN» не означає «один рівень довіри». Це означає одну точку входу та одну операційну поверхню: один досвід клієнтського профілю,
один робочий процес підтримки, одне місце для ротації ключів та сертифікатів. Права обчислюються після автентифікації і реалізуються по шляху
до призначення. Уявіть це як аеропорт: усі заходять у будівлю, але не всі потрапляють у кабіну пілота.

Для бухгалтерії «права» зазвичай означають доступ до ERP, фінансових шарів і, можливо, jump host для доступу до термінального сервера. Для складу
це зазвичай WMS, додатки на сканерах штрих-коду, принтери, можливо обмежений файловий drop. Для ІТ — адміністративні мережі, інтерфейси управління,
резервні копії, гіпервізори та повноваження «зламати скло», коли все горить.

Надійний груповий доступ досягається комбінацією чотирьох примітивів:

• Сильна ідентичність: хто цей користувач/пристрій і наскільки ми в цьому впевнені?
• Членство в групі: які ролі в нього є зараз?
• Політика: що ця роль може досягати (мережі, порти, додатки, шари).
• Примус виконання: де ця політика фактично застосовується (фаєрвол, маршрутизація, ACL на сховищах, автентифікація додатків).

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

Парафразована ідея (приписано): Системи, що повинні бути надійними, повинні припускати, що щось ламається, і проектуватися для цієї реальності — John Allspaw.
VPN і його політики не виняток.

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

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

• VPN починали як «безпечні труби», а не як системи ідентичності. Ранні підходи IPsec були орієнтовані на тунель; авторизація часто була вторинною задачею.
• Split tunneling викликає суперечки відтоді, як став поширеним. Це компроміс безпеки: менше бекаулу, більше ризику, якщо кінцеві точки «брудні».
• RADIUS передує більшості сучасних UI VPN-процесів. Авторизація за групами через RADIUS-атрибути існує десятиліттями.
• Сповзання груп у Active Directory — передбачувана причина зламу. «Тимчасові» групи доступу мають звичку ставати постійними сусідами.
• Колись сегментація мереж була здебільшого фізичною. VLAN і VRF зробили її логічною; сучасна політика VPN робить її керованою за ідентичністю.
• Дозволи SMB і POSIX еволюціонували окремо. Коли ви змішуєте Samba + Linux ACL + групи Windows, непорозуміння гарантовані.
• «Zero Trust» — нова етикетка для старих принципів. Мінімальні привілеї, сильна автентифікація та логування не винайдені в 2019 році; їм просто дали кращий маркетинг.
• WireGuard молодий, але принциповий. Він навмисно уникає вбудованої автентифікації користувачів; очікується інтеграція ідентичності зовні.
• Аудиторські вимоги тихо формують архітектуру. Якщо ви не можете відповісти «хто отримував доступ до чого», вашу архітектуру перепишуть вимоги відповідності.

Референсна архітектура, що витримує навантаження

Виберіть контрольну площину й дотримуйтеся її

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

Оберіть одне джерело істини для ідентичності:

• Active Directory (AD), якщо ви вже Windows-організація.
• LDAP/FreeIPA, якщо хочете сильну Linux-нативну ідентичність.
• Провайдер ідентичності + SSO, якщо модернізуєтеся, але будьте реалістичні щодо операційної складності.

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

Чистий дизайн використовує кілька точок примусу, кожна робить те, у чому вона сильна:

• VPN-шлюз: автентифікація, призначення IP, передача маршрутів/DNS, груба політика по групах.
• Фаєрвол/шлюз сегмента: мінімально необхідний мережевий доступ (порти, призначення) з аудитовими логами.
• Контролі додатків: ERP/WMS/SSH мають власну автентифікацію; користуйтеся нею.
• Контролі сховища: Samba/NTFS ACL, NFSv4 ACL, S3/IAM, делегування наборів ZFS — застосовуйте те, що підходить, але примушуйте виконання.

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

Конкретне виробниче розміщення

Ось макет, який масштабується і не перетворюється на будинок з привидами:

• Одна точка входу VPN: vpn-gw01 (і vpn-gw02 для HA, якщо ви цінуєте вихідні).
• Окремі внутрішні сегменти за межами фаєрвол/VRF:
  • FIN-NET (додатки бухгалтерії, фінансові файлові шари)
  • WMS-NET (сервери додатку складу, принтери)
  • MGMT-NET (гіпервізори, iDRAC/iLO, сервери резервного копіювання)
  • USER-NET (загальні корпоративні послуги)
• Пули адрес VPN по групах (або по ролях), наприклад:
  • 10.66.10.0/24 для бухгалтерії
  • 10.66.20.0/24 для складу
  • 10.66.30.0/24 для ІТ
• Правила фаєрволу, що прив’язані до джерела VPN-пулу плюс логи ідентичності з автентифікації VPN.
• DNS на групи: користувачі фінансів не повинні резолвити імена управлінських хостів — не тому, що DNS є «безпекою», а тому, що це гігієна і зменшення помилок.

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

Ідентичність і відображення груп: звідки починається контроль доступу

Користувачі проти пристроїв: вирішіть, що ви авторизуєте

Середовище складу часто має спільні пристрої, кіоски або вбудовані сканери.
Бухгалтерія схильна мати іменованих користувачів із більш високою чутливістю. ІТ часто має іменованих користувачів і привілейовані пристрої.

Визначте явно:

• VPN на основі користувача: користувач автентифікується з MFA; членство в групі визначається групами каталогу.
• VPN на основі пристрою: сертифікат пристрою або pre-shared key; група визначається ідентичністю пристрою.
• Гібрид: пристрій має бути зареєстрований плюс користувач має автентифікуватися (найкраще для доступу адміністраторів ІТ).

Якщо ви не можете чітко сказати, чи ваші складські сканери — «користувачі» чи «пристрої», ви збираєтеся побудувати неправильну політику.

Відображення груп: робіть це нудно

Використовуйте невелику кількість «груп доступу», які відповідають наборам мережевих політик, а не організаційним діаграмам.
Організаційні групи змінюються через реорганізації й політику. Групи доступу повинні змінюватися відповідно до потреб додатків.

Практичний шаблон:

• VPN-Accounting → FIN apps + finance shares
• VPN-Warehouse → WMS app + printers
• VPN-IT → mgmt networks + jump hosts + SSH/RDP to servers
• VPN-AllUsers → мінімальна базова набір (DNS, NTP, управління кінцевими точками)

MFA: робіть це, але без показухи

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

Шари примусу виконання: маршрутизація, фаєрвол і сховища

Маршрутизація: контролюйте радіус ураження за допомогою пулів адрес і передачі маршрутів

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

Передача маршрутів має бути мінімальною:

• Клієнти бухгалтерії отримують маршрути тільки до FIN-NET і загальних корпоративних сервісів, які їм справді потрібні.
• Клієнти складу отримують маршрути тільки до WMS-NET і підмереж принтерів.
• Клієнти ІТ можуть отримувати ширші маршрути, але краще використовувати jump hosts для адміністративних інтерфейсів.

Якщо вас тягне «просто запхати 0.0.0.0/0 усім», щоб було зручніше: це не простота, це борг.

Фаєрвол: дорослий в кімнаті

Політика фаєрволу має бути явною, з логами та керуванням змін.
Віддавайте перевагу allow-list по групах. За замовчуванням deny. Логуйте відмови для налагодження (але обмежуйте швидкість, щоб не DDoS-ити власний SIEM).

Структура правил, що працює:

• Джерело: VPN-пул (10.66.10.0/24)
• Призначення: підмережа додатку або група хостів
• Сервіс: TCP/443, TCP/445, UDP/161 тощо
• Дія: allow + log (принаймні для адміністративних мереж)

Дозволи сховища: де «мережевого доступу» замало

Фінансові дані не захищені тим, що вони в FIN-NET. Вони захищені файловим сервером, який застосовує дозволи.
Якщо користувач зі складу може змонтувати SMB-шару й переглядати бухгалтерські папки, ваша мережева сегментація декоративна.

Робіть це правильно:

• Samba/SMB: використовуйте AD-підтримувані ACL; чітко мапіть групи; уникайте локальних користувачів на NAS для корпоративних шарів.
• NFSv4: надавайте перевагу NFSv4 ACL з ідентичністю на рівні директорій; не покладайтеся на вгадування UID.
• ZFS datasets: окремі датасети за класом чутливості; snapshots; делегування для операцій ІТ без доступу до даних, коли це можливо.

Жарт №2: Якщо ваша «політика доступу» — це електронна таблиця і надія, вітаємо — ви винайшли Compliance Theater: Мюзикл.

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

Це ті завдання, які ви реально виконуєте, коли будуєте або налагоджуєте груповий доступ через одну VPN.
Кожне завдання містить: команду, що типовий вивід означає, і рішення, яке ви приймаєте.
Імена хостів і шляхи реалістичні; відкоригуйте їх під своє середовище.

1) Підтвердити, що інтерфейс VPN увімкнений і має правильний пул адрес

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.0.1/16

Значення: Інтерфейс шлюзу існує і має очікуваний супервнет. Якщо ви планували окремі /24 пули,
шлюз все одно може використовувати більший префікс; це прийнятно, якщо правила фаєрволу орієнтуються на IP клієнта.

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

2) Перевірити активних пірів VPN і їх призначені адреси

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

peer: Zq1a...redacted
  endpoint: 198.51.100.24:53321
  allowed ips: 10.66.10.23/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 102.45 MiB received, 88.22 MiB sent

Значення: Цей пір використовує 10.66.10.23, що має відповідати групі (тут: пул бухгалтерії).
Недавнє рукостискання підтверджує, що тунель живий.

Рішення: Якщо користувач складу з’явився в діапазоні бухгалтерії, логіка призначення ідентичності→IP зламана.
Виправте це перед тим, як ковиряти правила фаєрволу; інакше ви «виправите» проблему, відкривши дірки.

3) Перевірити маршрутизацію до захищеної підмережі з VPN-шлюзу

cr0x@server:~$ ip route get 10.20.10.50
10.20.10.50 via 10.0.0.1 dev eth0 src 10.0.0.10 uid 1000

Значення: Шлюз знає, як дістатися до FIN-NET (приклад хоста 10.20.10.50). Якщо це невірно, клієнти можуть автентифікуватися, але нічого не дістануться.

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

4) Підтвердити пересилання IP на шлюзі (класичне «підключається, але нічого не працює»)

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

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

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

5) Переглянути правила nftables, що фільтрують VPN-пули

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ip saddr 10.66.10.0/24 ip daddr 10.20.10.0/24 tcp dport { 443, 445 } accept
    ip saddr 10.66.20.0/24 ip daddr 10.30.20.0/24 tcp dport 443 accept
    ip saddr 10.66.30.0/24 ip daddr 10.40.0.0/16 accept
    counter drop
  }
}

Значення: За замовчуванням drop. Потім явні дозволи по VPN-пулах. Ось як у реальному житті виглядають «різні права».

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

6) Перевірити, що фаєрвол логує відмову, яка вас цікавить

cr0x@server:~$ sudo journalctl -k -n 20 | grep -E "DROP|DENY" | tail
Dec 28 11:04:02 vpn-gw01 kernel: IN=wg0 OUT=eth0 SRC=10.66.20.44 DST=10.20.10.50 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=39321 DF PROTO=TCP SPT=51522 DPT=445 WINDOW=64240 SYN

Значення: Клієнт зі складу намагався звернутися до SMB на фінансовому сервері, і це було заблоковано. Добре. Це політика, що виконує свою роботу.

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

7) Підтвердити, який IP має користувач (на стороні клієнта)

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.20.44/32

Значення: Клієнт у пулі складу. Це ваш перший санітарний чек, коли хтось каже «я в бухгалтерії, але не можу дістатися фінансів».

Рішення: Якщо IP не відповідає очікуваному пулу, виправте відображення груп або призначення профілю, а не фаєрвол.

8) Протестувати досяжність дозволеного сервісу (TCP/443) і інтерпретувати режими відмови

cr0x@server:~$ nc -vz -w 2 10.30.20.10 443
Connection to 10.30.20.10 443 port [tcp/https] succeeded!

Значення: Мережевий шлях і дозвіл фаєрволу для цього сервісу добрі.

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

9) Трасування шляху, коли маршрутизація дивна (особливо з багатьма внутрішніми стрибками)

cr0x@server:~$ traceroute -n 10.20.10.50
traceroute to 10.20.10.50 (10.20.10.50), 30 hops max, 60 byte packets
 1  10.66.0.1  9.214 ms  9.012 ms  9.118 ms
 2  10.0.0.1   10.202 ms  10.144 ms  10.165 ms
 3  10.20.10.50  11.011 ms  10.989 ms  10.972 ms

Значення: Ви бачите VPN-шлюз, потім внутрішній фаєрвол/роутер, потім призначення. Це щасливий шлях.

Рішення: Якщо він обривається на хопі 1 — проблема з локальним клієнтом/VPN. Якщо на хопі 2 — внутрішня маршрутизація/фаєрвол.

10) Перевірити поведінку DNS по групах (бо «не можу дістатися ERP» часто = «неправильне резолвінг імен»)

cr0x@server:~$ resolvectl status wg0
Link 12 (wg0)
      Current Scopes: DNS
DefaultRoute setting: no
       LLMNR setting: no
MulticastDNS setting: no
  DNS Servers: 10.20.10.53
   DNS Domain: corp.example

Значення: DNS для VPN-інтерфейсу вказує на фінансовий DNS-сервер (приклад). Якщо користувачі зі складу не повинні використовувати цей DNS,
їм не слід його отримувати.

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

11) Підтвердити членство в AD-групі для користувача (вхідні дані авторизації)

cr0x@server:~$ id jsmith
uid=11820(jsmith) gid=10513(domain users) groups=10513(domain users),12900(VPN-Warehouse),12910(WMS-Users)

Значення: Цей користувач в VPN-Warehouse і має отримати політику доступу для складу.

Рішення: Якщо користувача немає в очікуваній VPN-групі, виправте членство в каталозі і повторно автентифікуйтеся; не додавайте винятки у фаєрволі.

12) Переглянути ACL шари Samba (примус виконання на сховищі)

cr0x@server:~$ getfacl /srv/samba/finance
# file: srv/samba/finance
# owner: root
# group: "CORP\\Finance Admins"
user::rwx
group::rwx
group:"CORP\\Accounting":rwx
group:"CORP\\Warehouse":---
mask::rwx
other::---

Значення: Складу заборонено; бухгалтерія має доступ. Ось як виглядають «різні права» там, де зберігаються дані.

Рішення: Якщо склад все ж читає фінанси, ймовірно існує інший шлях до шари, успадковані ACL або неправильна конфігурація SMB-guest mapping.

13) Підтвердити, що SMB бачить правильне відображення ідентичності (класичне «дозволи виглядають правильно, але доступ все ще невірний»)

cr0x@server:~$ wbinfo -i jsmith
jsmith:*:11820:10513:John Smith:/home/CORP/jsmith:/bin/bash

Значення: Winbind може мапити AD-користувача в Unix-ідентичність. Якщо це не працює, ACL, що посилаються на AD-групи, не будуть працювати.

Рішення: Виправте інтеграцію каталогу (Kerberos, winbind, SSSD) перед тим, як чіпати ACL.

14) Доведіть, яка сторона відкидає пакети за допомогою tcpdump (використовуйте помірковано, але використовуйте)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.66.10.23 and host 10.20.10.50 and tcp port 445 -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
11:06:41.112233 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 12345 ecr 0,nop,wscale 7], length 0
11:06:42.114512 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 13345 ecr 0,nop,wscale 7], length 0

Значення: SYN-и прибувають на VPN-інтерфейс; якщо немає SYN-ACK у відповідь, відмова знаходиться далі по ланцюжку (фаєрвол, маршрутизація, хостовий фаєрвол, сервіс).

Рішення: Якщо ви бачите трафік на wg0, але не на eth0 — фаєрвол шлюзу відкидає. Якщо бачите і на eth0 — відмова далі за ним.

15) Перевірити conntrack на наявність стану (особливо при асиметричній маршрутизації)

cr0x@server:~$ sudo conntrack -L | grep 10.66.10.23 | head
tcp      6 117 SYN_SENT src=10.66.10.23 dst=10.20.10.50 sport=51422 dport=445 src=10.20.10.50 dst=10.66.10.23 sport=445 dport=51422 [UNREPLIED] mark=0 use=1

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

Рішення: Перегляньте внутрішні політики фаєрволу, маршрути повернення та хостовий фаєрвол на 10.20.10.50.

16) Підтвердити маршрути повернення на внутрішньому сервері (класика «працює з LAN, не працює з VPN»)

cr0x@server:~$ ip route
default via 10.20.10.1 dev eth0
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.50

Значення: Шлюз сервера за замовчуванням — 10.20.10.1. Якщо клієнти VPN приходять із 10.66.0.0/16, а 10.20.10.1 не знає, як повертати,
відповіді можуть загубитися.

Рішення: Переконайтеся, що внутрішній шлюз знає маршрути до VPN-пулів (або SNAT на VPN-шлюзі — останній засіб, але іноді операційно розумний).

План швидкої діагностики

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

Перше: ідентифікуйте обсяг і класифікуйте відмову

• Один користувач проти одна група проти усі.
• Помилка автентифікації проти підключений, але не дістатися проти доступ є, але немає привілеїв.
• Один додаток проти всі внутрішні призначення.

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

Друге: перевірте тунель і призначений IP

• На шлюзі: wg show / статусний файл OpenVPN / статус IPsec SA.
• На клієнті: IP інтерфейсу і налаштування DNS.

Неправильний діапазон IP = неправі права. Це не «мережева бага», це баг авторизації.

Третє: протестуйте один дозволений потік наскрізь

• Виберіть відоме робоче призначення для цієї групи (наприклад, склад → WMS HTTPS).
• Тестуйте за допомогою nc або curl, а не «відкрий браузер і відчуй».
• Дивіться логи відмов фаєрволу під час тесту.

Четверте: локалізуйте відмову

• Шлюз бачить пакет на VPN-інтерфейсі?
• Шлюз пересилає пакет на LAN-інтерфейс?
• Внутрішній фаєрвол бачить і дозволяє?
• Призначений хост відповідає?

П’яте: лише тоді зачіпайте дозволи сховища

Якщо мережа не може дістатися до файлового сервера, дозволи не мають значення.
Якщо мережа дісталася до серверу, але доступ відмовлено — тоді ви в зоні ACL (логи Samba, effective permissions, відображення груп).

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

1) «Склад бачить фінансові шари»

Симптоми: Користувач зі складу може переглядати або читати фінансові SMB-шари після підключення VPN.

Корінна причина: Мережева сегментація існує, але шлях до фінансової шари доступний з загальної VLAN файлового сервера; успадкування ACL або дозволи «Everyone»/«Domain Users» просочилися.

Виправлення: Помістіть фінансові шари на виділений датасет/шару з явною відмовою/відсутністю для групи складу; перевірте за допомогою getfacl і перевірок ефективного доступу SMB; обмежте мережеві шляхи так, щоб лише пул бухгалтерії мав доступ до TCP/445 на фінансових файлових серверах.

2) «Бухгалтерія не може дістатися ERP, але ping працює»

Симптоми: ICMP проходить; з’єднання з додатком не вдається або таймаутиться.

Корінна причина: Фаєрвол дозволяє ICMP (або його не фільтрують), але блокує TCP/443 або порт додатку; іноді проблеми з MTU приводять до зависання TLS.

Виправлення: Тестуйте за допомогою nc -vz до точного порту; перегляньте правила фаєрволу для пулу бухгалтерії; якщо TLS зависає, протестуйте MTU (ping -M do -s) і налагодьте MSS на шлюзі.

3) «ІТ дістається до серверів, але SSH випадково зависає»

Симптоми: TCP підключається, але сесії періодично заморожуються, особливо через мобільні мережі.

Корінна причина: PMTUD блокується, що спричиняє проблеми з фрагментацією; або тиск на таблицю conntrack під навантаженням.

Виправлення: Увімкніть MSS-clamping на шлюзі; перевірте використання conntrack і збільшіть ліміти, якщо це обґрунтовано; переконайтеся, що ICMP «fragmentation needed» не блокується внутрішньо.

4) «Користувача перевели в бухгалтерію, але він усе ще має доступ складу»

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

Корінна причина: Членство в групі кешується шаром автентифікації VPN (RADIUS/LDAP) або довготривалі VPN-сесії не примушуються до повторної автентифікації.

Виправлення: Зменшіть TTL кешу автентифікації, примусьте повторну автентифікацію при зміні груп, встановіть тривалість сесій; в операційному плані: мати runbook «права змінено → відключити сесію».

5) «Усім надаються повні маршрути незважаючи на налаштування по групах»

Симптоми: Клієнти складу бачать внутрішні маршрути, яких не повинні бачити; traceroute веде туди, куди не треба.

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

Виправлення: Зробіть push маршрутів по групах явним і тестуйте з чистим профілем клієнта; ставте конфігурації клієнтів під код-рев’ю і поступове розгортання.

6) «VPN підключено, але DNS резолвить внутрішні імена у публічні IP»

Симптоми: Користувачі потрапляють на неправильні кінцеві точки; SSO петлі; помилки додатків, які виглядають як проблеми автентифікації.

Корінна причина: Split DNS не налаштовано; клієнт все ще використовує домашні/публічні резолвери; домени пошуку не встановлені.

Виправлення: Надсилайте правильні DNS-сервери й домени для групи; перевіряйте через resolvectl; уникайте покладання на ручні налаштування DNS на кінцевих пристроях.

7) «Доступ працює деякий час, потім ламається після змін у мережі»

Симптоми: Після додавання підмережі або переміщення додатку одна група втрачає доступ, інші — ні.

Корінна причина: Об’єкти/групи фаєрволу не оновлено; маршрут не анонсується; дрейф політик між середовищами.

Виправлення: Тримайте єдине джерело істини для підмереж і політик; додайте хуки змін: коли додається підмережа, оновлюйте push-маршрути і правила фаєрволу разом, а потім валідовуйте підключення.

8) «Фінансист не може відкрити таблиці на SMB, але може перелічити теки»

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

Корінна причина: Права на рівні шару ОК, але NTFS/Samba ACL на файлах неправильні; або невідповідність вимог підписування/шифрування SMB; іноді opportunistic locking впливає на старі клієнти.

Виправлення: Перевірте ACL файлів та успадкування, не лише верхню папку; перевірте конфіг Samba; протестуйте відомим робочим Windows-клієнтом; тримайте політики безпеки SMB узгодженими.

Три міні-історії з корпоративного життя

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

Середня компанія консолідувала віддалений доступ в одну VPN «щоб спростити підтримку». Мета зрозуміла.
Мережна команда розділила пули VPN для бухгалтерії і складу і вважала справу зробленою. Так — на папері.
Потім супервайзер складу відкрив тикет: «Я бачу фінансові папки. Це нормально?»

Припущення полягало в тому, що якщо склад не може маршрутизуватися в FIN-NET, то він не зможе отримати фінансові дані.
На жаль, фінансові шари не були в FIN-NET. Вони жили на загальному файловому сервері, доступному з USER-NET,
бо «це просто файли», і сервер існував довше за проект сегментації.
Мережева сегментація і розміщення даних віддалилися одне від одного за роки, як колеги після реорганізації.

Негайне виправлення було негарним, але ефективним: правило фаєрволу, що блокує TCP/445 з пулу складу до файлового сервера.
Це зупинило течію, але також зламало законні файлові «киди» зі складу, бо вони були на тому самому сервері.
Реальне виправлення зайняло тиждень: створити окремі Samba-шари на окремих ZFS-датасетах, перемістити фінансові дані на фінансовий датасет
і застосувати AD-групові ACL. Шара для складу залишилася доступною, фінансова — ні.

Урок не в тому, що сегментація мереж погана. Урок в тому, що сегментація без примусу на сховищі — це рекомендація,
і зловмисники люблять рекомендації.

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

В іншому місці була «розумна» ідея: зменшити завантаження CPU VPN-сервера і спростити маршрутизацію шляхом SNAT усіх VPN-пакетів на один IP шлюзу.
Аргумент був у продуктивності і простоті: менше маршрутів в інфраструктурі, менше стану в фаєрволах.
Це навіть працювало — в тому сенсі, як свіжа фарба «працює», приховуючи тріщину.

Потім настала аудиторська перевірка. Команда безпеки задала просте питання: «Які користувачі заходили в підмережу фінансового додатку у вівторок?»
З SNAT внутрішні логи показували лише IP шлюзу. Логи VPN мали ідентичності користувачів, звісно, але кореляція по потоках вимагала зшивання
за часом сесій і вгадувань, який трафік кому належав. Це було можливо, але не захищалося в аудиті.

Операційно SNAT також ускладнило налагодження. Коли WMS повільно працював, команди ледь розуміли, хто винен:
VPN-команда звинувачувала додаток; додаткова команда VPN — додаток. Фаєрвол бачив один вихідний IP для всіх, тому неможливо було ізолювати шумні клієнти чи бачити поведінку по групах.
Система втратила спостережливість, і кожен інцидент тривав довше, бо правду треба було реконструювати.

Зрештою вони відкотили SNAT і додали правильні маршрути повернення із внутрішніх мереж до VPN-пулів.
CPU трохи піднявся; прозорість піднялася значно. Це зазвичай вигідний обмін.

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

Компанія зі строгим розділенням бухгалтерії і складу мала практику, яка здавалась нудною: квартальні «перевірки реальності доступу».
Не раз у рік «для галочки». Квартально. Набір скриптованих тестів запускалися з трьох тестових акаунтів — по одному на групу — і перевіряли доступність:
чи може бухгалтерія дістатися ERP? чи може склад дістатися WMS? чи може ІТ дістатися jump hosts? чи не може склад дістатися фінансового SMB?

Одної п’ятниці внутрішнє оновлення мережі перемістило WMS-сервери в нову підмережу. Вікно змін закінчилося, усі пішли додому,
і дежурний інженер очікував тиші. Квартальні скрипти, що запускалися як частина післязмінної валідації, одразу впали:
клієнти VPN складу більше не могли дістатися WMS. Бухгалтерія та ІТ були в порядку.

Корінна причина була простою: правила фаєрволу були написані з явними старими підмережами, і нову підмережу не додали.
Оскільки валідація була автоматизована і групово-орієнтована, збій виявили до того, як нічна зміна почала обслуговувати піддони.
Виправлення — невелике оновлення політики і повторний запуск тестів.

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

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

План поетапно для впровадження групових прав через одну VPN

1. Визначте ролі як політики доступу, а не як оргодиниці.
   Створіть 3–6 груп доступу VPN, які мапляться на доступні сервіси.
   Уникайте, щоб «VPN-Employees» перетворився на «VPN-Усі-і-їхні-підрядники».
2. Створіть окремі IP-пули VPN для кожної групи доступу.
   Це стане вашим ключем у фаєрволі і ручкою аудиту.
3. Виберіть межу примусу виконання.
   Краще: застосовуйте на фаєрволі між VPN і внутрішніми сегментами. Достатньо: на VPN-шлюзі з nftables/iptables. Найгірше: «ми зробимо це в додатках».
4. Надсилайте мінімальні маршрути й DNS по групах.
   Якщо бухгалтерія ніколи не потребує WMS, не рекламуте його. Менше маршрутів = менше сюрпризів.
5. Реалізуйте forwarding за замовчуванням deny.
   Потім дозвольте явні потоки (джерело пул → підмережа/хости → порти).
6. Логуйте відмови (з розумними лімітами) і логуйте адмін-дозволи.
   Потрібно достатньо доказів для налагодження й аудиту, але не так багато, щоб плавився диск.
7. Примушуйте доступ на сховищі, а не тільки в мережі.
   Окремі датасети/шари; застосуйте AD-групові ACL; тестуйте з реальними токенами користувачів.
8. Додайте jump host для адміністративного доступу ІТ.
   Тримайте інтерфейси управління недоступними напряму з випадкового готельного Wi‑Fi.
9. Визначте тривалість сесії та поведінку при повторній автентифікації.
   Якщо членство в групі змінюється, сесії мають оновитися у передбачуваний проміжок часу.
10. Напишіть тести валідації по групах і запускайте їх після змін.
    Тести доступності дешеві. Аварії — ні.
11. Документуйте «чому» поруч із «що».
    Коментарі до правил мають пояснювати, яку бізнес-можливість вони надають. Інакше правила розмножуються як кролі.
12. Проводьте квартальний перегляд доступу з технічною валідацією.
    «Переглянути список груп» — не перевірка. Перевірка — це пакети, логи й перевірки ACL.

Операційний чеклист для вікон змін

• Перед зміною: зробіть знімок/експорт конфігів VPN і фаєрволу; підтвердьте, що шлях відкату працює.
• Під час зміни: оновлюйте маршрути, об’єкти фаєрволу і DNS разом для вплинутих додатків.
• Після зміни: проганяйте тесті доступності по групах; підтвердіть, що відмови все ще відхиляються.
• Після зміни: перевірте логи на несподівані відмови/дозволи з VPN-пулів.

Чеклист безпеки, що не саботує операції

• MFA для VPN на основі користувача (особливо для бухгалтерії й ІТ).
• Ніяких спільних IT-адмінських акаунтів; окремі іменовані акаунти для привілейованого доступу.
• Документований і протестований break-glass доступ (так, протестований).
• Ротація ключів/сертифікатів; протерміновані профілі; негайне відкликання при офбордингу.
• Обмежуйте латеральний рух: клієнти VPN не повинні мати доступ один до одного, якщо це не потрібно явно.

Питання й відповіді (FAQ)

1) Чи можна це зробити на одному VPN-сервері, чи потрібні окремі сервери на відділ?

Один сервер підходить, якщо він може призначати різні IP/маршрути залежно від ідентичності і ви застосовуєте політику на фаєрволі.
Окремі сервери іноді використовують для політичного комфорту; технічно вони часто непотрібна складність.

2) Де краще застосовувати політику — на VPN-шлюзі чи на внутрішньому фаєрволі?

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

3) Чи потрібні окремі підмережі (пули VPN) для груп?

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

4) А підрядники, яким потрібен бухгалтерський доступ на місяць?

Помістіть їх у часово-обмежену групу доступу з явним робочим процесом експірації.
Не додавайте їх у основну бухгалтерську групу «тимчасово». «Тимчасово» — це як створити постійний ризик.

5) Чи повинні сканери складу використовувати той самий метод VPN, що й ноутбуки?

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

6) Чи прийнятний split tunneling в цій моделі?

Іноді. Якщо кінцеві точки керовані і ви мінімізуєте бекаул, split tunnel може бути розумним.
Для адміністраторського доступу ІТ і фінансових операцій повний тунель часто безпечніший, бо ви контролюєте DNS і вихідну інспекцію.

7) Чому не можна покладатися лише на логіни в додатках (ERP/WMS) і пропустити мережеві обмеження?

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

8) Як довести аудиторам, що склад не може дістатися фінансових даних?

Надайте багатошарові докази: політику фаєрволу з відмовами (і логи спроб доступу з тестових акаунтів),
плюс докази ACL на сховищі, що показують відмову для груп складу. Бонус — повторювані тестові скрипти.

9) Як найчистіше обробити широкі потреби ІТ, не даючи їм «усю мережу»?

Використовуйте jump hosts і робочі процеси привілейованого доступу. ІТ може дістатися до jump host; jump host має доступ до мереж управління.
Ви логируєте. Ви контролюєте. Ви можете відкликати доступ без переписування кожного правила фаєрволу.

10) Як уникнути дрейфу політик з часом?

Трактуйте політику VPN і фаєрволу як код: рев’ю, поетапні зміни і автоматизовані тести по групах.
Дрейф виникає, коли ви сприймаєте мережеву політику як дошку для маркерів.

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

Груповий доступ через одну VPN — це не функція продукту. Це дисципліна проєктування.
Переможний підхід нудний: ідентичність → відображення груп → окремі IP-пули → явна політика фаєрволу → примус ACL на сховищах → логи, якими можна скористатися.
Будь-що інше — театр.

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

1. Створіть (або очистіть) три групи доступу: VPN-Accounting, VPN-Warehouse, VPN-IT. Зробіть правила членства явними.
2. Призначте три VPN-пули адрес і забезпечте, щоб клієнти потрапляли в правильний пул щоразу.
3. Впровадьте forwarding за замовчуванням deny і напишіть дозволи по пулах лише до потрібних підмереж/портів.
4. Перемістіть фінансові дані в окремий шар/датасет і застосуйте ACL через групи каталогу.
5. Побудуйте маленький набір валідації: один тестовий акаунт на групу, п’ять перевірок доступності і один негативний тест (склад → фінанси SMB має відмовити).
6. Операціоналізуйте: логування відмов, перегляд змін і задокументуйте runbook «права змінено → повторна автентифікація сесії».

Зробіть це, і «одна VPN» перестане бути компромісом безпеки і стане тим, чим мала бути від початку: контрольованою точкою входу з керованим доступом.