Контроль доступу між офісами: забезпечте правило «лише сервери, не вся локальна мережа»

December 20, 2025 • February 3, 2026 • Читання: 5 хв • Views: 6

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

Ви хочете з’єднати два офіси — але не бажаєте, щоб кожен принтер, ноутбук BYOD і «тимчасова» камера IoT в Офісі A мала прямий доступ до робочих станцій Офісу B. Ви прагнете логічного правила: трафік між офісами — для серверів та невеликого набору керованих сервісів, а не для всієї LAN.

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

Модель: офіси — ненадійні, дозволені — сервіси

«Лише сервери, не вся LAN» звучить як правило брандмауера. Насправді це позиція в мережевому дизайні:

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

Практично, «лише сервери» означає:

Між Офісом A і Офісом B доступні лише невеликі набори призначених підмереж (наприклад, 10.20.10.0/24 для серверів, а не 10.20.0.0/16 для всього).
Навіть у дозволених підмережах дозволені лише потрібні порти (наприклад, 443 до зворотних проксі, 22 лише через бастіони, 445 — тільки через файловий шлюз, якщо взагалі потрібно).
Маршрути та політики узгоджені: не рекламувати маршрут, який плануєте блокувати, і не блокувати те, що ненавмисно рекламувалося більш специфічним префіксом.
Логування обов’язкове на межі. Якщо ви не можете відповісти «хто ініціював що куди», то ви не контролюєте доступ — ви здогадуєтесь.

Суб’єктивна думка: якщо ваш «офіс‑до‑офісу VPN» — просто тунель з 0.0.0.0/0 з обох сторін і ви сподіваєтесь, що хост‑фаєрволи врятують ситуацію, ви будуєте канал інцидентів.

Визначте «сервер» конкретно

Команди застрягають, бо «сервер» перетворюється на розмитий образ. Зробіть це конкретним:

Серверні підмережі — IP‑діапазони, присвячені керованим робочим навантаженням (кластери VM, вузли контейнерів, NAS, AD/LDAP, зворотні проксі).
Клієнтські підмережі — кінцеві пристрої користувачів (дротові, Wi‑Fi, гостьові, лабораторії, переговорні).
Інфраструктурні підмережі — мережеві пристрої, моніторинг, площини керування, jump‑hostи та VPN‑концентратори.

Потім закріпіть це: міжофісне з’єднання дозволене лише до серверних + інфраструктурних підмереж, з переліком дозволених портів і, бажано, з додатковою ідентичністю (mTLS, проксі зі SSO або перевірка стану пристрою).

Факти та історія, які пояснюють, чому це часто ламається

Контекст допомагає. Не тому, що це мило, а тому, що ці сценарії відтворюються з тих самих причин.

Ранні корпоративні мережі росли «плоскими», бо це було дешевше. VLAN-и та між‑VLAN маршрутизація часто з’являлися пізніше, не як початковий план.
Site‑to‑site VPN-и вибухнули у 2000‑х, коли інтернет‑з’єднання стали надійними, щоб замінити виділені лінії; багато проєктів успадкували припущення «довереного WAN» з епохи MPLS.
Культура MPLS навчила довіряти хмарі провайдера. Коли команди перейшли на інтернет‑VPN, вони часто зберігали маршрути «будь‑куди‑до‑будь‑куди», але з шифруванням.
CIDR (1993) дозволив агрегацію, але також спростив надмірні узагальнення: рекламувати /16, бо це акуратно, а не безпечно.
NAT став опорою безпеки в багатьох офісах. Він ховає адресацію, але не гарантує найменших привілеїв; лише ускладнює відлагодження.
SMB і Windows‑оголошення історично очікували близькості в LAN. Коли офіси зʼєднуються, трафік виявлення витікає і перетворюється на «чому повільний вхід?»‑квитки.
Принтери історично вважалися безпечними. Потім виявилось, що багато з них працюють на старих стек‑ах і можуть стати точками розгортання. Принтери: дарують папір — іноді й дані.
Брандмауери стали швидшими, отже люди стали лінивішими. Коли пристрій може пропустити десятки Гбіт/с, «просто дозволити» здається безпечним. Ні — масштаб робить помилки голоснішими.

Цитата, яку варто мати на увазі в кожному рев’ю дизайну (парафраз): «Сподівання — не стратегія.» — приписують Ed Catmull у колах експлуатації; формулювання різниться, тож розглядайте ідею, а не догму.

Опорна архітектура: маршрути, політики та контрольні точки

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

Оберіть свої контрольні точки

У кожному офісі потрібен пристрій (або HA‑пара), який виконує:

термінацію site‑to‑site тунелю (або SD‑WAN оверлею),
L3‑шлюз для серверних і клієнтських VLAN‑ів (або принаймні маршрутизатор між VLAN‑ами),
точку виконання міжофісних політик,
точку логування.

Поширені варіанти: фаєрвол‑пристрій, маршрутизатор з ACL, Linux‑шлюз з nftables або SD‑WAN edge. Бренд важить менше за дисципліну: deny‑by‑default, вузькі дозволи та контрольоване рекламування маршрутів.

Стратегія маршрутизації: рекламувати лише те, що плануєте дозволити

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

Опції:

Статичні маршрути: добре для малих середовищ, явні точки відмови, легко аудітувати. Погано, коли масштабуєте до багатьох підмереж і сайтів.
Динамічна маршрутизація (BGP/OSPF через тунель): масштабована та швидке перемикання, але вона радо розповсюджує ваші помилки зі швидкістю протоколу.
Політична маршрутизація SD‑WAN: зручно централізовано керувати намірами, але треба розуміти андерлей і що відбувається при конфлікті політик.

Правило: не рекламувати клієнтські підмережі через межу між офісами. Якщо клієнтам Офісу A потрібен сервіс в Офісі B, вони повинні звертатись до сервісного endpoint в Офісі B (reverse proxy, шлюз, bastion, опублікований додаток), а не до клієнтської VLAN.

Стратегія політик: відмова за замовчуванням з явними дозволами

На межі між офісами реалізуйте матрицю політик, що включає:

Зони джерела (Office A client, Office A server, Office A infra)
Зони призначення (Office B server, Office B infra)
Групи сервісів (HTTPS, SSH через бастіон, моніторинг, служби каталогів, реплікація бекупів)
Логування для відхилень і для частини дозволів (або принаймні вибіркова вибірка), щоб довести, що реальність відповідає намірам.

Станова інспекція — ваш друг. Асиметрична маршрутизація — ні. Ми це розберемо пізніше, бо це обов’язково трапиться у вас.

Ідентичність зверху: «підмережа сервера» недостатньо

Allowlist підмереж зменшує площу атаки. Вони не завадять скомпрометованому серверу стати плацдармом.

Для важливих шляхів додайте:

mTLS між сервісами
SSH через бастіони (жодного прямого SSH з офісних клієнтів у віддалені серверні мережі)
Проксі‑шлюзи додатків (HTTP reverse proxy, RDP gateway, файловий шлюз)
Перевірку стану пристрою (device posture) там, де можливо

Так, це додатково. Ні, ви не пошкодуєте о 02:00.

Опції контролю і коли використовувати кожну

1) Фільтрація маршрутів (кращий перший рівень)

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

Використовуйте її, коли контролюєте маршрутизацію (статичну або BGP/OSPF) і хочете надійну межу.

2) Станові політики брандмауера (реальна книга правил)

Навіть з фільтрацією маршрутів потрібна політика фаєрвола, бо:

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

3) Мікросегментація / хост‑фаєрволи (добре, але недостатньо самі по собі)

Хост‑фаєрволи (Windows Firewall, ufw, firewalld) і агенти мікросегментації можуть значно зменшити латеральний рух. Але покладатися лише на них — означає ставити межу на гігієну кінцевих точок. Ця ставка рано чи пізно програє.

4) Публікація на рівні додатків (кращий UX у багатьох випадках)

Замість того, щоб дозволяти Офісу A ширше діставатися до серверів Офісу B, опублікуйте конкретні додатки:

HTTPS‑додатки за зворотним проксі з SSO
RDP через gateway з MFA
SMB через файловий шлюз або механізм синхронізації

Коли люди кажуть «нам потрібен мережевий доступ», запитайте, що саме їм потрібно. Зазвичай це «один веб‑додаток і один шар файлів», а не «ми повинні бачити всі пристрої в /16».

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

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

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

Завдання 1: Доведіть, які маршрути у вас насправді є (і чи просочилися клієнтські підмережі)

cr0x@server:~$ ip route show
default via 10.10.0.1 dev eth0 proto dhcp src 10.10.0.20 metric 100
10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.20
10.20.10.0/24 via 10.10.0.1 dev eth0
10.20.30.0/24 via 10.10.0.1 dev eth0

Значення: Цей хост може маршрутизувати до двох віддалених підмереж: 10.20.10.0/24 і 10.20.30.0/24. Якщо 10.20.30.0/24 — клієнтська VLAN, ви вже порушили правило «лише сервери».

Рішення: Виправити рекламування маршрутів або статичні маршрути в першу чергу. Не «заклеюйте» витоки маршрутів правилами на хості.

Завдання 2: Перевірте, що ваш VPN‑інтерфейс думає, що робить

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.10.0.20/24 fe80::a00:27ff:fe4e:66a1/64
tun0             UP             172.31.255.2/30

Значення: Тунельний інтерфейс піднятий з /30. Це нормально. Це не показує, що по ньому маршрутують, лише що інтерфейс існує.

Рішення: Корелюйте з таблицею маршрутів і політиками брандмауера; не припускайте, що «tun0 піднятий» означає «політика вірна».

Завдання 3: Перевірте шлях до віддаленої серверної підмережі (і впіймайте несподівані об’їзди)

cr0x@server:~$ tracepath -n 10.20.10.50
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.10.0.1                                            0.410ms
 2:  172.31.255.1                                         1.283ms
 3:  10.20.10.50                                          2.104ms reached
     Resume: pmtu 1500 hops 3 back 3

Значення: Трафік іде до локального шлюзу, потім через тунель до піринга, потім до призначення. Чистий шлях, MTU 1500.

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

Завдання 4: Перевірте PMTU (класична «пінгує, але додаток зависає»)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.10.50
PING 10.20.10.50 (10.20.10.50) 1472(1500) bytes of data.
From 10.10.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.10.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1400)
From 10.10.0.1 icmp_seq=3 Frag needed and DF set (mtu = 1400)

--- 10.20.10.50 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Значення: Ефективний MTU на шляху — 1400. Великі пакети з DF не проходять. Деякі додатки зависатимуть або безкінечно повторюватимуть передачі.

Рішення: Обмежити MSS на VPN/фаєрволі, або встановити відповідний MTU тунелю. Потім повторно протестувати з різними розмірами до стабільності.

Завдання 5: Підтвердіть, що фаєрвол відкидає (приклад nftables)

cr0x@gateway:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "lan_clients" oifname "vpn0" ip daddr 10.20.10.0/24 tcp dport { 443 } accept
    iifname "lan_clients" oifname "vpn0" counter log prefix "DROP interoffice " drop
  }
}

Значення: За замовчуванням drop у ланцюгу forward. Дозволено лише з клієнтської VLAN до віддаленої серверної підмережі на 443. Все інше логиться і відкидається.

Рішення: Форма коректна. Далі переконайтеся, що правила симетричні (зворотний шлях) і зони відповідають реальним інтерфейсам.

Завдання 6: Спостерігайте відкидання в реальному часі, щоб побачити, що користувачі намагаються (і що ви забули)

cr0x@gateway:~$ sudo journalctl -k -f | grep "DROP interoffice"
Aug 21 10:13:02 gw kernel: DROP interoffice IN=lan_clients OUT=vpn0 SRC=10.10.50.23 DST=10.20.30.44 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=5421 DF PROTO=TCP SPT=51844 DPT=445 WINDOW=64240 SYN
Aug 21 10:13:04 gw kernel: DROP interoffice IN=lan_clients OUT=vpn0 SRC=10.10.50.23 DST=10.20.10.60 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=5512 DF PROTO=TCP SPT=51845 DPT=3389 WINDOW=64240 SYN

Значення: Хтось намагається SMB (445) до віддаленої клієнтської підмережі (10.20.30.44) і RDP (3389) до сервера (10.20.10.60). Ваша політика дозволила лише 443.

Рішення: Не поспішайте дозволяти 445/3389. Запитайте: чи повинен SMB проходити між офісами? Чи має RDP йти через шлюз? Зазвичай відповідь: «опублікувати правильно».

Завдання 7: Перевірте, що BGP‑реклама не витікає клієнтські діапазони

cr0x@router:~$ vtysh -c "show ip bgp neighbors 172.31.255.1 advertised-routes" | sed -n '1,40p'
BGP table version is 44, local router ID is 10.10.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.20.10.0/24    0.0.0.0                  0         32768 i
*> 10.20.99.0/24    0.0.0.0                  0         32768 i

Значення: Ви рекламували два префікси. Якщо 10.20.99.0/24 — клієнтська/Wi‑Fi VLAN, ви експортуєте її через міжофісний лінк.

Рішення: Додайте prefix‑lists/route‑maps, щоб експортувати лише серверні та інфраструктурні префікси. Після цього підтвердіть на віддаленій стороні, які маршрути отримано.

Завдання 8: Перевірте отримані маршрути на іншій стороні (підтвердіть, що виправлення спрацювало)

cr0x@router-b:~$ vtysh -c "show ip bgp neighbors 172.31.255.2 received-routes" | sed -n '1,40p'
BGP table version is 107, local router ID is 10.20.0.1

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.20.10.0/24    172.31.255.2            0             0 i

Значення: Отримано лише серверний префікс. Добре. Менше досяжності — менше несподіванок.

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

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

cr0x@gateway:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 1

Значення: IP‑форвардинг увімкнено. Reverse path filtering суворий (1). Строгий rp_filter може скидати легітимний трафік, коли шляхи повернення відрізняються (поширено при подвійних каналах, SD‑WAN або політичній маршрутизації).

Рішення: Якщо спостерігаєте односторонній трафік при валідному стані, розгляньте встановлення rp_filter у 2 (loose) на VPN‑інтерфейсах, але тільки після розуміння симетрії маршрутів.

Завдання 10: Захопіть трафік на межі, щоб відрізнити «немає маршруту» від «фаєрвол відкинув»

cr0x@gateway:~$ sudo tcpdump -ni vpn0 host 10.10.50.23 and host 10.20.10.50 and tcp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vpn0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:15:22.011221 IP 10.10.50.23.51910 > 10.20.10.50.443: Flags [S], seq 405483990, win 64240, options [mss 1360,sackOK,TS val 120119 ecr 0,nop,wscale 7], length 0
10:15:22.032909 IP 10.20.10.50.443 > 10.10.50.23.51910: Flags [S.], seq 29199210, ack 405483991, win 65160, options [mss 1360,sackOK,TS val 99122 ecr 120119,nop,wscale 7], length 0

Значення: SYN і SYN‑ACK видно на vpn0. Хендшейк відбувається. Якщо клієнт усе ще не працює, проблема, ймовірно, за межами міжофісного зв’язку (хост‑фаєрвол, TLS, проксі, додаток).

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

Завдання 11: Перевірте доступність порту без самомарення

cr0x@client-jumphost:~$ nc -vz -w 3 10.20.10.50 443
Connection to 10.20.10.50 443 port [tcp/https] succeeded!

Значення: TCP‑connect працює. Це достатньо для L3/L4. Це не підтверджує коректність додатку.

Рішення: Якщо з’єднання невдале — перевіряйте логи фаєрвола і маршрути. Якщо з’єднання успішне, але додаток не працює — перевірте TLS‑сертифікати, SNI, проксі та серверні ACL.

Завдання 12: Підтвердіть, що віддалена клієнтська підмережа дійсно недосяжна (мета)

cr0x@client-jumphost:~$ ping -c 2 10.20.30.44
PING 10.20.30.44 (10.20.30.44) 56(84) bytes of data.

--- 10.20.30.44 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1021ms

Значення: Відсутня відповідь ICMP. Це саме по собі не доводить блокування (ICMP може фільтруватись), але це хороший сигнал у поєднанні з маршрутами й логами фаєрвола.

Рішення: Підтвердіть за допомогою ip route get 10.20.30.44 і лічильників/логів фаєрвола. Мета: немає маршруту або явний drop з логом.

Завдання 13: Покажіть, яке правило спрацьовує (приклад лічильників iptables)

cr0x@gateway:~$ sudo iptables -L FORWARD -v -n --line-numbers | sed -n '1,25p'
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in          out         source          destination
1     918K  712M ACCEPT     all  --  *           *           0.0.0.0/0       0.0.0.0/0       ctstate RELATED,ESTABLISHED
2     231K   18M ACCEPT     tcp  --  lan_clients vpn0        10.10.50.0/24    10.20.10.0/24    tcp dpt:443
3     1245  104K DROP       all  --  lan_clients vpn0        0.0.0.0/0       0.0.0.0/0

Значення: Правило 2 активно використовується; правило 3 відкидає решту. Лічильники роблять політику реальною. Якщо правило 3 швидко зростає, користувачі/додатки намагаються заборонені шляхи.

Рішення: Дослідіть, що відкидається, перш ніж додавати нові дозволи. Іноді правильним виправленням є «припинити це робити», а не «відкрити фаєрвол».

Завдання 14: Доведіть, що DNS не створює ілюзій «воно впало» між офісами

cr0x@client-jumphost:~$ dig +short app.officeb.internal
10.20.10.50

Значення: Ім’я резольвиться у IP серверної підмережі. Добре. Якщо воно резольвиться у клієнтський підмережі або публічний IP неочікувано, план контролю доступу буде виглядати «випадковим» для користувачів.

Рішення: Переконайтесь, що внутрішній DNS дає різні відповіді по сайтах тільки тоді, коли це навмисно. Не дозволяйте split‑horizon DNS перетворитися на split‑brain.

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

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

Перше: істина маршрутизації (досяжність на L3)

На вихідному хості: ip route get <dest-ip>, щоб побачити egress‑інтерфейс і наступний хоп.
На шлюзі: підтвердити, що маршрут існує і веде в тунель/SD‑WAN оверлей.
На віддаленому шлюзі: підтвердити, що шлях повернення існує назад до джерельної підмережі (або що NAT політика навмисна і послідовна).

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

Друге: політика фаєрвола і лічильники (відкидається чи дозволяється?)

Перевірте політику за замовчуванням: drop чи accept.
Перевірте явний allow для точного кортежу: src підмережа, dst підмережа, протокол, порт.
Перевірте лічильники/логи під час відтворення проблеми.

Якщо лічильники показують відкидання, вирішіть: це легітимний запит (опублікуйте/шлюзуйте його), чи це латеральний рух (тримайте відкинутим)?

Третє: стани і асиметрія (пастка «має працювати»)

Шукайте асиметричні шляхи повернення (dual WAN, політична маршрутизація, ECMP, події SD‑WAN failover).
Перевірте rp_filter та поведінку таблиці станів.
Використовуйте tcpdump на обох інтерфейсах (LAN і VPN), щоб підтвердити, що пакети йдуть як очікувалось.

Четверте: MTU і фрагментація (безшумний вбивця)

Використовуйте ping -M do з різними розмірами, щоб знайти робочий MTU.
Шукайте «Frag needed and DF set».
Обмежуйте MSS на тунелі.

П’яте: рівень додатків та ідентичність

Тестуйте TCP‑з’єднання (nc), потім TLS (openssl s_client за потреби), потім сам додаток.
Перевіряйте серверні фаєрволи та ACL.
Валідуйте DNS‑відповіді з ураженого сайту.

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

Це ті, що постійно з’являються, бо вони спокусливі.

1) «Ми дозволили лише серверні підмережі, але користувачі все одно дістаються віддалених десктопів»

Симптом: Користувачі з Офісу A підключаються через RDP до випадкових машин в Офісі B.

Корінь: «Серверна підмережа» включає VDI‑пули, jump‑boxи з широким доступом або неправильно класифіковані десктопи. Або ви дозволили 3389 широко в серверній VLAN.

Виправлення: Виведіть адміністраторські/VDI/бастіон‑сегменти в окремі підмережі й застосуйте жорсткіші правила. Використовуйте RDP‑gateway з MFA; блокуйте прямий 3389 між офісами.

2) «Пінги працюють, HTTPS таймаутиться»

Симптом: ICMP в порядку, TCP‑хендшейк можливо проходить, але великі відповіді зависають.

Корінь: Невідповідність MTU/MSS у тунелі або PMTUD блокується.

Виправлення: MSS‑clamping на краю VPN, дозволити ICMP fragmentation‑needed, встановити MTU тунелю правильно, потім перевірити ping‑и з DF.

3) «Ми заблокували все, тепер нічого не працює — навіть те, що дозволено»

Симптом: Навіть явні allow‑правила ігноруються.

Корінь: Неправильне відображення зон/інтерфейсів, політика застосована в невірному напрямку або обхід політик через hardware offload/fast‑path.

Виправлення: Перевірте імена інтерфейсів, членство у зонах і порядок правил. Тимчасово відключіть fast‑path для діагностики. Підтвердіть через лічильники й tcpdump.

4) «Після відмови деякі потоки вмирають і не відновлюються»

Симптом: SD‑WAN failover відбувається; деякі користувачі підключаються, деякі — ні.

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

Виправлення: Забезпечте симетрію маршрутів або синхронізацію сесій в HA. Використовуйте консистентні NAT‑політики. Розгляньте loose rp_filter на тунельних інтерфейсах.

5) «Ми не рекламували клієнтські підмережі, але віддалий офіс все одно їх дістає»

Симптом: Ви впевнені, що фільтрація маршрутів є, але звʼязок існує.

Корінь: Хтось додав супернет статичним маршрутом, або через тунель пройшов default route, або NAT ненавмисно робить hairpin.

Виправлення: Аудит статичних маршрутів на шлюзах, перевірка 0/0 або великих сум у селекторах VPN/crypto ACL, і верифікація через ip route і BGP‑таблиці.

6) «Доступ до файлових шарів переривчастий і повільний між офісами»

Симптом: SMB працює, але користувачі постійно скаржаться.

Корінь: SMB‑чатливість через лінки з більшою затримкою, проблеми opportunistic locking і блокування/розпізнавання імен, які фільтруються дивним чином.

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

7) «Команда безпеки просить «ніхто в ширину» але нам потрібен моніторинг»

Симптом: Моніторинг або бекап ламаються після сегментації.

Корінь: Моніторинг/бекапи покладалися на широку досяжність (ICMP, SNMP, агенти, RPC).

Виправлення: Зробіть моніторинг повноцінною службою: виділена моніторинг‑підмережа, явні порти і, бажано, pull‑агенти з mTLS.

Жарт 2: VPN без фільтрації — це просто довгий Ethernet‑кабель з паспортним штампом.

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

Міні‑історія 1: Інцидент, спричинений хибним припущенням

Два офіси. Один «корпоративний», інший «супутниковий». Супутнику потрібен доступ до кількох внутрішніх веб‑додатків і SSH‑бастіона. Мережна команда розгорнула site‑to‑site тунель і попросила «підмережі» для маршрутизації.

Власник додатку відповів приблизно так: «Ми використовуємо 10.40.0.0/16». Це було правдиво так само, як «океан мокрий»: технічно вірно, оперативно марно. Всередині цього /16 жили серверні VLAN, користувацькі VLAN, принтери та лабораторна мережа, де інженери тестували речі, які, можливо, не мали тестувати.

Хибне припущення було простим: «Якщо це внутрішнє, то довірене.» Протягом тижня скомпрометований ноутбук у супутниковому офісі (фішинг, нічого надзвичайного) просканував тунель, знайшов старий SMB‑шар на десктопній VLAN у HQ і використав його як плацдарм. Атакуючому не потрібен був нуль‑ді; йому потрібна була досяжність і час.

Форензика була неприємною. Не тому, що експлойт був хитрим — він не був — а тому, що логи були тонкими. Пристрій VPN мав «allow any» з мінімальним логуванням, щоб «не створювати шуму». Команда кінцевих точок наполягала, що ноутбук патчено. Мережева команда наполягала, що тунель «приватний». Кожен був правий у способі, що веде до компрометації.

Виправлення не було героїчним. Вони перестали рекламувати /16, розбили мережу на опубліковані серверні префікси і примусили доступ адміністратора через бастіон з MFA. Звіт incident response багато разів згадував слово «сегментація». Справжній урок короткий: перестаньте маршрутизувати те, що не хочете захищати.

Міні‑історія 2: Оптимізація, що виявилась помилкою

Середня компанія розгорнула SD‑WAN для підключення кількох офісів. Продуктивність одразу зросла; джиттер зменшився, відеодзвінки перестали звучати, ніби під водою. Мережна команда потім «оптимізувала» політику безпеки: замість десятків детальних правил вони узагальнили їх у кілька великих. Менше правил — менше помилок. Звучить логічно, правда?

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

Спочатку нічого не трапилось. Саме тому цей клас помилок небезпечний: він чекає. Потім машина підрядника почала генерувати підозрілий трафік до внутрішнього Git‑сервісу в іншому офісі. Доступ не блокували, бо він підпадав під нове узагальнене правило allow. Сигналів не спрацювало, бо трафік виглядав як звичайний HTTPS.

Постмортем був недобрий до оптимізації. Дані не вкрали, але витратили багато часу. Команді довелось відкотити агрегат, визначити, що VLAN підрядників повинна була мати доступ майже ні до чого, і додати route‑maps, щоб уникнути ненавмисного включення в майбутні узагальнення.

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

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

Фінансова організація з двома основними офісами мала сувору міжофісну політику: тільки серверні підмережі, тільки конкретні порти, і всі правила проходили через зміну з власником і строком дії. Це не захоплювало. Люди скаржилися на процес. Звісно.

Одного дня надійшов тикет: «Користувач в Офісі A не може дістатися до чогось в Офісі B». Запит виглядав легітимним і терміновим. Почався тиск: «Просто тимчасово відкрийте».

Черговий SRE зробив нудну річ. Він перевірив логи фаєрвола і побачив повторні спроби доступу до TCP/445 і TCP/135 між офісами з користувацької VLAN — класичні шаблони латерального руху, а не «доступ до додатку». Також він перевірив DNS і виявив, що хостнейм резольвився у десктопну підмережу в Офісі B, а не в опублікований сервісний endpoint.

Замість відкриття фаєрвола він виправив проблему: виправив DNS, щоб ім’я вказувало на reverse proxy в серверній VLAN, і додав вузький allow тільки до TCP/443 для цього проксі. Тим часом команда безпеки розглядала кінцеву точку користувача. Виявилось, що пристрій був інфікований і пробував свої шанси.

Нічого драматичного не сталося, бо політика була спроєктована так, щоб робити драматичні речі нудними. Це мета: зробити безпечний шлях простим, а небезпечний — гучним і заблокованим.

Перевірочні списки / покроковий план

Покроковий план: запровадити «лише сервери» без шкоди бізнесу

Перелікуйте підмережі за функцією: client, server, infra, guest, lab. Якщо не можете позначити підмережу — її не готово маршрутизувати нікуди.
Визначте дозволені префікси призначення для кожного офісу: зазвичай лише server + infra. Тримайте їх короткими.
Визначте сервісні порти під кожен випадок використання:
- Веб‑додатки: 443 до reverse proxy
- Адмінка: 22 тільки з бастіонів; уникайте прямого SSH між офісами
- Директорійні служби: тільки те, що потрібно, з конкретних джерел
- Моніторинг: лише з мережі моніторингу
Виправте маршрутизацію першою: фільтрація префіксів або статичні маршрути тільки для дозволених префіксів. Не експортуйте клієнтські VLAN.
Застосуйте політики фаєрвола: default‑deny, явні дозволи з логуванням. Переконайтесь, що враховані обидва напрямки (станова інспекція допомагає, але не чекайте дива).
Визначте NAT‑політику: бажано без NAT для внутрішнього‑до‑внутрішнього, але якщо NAT потрібен — робіть це послідовно і документуйте причину. NAT може приховувати помилки маршрутизації; він їх не виправляє.
Публікуйте додатки замість мереж, де можливо: reverse proxy, шлюзи, SSO, MFA. Користувачі потребують додатків, не підмереж.
Впровадьте робочий процес змін: кожен новий міжофісний дозвіл потребує власника і терміну дії. Тимчасові правила без кінця — брехня.
Тестуйте з обох сторін: перевірка маршрутів, портів і додатків. Раніше перевірте MTU.
Базуйте логи і лічильники: ви маєте вміти відповісти «що відкидалось» і «що дозволялось» під час інциденту.
Проведіть tabletop‑дрил: симулюйте витік маршруту або неправильне узагальнення префіксу і перевірте виявлення (оповіщення про нові префікси, сплески відкидань, несподівані потоки).

Оперативний чекліст: що моніторити постійно

Нові маршрути, вивчені через міжофісну суміжність (особливо широкі агрегати і клієнтські VLAN).
Підрахунки влучань правил фаєрвола для «deny interoffice» (сплески часто означають сканування або помилку конфігурації).
Індикатори MTU/фрагментації тунелю та TCP‑ретрансмісій.
Події зміни шляху SD‑WAN і failover у кореляції зі скаргами на додатки.
DNS‑аномалії: внутрішні імена резольвяться у несподівані підмережі по сайтах.
Сигнали ідентичності: помилки MFA, незвичайне використання бастіона, аномальна поведінка сервісних акаунтів.

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

1) Чи краще блокувати маршрути, ніж блокувати фаєрволом?

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

2) Нам потрібно, щоб користувачі Офісу A доступали базу даних в Офісі B. Чи дозволяти DB‑підмережу?

Надавайте перевагу публікації через рівень додатків або проксі в Офісі B. Якщо доводиться дозволяти доступ до БД, обмежте його до конкретних підмереж (або хостів) та конкретних портів, і логируйте. Бази даних — не повсякденні міжофісні сервіси.

3) Чи можемо ми покладатись на Windows Firewall на серверах замість мережевих фаєрволів?

Використовуйте Windows Firewall — безумовно. Але не покладайтесь на нього як на єдину межу. Мережеве виконання дає послідовну політику, централізовані логи і складнішу точку обходу.

4) Що якщо «ми довіряємо наші офіси», бо це одна компанія?

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

5) Чи слід NAT‑ити між офісами, щоб «сховати» мережі?

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

6) Як вирішувати перекриття RFC1918 після поглинання?

Короткостроково: NAT на межі й тримати дозволені сервіси вузькими. Середньостроково: перенумеруйте одну зі сторін або введіть сегмент перекладу з чіткою відповідальністю. Довгостроково: перестаньте сприймати IP‑простір як дрібницю при інтеграції.

7) Наша команда безпеки каже «zero trust». Що це означає для міжофісного звʼязку?

Це значить, що мережева локація недостатня. Тримайте allowlist підмереж, але додавайте ідентичність: mTLS, проксі з SSO, перевірку стану пристрою і MFA для адміністративних шляхів. «Лише сервери» стає «лише конкретні сервіси на конкретних серверах з верифікованою ідентичністю».

8) Як запобігти тому, щоб «тимчасові» правила ставали постійними?

Зробіть обов’язковими дати закінчення, автоматизуйте нагадування (або автоматичне відключення) після завершення терміну. Якщо правило все ще потрібне, продовжіть його з обґрунтуванням. Тертя в цьому процесі — це функція.

9) Які порти ніколи не слід широко дозволяти між офісами?

Загалом: SMB (445), NetBIOS (137–139), RPC endpoint mapper (135) і прямий RDP (3389). Є винятки, але вони повинні відчуватись саме як винятки і мати компенсаційні контролі.

10) Який найшвидший доказ того, що ми досягли «лише сервери»?

З клієнтської підмережі в Офісі A має бути (a) немає маршруту до клієнтських VLAN Офісу B, і (b) логи фаєрвола, що показують відкидання спроб доступу. З схвалених джерел схвалені порти до серверних підмереж повинні проходити з чистими лічильниками.

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

«Лише сервери, не вся LAN» — це не слоган. Це дизайн, який ви реалізуєте дисципліною маршрутизації, політикою «deny by default» і логами, що говорять правду, коли хтось наполягає «раніше працювало».

Практичні кроки:

Перерахуйте кожну підмережу в обох офісах і позначте її client/server/infra/guest/lab.
Припиніть рекламувати клієнтські VLAN через міжофісний зв’язок. Використовуйте prefix‑lists або закрутіть статичні маршрути.
Впровадьте політику міжофісного фаєрвола з deny‑by‑default і явними дозволами до серверних підмереж з вузькими портами.
Публікуйте додатки через шлюзи/проксі замість відкриття широкого мережевого доступу (особливо для RDP і SMB).
Додайте логування і лічильники, потім зафіксуйте, як виглядає «норма» перед наступним інцидентом, що навчить вас важко.

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

Схожі статті

VPN повна сітка для трьох офісів: коли вона потрібна і як її підтримувати керованою