VPN + RDP/SSH: віддалений доступ без відкриття портів в інтернеті

Чому не варто відкривати RDP/SSH в інтернет

Відкривати RDP (3389) або SSH (22) в інтернет — це як повісити зчитувач пропусків біля входу в офіс на ліхтарному стовпі з наліпкою «будь ласка, поводьтеся нормально». Люди не будуть поводитися нормально.

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

Розміщення RDP/SSH за VPN змінює ситуацію в трьох вимірах:

• Доступність: сервіси більше не доступні публічно, тож більшість опортуністичних атак і не стартує.
• Межа ідентичності: першією перешкодою стає аутентифікація VPN та стан пристрою, а не цільовий сервіс.
• Спостережуваність: ви можете логувати й обмежувати швидкість в одній точці. Одне місце для перевірки, одне місце для блокування.

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

Цікаві факти та коротка історія

Контекст важливий. Багато сучасних болів з віддаленим доступом — це наслідок колишніх рішень «відвантажити і забути».

1. RDP не створювався для ворожих мереж. Він виростав в корпоративних LAN і WAN, а не в сучасній загрозовій моделі інтернету.
2. SSH замінив telnet/rsh, бо текстові паролі помирали. Раннє впровадження SSH наприкінці 1990-х було практичною відповіддю на «люди можуть перехоплювати ваші паролі».
3. IPsec зʼявився раніше за більшість хмарних звичок. IPsec існує з 1990-х; багато «нових» дискусій про VPN — це старі аргументи в нових одежах.
4. SSL VPN стали популярними через NAT. Коли все за NAT і фаєрволами, тунелювання по TCP/443 стало тактикою виживання.
5. Грубе перебиральництво RDP перетворилося на економіку. Ботнети люблять сканувати 3389, бо це стабільно прибутково: облікові дані, підготовка шляху для ransomware, латеральний рух.
6. WireGuard молодий, але принциповий. Він навмисне компактний, із сучасною криптографією і менше налаштувань. Для операцій це перевага — менше місць для помилок.
7. Split tunneling — давній спір. Безпека хоче його вимкненим. Мережевики — увімкненим. Відповідь часто «залежить», але не так часто, як думають.
8. Bastion-хости — це сучасні jump box. Ідея стародавня: одна контрольована двері в приватну мережу.
9. NLA (Network Level Authentication) врятував репутацію RDP. Аутентифікація стала раніше в процесі підключення, що зменшило вплив деяких класів атак.

Еталонна архітектура, що працює в реальному світі

Ось архітектура, яку я рекомендую, коли вам потрібне віддалене адміністрування (RDP/SSH) без відкривання цих портів. Вона масштабується від компанії на 10 осіб до корпорації з трьома різними VPN-продуктами через злиття.

Мета: зробити приватну мережу єдиною важливою мережею

Основна ідея проста: ваші адміністративні кінцеві пристрої (ноутбуки) підключаються до VPN. Керовані системи (сервери/робочі станції) доступні лише з адресного простору VPN або внутрішніх підмереж. RDP/SSH привʼязані до внутрішніх інтерфейсів. Фаєрволи це контролюють.

Мінімальна кількість рухомих частин (без героїзму)

• VPN-шлюз: WireGuard або OpenVPN (або IPsec), бажано з резервуванням.
• Постачальник ідентичності: принаймні локальні акаунти + MFA; краще — інтеграція SSO на рівні VPN.
• Маршрутизація: або маршрутизований VPN (L3), або поєднання політик і NAT. Надавайте перевагу маршрутизованому варіанту.
• Контроль доступу: дозволені IP за користувачем або групою; бажано реалізовано в фаєрволі або конфігурації VPN.
• Логування: підключення/відключення VPN, події аутентифікації та метадані сесій. Для SSH — запис команд, де це можливо.

Де підходить jump host (і де ні)

Деякі команди вважають «VPN» і «bastion host» взаємовиключними. Так не є. Чистий підхід такий:

• Користувачі підключаються до VPN.
• Користувачі можуть досягати лише захищеного jump host (SSH) і, можливо, шлюзу віддалених робочих столів.
• З jump host вони отримують доступ до глибинних мереж на основі принципу найменших привілеїв.

Це знижує радіус можливого ураження, якщо ноутбук скомпрометовано, і дає місце для запису сесій. Але не ставте jump host лише щоб уникнути виправлення маршрутизації. Це не архітектура — це спокута.

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

Варіанти VPN, які не будуть вам шкодити

WireGuard: мій базовий вибір для сучасного адміністративного доступу

WireGuard компактний, швидкий і агресивно мінімалістичний. Для операцій це означає менше станів конфігурації, які «іноді працюють». Ключі статичні; ідентичність більше на кшталт «цей ключ пристрою дозволено». Ви можете нашарувати SSO і перевірку стану пристрою поза WireGuard, якщо використовуєте контролер, але навіть простий WireGuard — надійна база.

Компроміси:

• Плюси: продуктивність, стабільність, прості конфіги, чиста криптографія, легка маршрутизація.
• Мінуси: управління ключами на вас, якщо немає шару керування; відкликання — «видалити peer» (зручно, але потрібен процес).

OpenVPN: перевірений, гнучкий, іноді «балакучий»

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

Компроміси:

• Плюси: зріла екосистема, багато інтеграцій аутентифікації, опція TCP/443 для ворожих мереж.
• Мінуси: більше регулювань, вища складність, накладні витрати на продуктивність.

IPsec (IKEv2): відмінно, коли у вас гарна мережева дисципліна

IPsec чудовий, коли ви можете стандартизувати і вам важлива сумісність. Він також корисний для site-to-site тунелів між мережами, а не лише для окремих адміністраторів.

Проблема менше в протоколі, більше в реальності: постачальники по-різному інтерпретують стандарти, NAT traversal іноді відчувається як фольклор, а відлагодження може перетворитися на довгу сутичку з пакетними дампами.

Не плутайте «Remote Desktop Gateway» з «заміною VPN»

Шлюзи RDP можуть бути корисними. Вони також можуть стати яскравою ціллю, якщо ви опублікуєте їх у інтернеті. Якщо ви все ж виставляєте шлюз публічно, ставтеся до нього як до продакшн API: загартована ОС, MFA, обмеження швидкості, суворий TLS, патчі вразливостей та постійне логування. Інакше: тримайте шлюз теж за VPN.

Жарт №1: Правило фаєрволу з позначкою «temporary» — єдина річ в ІТ, що переживає апаратні засоби.

Ідентичність, контроль доступу та «хто що зробив»

Аутентифікація: зробіть VPN «важкою частиною»

Якщо ви ховаєте RDP/SSH за VPN, вхід до VPN стає вашим першим дверима. Зробіть його надійним:

• MFA для користувачів VPN. Не опціонально. Якщо ви не можете ввести MFA — ви не робите віддалений доступ, ви граєтеся в рулетку.
• Довіра до пристрою, якщо можливо: лише керовані пристрої, сертифікати або перевірка стану пристрою.
• Короткостроковий доступ для постачальників і в надзвичайних випадках: тимчасові акаунти або тимчасове членство в групах.

Авторизація: маршрутизація — це система дозволів

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

Натомість:

• Визначайте адресні пули VPN за ролями (адміністратори, підтримка, постачальники).
• Обмежуйте, які внутрішні підмережі може досягати кожен пул за допомогою правил фаєрволу на VPN-шлюзі або внутрішніх фаєрволів.
• Для дуже чутливих середовищ додайте другу перешкоду: лише jump host доступний, і цей хост контролює доступ до цілей.

Аудит: вам це знадобиться пізніше, тож побудуйте зараз

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

Як мінімум збирайте:

• Логи підключень VPN (ідентичність користувача/пристрою, вихідна IP, призначена VPN IP, час початку/закінчення).
• Логи RDP на Windows (події входу, початок/кінець сесії).
• SSH логіни аутентифікації і, по можливості, аудит виконаних команд для привілейованого доступу.

Укріплення RDP і SSH після розміщення за VPN

Привʼяжіть сервіси до внутрішніх інтерфейсів

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

Укріплення SSH, яке дійсно має значення

• Ключі замість паролів для облікових записів адміністраторів.
• Заборонити логін під root по SSH. Використовуйте sudo з логуванням.
• Обмежити користувачів за допомогою AllowUsers або AllowGroups.
• Використовувати сучасну криптографію (за замовчуванням у сучасних дистрибутивах зазвичай достатньо; не винаходьте нове).

Укріплення RDP, яке дійсно має значення

• Увімкніть NLA і вимагайте надійної аутентифікації.
• Використовуйте групу Remote Desktop Users свідомо; не додавайте туди «Domain Users» через втому.
• Обмежте буфер обміну/редирект дисків, якщо працюєте з чутливими даними. Зручність — це шлях, яким дані витікають.
• Швидко встановлюйте оновлення. Помилки, повʼязані з RDP, — не теорія.

Сегментуйте мережі управління

Якщо можете, тримайте виділену підмережу управління. Ваші продукційні підмережі не повинні бути місцем, де адміністратори випадково переглядають сервери через RDP. Саме так шкідливе ПЗ вивчає вашу внутрішню карту.

Практичні завдання з командами: перевірити, діагностувати, вирішити

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

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

cr0x@server:~$ ip -brief addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24 fe80::1c2:abff:fe3d:111/64
wg0              UP             10.42.0.2/32

Що це означає: wg0 існує і має 10.42.0.2. Якщо його немає або він DOWN — ви не «в VPN».

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

Завдання 2: Перевірити хендшейк WireGuard і останню активність

cr0x@server:~$ sudo wg show
interface: wg0
  public key: gD2RkqvB8sH9m3Q0uP5xPpZQmYQbqgG2vNQhJwRzG2A=
  listening port: 51820

peer: N7u2dX3XyqS3pWm0pYbV5z6mXh3q3wVxQe7zq7LwG3M=
  endpoint: 198.51.100.24:53321
  allowed ips: 10.42.0.1/32
  latest handshake: 34 seconds ago
  transfer: 42.11 MiB received, 18.07 MiB sent

Що це означає: Недавній хендшейк підтверджує крипто й базову звʼязність. Лічильники трафіку, що змінюються, означають, що трафік реально проходить.

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

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

cr0x@server:~$ ip route get 10.10.20.15
10.10.20.15 dev wg0 src 10.42.0.2 uid 1000
    cache

Що це означає: Ядро планує відправити трафік до 10.10.20.15 через wg0.

Рішення: Якщо воно каже dev eth0 або «unreachable», виправте AllowedIPs/маршрути VPN перед тим, як чіпати конфіг RDP/SSH.

Завдання 4: Перевірити базову досяжність (ICMP) і інтерпретувати обережно

cr0x@server:~$ ping -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 56(84) bytes of data.
64 bytes from 10.10.20.15: icmp_seq=1 ttl=63 time=23.4 ms
64 bytes from 10.10.20.15: icmp_seq=2 ttl=63 time=22.9 ms
64 bytes from 10.10.20.15: icmp_seq=3 ttl=63 time=23.1 ms

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 22.9/23.1/23.4/0.2 ms

Що це означає: Шлях працює, латентність розумна. Якщо ping не проходить — це ще не кінець: ICMP часто блокується.

Рішення: Якщо ping успішний, а TCP ні — фокус на портах сервісів і фаєрволах. Якщо ping не проходить — переходьте до traceroute і перевірки правил фаєрволу.

Завдання 5: Перевірити TCP-порт для SSH

cr0x@server:~$ nc -vz 10.10.20.15 22
Connection to 10.10.20.15 22 port [tcp/ssh] succeeded!

Що це означає: Щось слухає і доступне на порті 22.

Рішення: Якщо не вдається — перевірте стан сервісу та політики фаєрволу. Не «відкривайте просто так» глобально; відкривайте лише для VPN CIDR.

Завдання 6: Перевірити TCP-порт для RDP

cr0x@server:~$ nc -vz 10.10.30.25 3389
Connection to 10.10.30.25 3389 port [tcp/ms-wbt-server] succeeded!

Що це означає: RDP доступний на внутрішній адресі. Якщо RDP-клієнт все одно не підключається — проблема в аутентифікації/NLA/сертифікатах, а не в мережі.

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

Завдання 7: Підтвердити, що sshd слухає лише на внутрішніх/VPN інтерфейсах (Linux)

cr0x@server:~$ sudo ss -lntp | grep ':22'
LISTEN 0      128        10.10.20.15:22        0.0.0.0:*    users:(("sshd",pid=923,fd=3))
LISTEN 0      128           10.42.0.10:22        0.0.0.0:*    users:(("sshd",pid=923,fd=4))

Що це означає: SSH слухає на внутрішніх та VPN-адресах, а не на 0.0.0.0:22 (усі інтерфейси).

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

Завдання 8: Перевірити правила фаєрволу на VPN-шлюзі (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "wg0" tcp dport { 22, 3389 } accept
    iif "wg0" icmp type echo-request accept
    tcp dport 51820 accept
    reject with icmpx type port-unreachable
  }
}

Що це означає: Політика за замовчуванням — drop. Лише інтерфейс VPN wg0 може звертатися до SSH/RDP на цьому шлюзі. Порт WireGuard дозволено.

Рішення: Якщо ви бачите широкі дозволи на iif "eth0" для 22/3389 — виправте. Якщо політика drop і ви забули ct state established, отримаєте «працює 2 секунди» — нісенітницю.

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

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

Що це означає: Форвардинг увімкнено. Reverse path filtering — «loose» (2), зазвичай правильно для маршрутизації VPN з асиметричними шляхами.

Рішення: Якщо forwarding = 0 на маршрутизуючому шлюзі — увімкніть його. Якщо rp_filter строгий (1) і ви бачите односторонній трафік — встановіть 2 для відповідних інтерфейсів.

Завдання 10: Перевірити правила NAT, якщо ви вимушені NAT-ити (iptables)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.42.0.0/24 -o eth1 -j MASQUERADE

Що це означає: Клієнти VPN у 10.42.0.0/24 маскуються при виході через eth1 до внутрішніх мереж, які не знають маршрутів VPN.

Рішення: Надавайте перевагу додаванню правильних маршрутів замість NAT. Але якщо ви не можете швидко змінити внутрішню маршрутизацію — NAT може бути тимчасовим рішенням. Документуйте це, як зброю з заряджанням.

Завдання 11: Підтвердити, що цільовий Windows-хост дійсно слухає RDP

cr0x@server:~$ sudo nmap -Pn -p 3389 10.10.30.25
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-27 10:20 UTC
Nmap scan report for 10.10.30.25
Host is up (0.024s latency).

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Що це означає: Порт відкритий. Якщо RDP-клієнт видає помилку — це переговори/аутентифікація/сертифікат/NLA, а не закритий порт.

Рішення: Якщо порт закритий — перевірте Windows Firewall, групові політики та чи ввімкнено Remote Desktop.

Завдання 12: Визначити, де саме помилки автентифікації SSH, а де — мережеві

cr0x@server:~$ ssh -vvv admin@10.10.20.15
OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 10.10.20.15 [10.10.20.15] port 22.
debug1: Connection established.
debug1: Authenticating to 10.10.20.15:22 as 'admin'
debug1: Offering public key: /home/cr0x/.ssh/id_ed25519 ED25519 SHA256:4tS...
debug1: Authentications that can continue: publickey
debug1: Authentication succeeded (publickey).
debug1: Entering interactive session.

Що це означає: Мережа в порядку і аутентифікація пройшла. Якщо ви бачите таймаути — це мережа/маршрутизація/фаєрвол. Якщо «Permission denied» — це ключі/користувачі/політики.

Рішення: Проблеми з аутентифікацією направляйте до IAM/розподілу ключів. Таймаути — до мережі/SRE.

Завдання 13: Знайти, де пакети «вмирають» (traceroute через VPN)

cr0x@server:~$ traceroute -n 10.10.20.15
traceroute to 10.10.20.15 (10.10.20.15), 30 hops max, 60 byte packets
 1  10.42.0.1  24.102 ms  23.881 ms  23.770 ms
 2  10.10.0.1  24.231 ms  24.021 ms  23.996 ms
 3  10.10.20.15  23.902 ms  23.912 ms  23.901 ms

Що це означає: Ви бачите VPN-шлюз і внутрішні маршрутизаторні стрибки. Якщо зупиняється на ході 1 — шлюз не може маршрутизувати далі.

Рішення: Де воно зупиняється — туди і дивіться: таблиця маршрутизації, ACL або відсутній зворотний маршрут.

Завдання 14: Спостерігати живий трафік на VPN-шлюзі (tcpdump)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.42.0.2 and host 10.10.20.15 and tcp port 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:23:11.102334 IP 10.42.0.2.52144 > 10.10.20.15.22: Flags [S], seq 341234112, win 64240, options [mss 1420,sackOK,TS val 123 ecr 0], length 0
10:23:11.125883 IP 10.10.20.15.22 > 10.42.0.2.52144: Flags [S.], seq 91234122, ack 341234113, win 65160, options [mss 1360,sackOK,TS val 456 ecr 123], length 0

Що це означає: Ви бачите SYN і SYN-ACK. Це доводить, що зворотний трафік існує хоча б на wg0. Якщо ви бачите лише SYN — зворотний шлях зламаний.

Рішення: Якщо зворотного шляху немає — перевірте внутрішні маршрути назад до підмережі VPN або поведінку NAT.

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

cr0x@server:~$ ip route | grep 10.42.0.0
10.42.0.0/24 dev wg0 proto kernel scope link src 10.42.0.1

Що це означає: VPN-шлюз знає, що підмережа VPN на wg0. Це необхідно, але не достатньо: внутрішні маршрутизатори також повинні знати, де знаходиться 10.42.0.0/24.

Рішення: Якщо внутрішні маршрутизатори не мають зворотного маршруту — додайте його (краще) або використайте NAT (тимчасово). Односторонній VPN — класична втрата часу.

Завдання 16: Перевірити статус сервера OpenVPN, якщо у вас така стек

cr0x@server:~$ sudo systemctl status openvpn-server@server
● openvpn-server@server.service - OpenVPN service for server
     Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:41:02 UTC; 42min ago
       Docs: man:openvpn(8)
   Main PID: 1234 (openvpn)
      Tasks: 1 (limit: 18954)
     Memory: 9.6M
        CPU: 1.214s

Що це означає: Сервіс працює. Якщо користувачі не можуть підключитися — дивіться логи і конфіг клієнта, а не стан сервісу.

Рішення: Якщо не active — поводьтесь як з відмовою: відновіть конфіг, перевірте сертифікати/ключі та підтвердьте правила фаєрволу.

Швидкий плейбук діагностики

Це плейбук на випадок «VPN підключено, але я не можу RDP/SSH» і вам потрібні відповіді до того, як охолоне кава.

Перше: доведіть, що VPN справді підключений і обмінюється трафіком

• Перевірте, що інтерфейс існує і має IP (ip -brief addr).
• Перевірте хендшейк (WireGuard: wg show; OpenVPN: статус сервісу + логи).
• Перевірте, чи зростають лічильники передачі під час спроби зʼєднання.

Якщо хендшейк мертвий: дивіться досяжність до кінцевої точки VPN (фаєрвол, NAT, UDP заблоковано, неправильний порт).

Друге: перевірте маршрути обома напрямками

• З клієнта: ip route get <target> має вказувати на використання VPN-інтерфейсу.
• З VPN-шлюзу: підтвердьте, що він може маршрутизувати до цільової підмережі.
• З внутрішнього маршрутизатора: переконайтесь, що є зворотний маршрут до підмережі VPN (або ви навмисно використовуєте NAT).

Якщо ви бачите SYN, але немає SYN-ACK: зворотна маршрутизація або фаєрвол на віддаленому боці. Якщо ви бачите SYN-ACK на wg0, але клієнт все ще тайм-аутиться — можливо, проблеми з MTU або локальним фаєрволом.

Третє: перевірте, що сервіс доступний і слухає там, де ви думаєте

• Перевірка портів: nc -vz host 22 / nc -vz host 3389.
• На цілі: підтвердьте адресу прослуховування (ss -lntp на Linux; стан Windows Firewall/сервісу на Windows).
• Переконайтесь, що фаєрвол хоста дозволяє трафік з CIDR VPN.

Четверте: ізолюйте вузькі місця продуктивності (затримка, MTU, DNS)

• Затримка: ping або TCP-час підключення, потім traceroute.
• MTU/MSS: симптоми — «підключається, але зависає» або «чорний екран RDP».
• DNS: якщо імʼя не резолвиться, але IP працює — виправте split-DNS або налаштуйте внутрішні резолвери.

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

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

Симптом: VPN показує, що підключено; ви можете пінгувати VPN-шлюз, але не внутрішні хости.

Корінна причина: Відсутні маршрути (AllowedIPs занадто вузькі або внутрішні маршрутизатори не знають підмережу VPN).

Виправлення: Додайте маршрути до внутрішніх підмереж у конфіг клієнта VPN і додайте зворотний маршрут на внутрішніх маршрутизаторах (переважно) або NAT на шлюзі (тимчасово).

2) «SSH працює до деяких хостів, але не до інших, випадково.»

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

Корінна причина: Перекривання IP-діапазонів (VPN пул стикається з внутрішніми діапазонами) або асиметрична маршрутизація через кілька виходів.

Виправлення: Переназначте VPN-пул на неперекриваючийся діапазон; забезпечте симетрію маршрутизації або використайте політичну маршрутизацію на шлюзі.

3) «RDP підключається, потім чорний екран / зависає.»

Симптом: TCP 3389 доступний, але сесія зависає.

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

Виправлення: Встановіть консервативний MTU тунелю; обмежте MSS на шлюзі; уникайте TCP-over-TCP тунелювання, якщо це можливо.

4) «Ми відкрили лише порт VPN; все одно скомпрометували.»

Симптом: Єдиний публічний порт — VPN, проте зловмисник потрапив всередину.

Корінна причина: Слабка аутентифікація VPN (без MFA), витік ключів, спільні акаунти або скомпрометований кінцевий пристрій з валідними обліковими даними.

Виправлення: Вимагайте MFA, регулярно міняйте ключі/сертифікати, швидко відкликайте peers, вимагайте керовані пристрої та обмежуйте доступ VPN-клієнтів.

5) «DNS працює для інтернету, але внутрішні імена не резолвяться через VPN.»

Симптом: Можна SSH за IP, але не за іменем; внутрішні імена не резолвяться.

Корінна причина: Split-DNS не налаштовано; VPN не штовхає внутрішній резолвер або search-домени.

Виправлення: Надавайте внутрішні DNS-сервери і search-домени через конфіг VPN або політику клієнта. Не покладайтеся на ручні hosts-файли.

6) «Продуктивність жахлива тільки через VPN.»

Симптом: Висока затримка, рваний RDP, повільний SCP.

Корінна причина: Hairpin-маршрутизація (усі пакети йдуть через Головний офіс), перевантажений CPU шлюзу, неправильні очікування апаратного прискорення або втрата пакетів на UDP-шляху.

Виправлення: Використовуйте split tunneling обережно для непотрібного трафіку, додайте регіональні шлюзи, моніторте CPU шлюзів і перевіряйте втрати пакетів за допомогою tcpdump.

7) «Після того як ми «загартували» SSH, автоматизація зламалася.»

Симптом: CI/CD завдання не в змозі SSH після зміни безпеки.

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

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

8) «Доступ постачальника залишається постійним.»

Симптом: Старі VPN-акаунти постачальників працюють місяцями.

Корінна причина: Немає процесу відключення; доступ надається винятком і ніколи не переглядається.

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

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

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

Середня компанія перемістила легасі додаток бухгалтерії в хостинг. Операційна команда була горда: немає публічного RDP, немає публічного SSH, лише VPN. Вони зробили правильно — переважно. Потім прийшла платіжна неділя, і RDP-сесії почали відвалюватися кожні кілька хвилин.

Припущення було простим і хибним: «якщо VPN підключено, мережевий шлях в порядку». Команда ганяла перевірки Windows Update, налаштувань RDP і ноутбуків користувачів. Хтось навіть запропонував збільшити таймаути RDP — чудовий спосіб впевнено втрачати час.

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

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

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

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

Перший тиждень був нормальний. Потім регіональний офіс став скаржитися, що передача файлів і RDP — повільні. Не просто повільні — «липкі», ривкові і непередбачувані. Пакетні дампи показали повторні відправлення і блокування через head-of-line.

Вони побудували TCP-over-TCP: TCP-тунель, що несе TCP-додатки. Коли є втрата, TCP намагається відновити; внутрішній TCP теж намагається. Механізми відновлення борються, і користувачі отримують слайд-шоу.

Виправлення — повернутися до UDP для VPN, де це можливо, і залишити TCP/443 як останній засіб. Продуктивність стабілізувалася, а «оптимізація» була тихо видалена з діаграми архітектури.

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

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

Одного дня з автомобіля вкрали ноутбук інженера. Ноутбук був зашифрований, але команда реагування припустила найгірше: пристрій може бути скомпрометований. Питання було: «Що цей пристрій може зараз дістати?»

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

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

Жарт №2: Єдина річ, що ще наполегливіша за атакувальників — інтерн, який вивчив перенаправлення портів учора.

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

План A: Розумний стандарт (VPN + маршрутизований доступ + обмежені підмережі)

1. Виберіть неперекриваючийся CIDR для VPN (приклад: 10.42.0.0/24). Запишіть його. Ставтесь до нього як до API-контракту.
2. Розгорніть VPN-шлюз(и) з фаєрволом за замовчуванням deny. Публічно відкривайте лише порт VPN.
3. Увімкніть MFA для доступу до VPN. Якщо ваш VPN-продукт не підтримує MFA — це ваша заявка на зміну.
4. Визначте доступ за ролями: адміністратори — до підмереж управління; підтримка — до обмежених кінцевих точок; постачальники — тимчасовий доступ до конкретних хостів.
5. Поширюйте внутрішній DNS на клієнти VPN і налаштуйте split-DNS за потреби.
6. Додайте зворотні маршрути на внутрішніх маршрутизаторах для CIDR VPN через VPN-шлюз. Уникайте NAT, якщо це можливо.
7. Привʼяжіть SSH/RDP до внутрішніх інтерфейсів і налаштуйте фаєрвол хостів, щоб дозволяти лише VPN CIDR або jump host.
8. Централізуйте логи: логи аутентифікації VPN, журнали Windows, SSH-логи. Налаштуйте алерти на підозрілу активність.
9. Протестуйте з чистого клієнта: новий VPN-профіль, перевірте маршрути, перевірте порти і аутентифікацію.
10. Документуйте процедуру «break glass»: хто може отримати екстрений доступ, як він затверджується і як його відкликати.

План B: Додайте jump host для суворішого контролю

1. Користувачі заходять по VPN, але можуть досягати лише підмережі jump host.
2. Jump host повторно вимагає MFA/SSO, з суворим логуванням і записом сесій, якщо можливо.
3. З jump host дозволяйте SSH/RDP до цілей на основі членства в групах.
4. Забороніть прямі маршрути клієнт→продакшн. Ні «виняткам для мене». Винятки породжують культуру.

План C: Доступ постачальників без хаосу

1. Створюйте VPN-профілі для постачальників з тимчасовими лімітами і вузькими AllowedIPs.
2. Примушуйте доступ через jump host з записом сесій.
3. Вимикайте split tunneling для профілів постачальників, якщо можете; принаймні блокуйте доступ до внутрішніх ресурсів, що не потрібні.
4. Регулярно переглядайте доступ постачальників; відкликайте при завершенні контракту автоматично.

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

1) Чи достатньо VPN, чи треба все одно укріплювати SSH/RDP?

Укріплюйте в будь-якому разі. VPN знижує експозицію; він не усуває ризик інсайдерів, скомпрометованих кінцевих пристроїв або латерального руху. Трактуйте VPN як ворота, а не як магічний щит.

2) Чи варто вимкнути split tunneling?

За замовчуванням вимикайте його для адміністративних профілів. Якщо вимушені увімкнути split tunneling — обмежте доступ до внутрішніх підмереж і уважно моніторьте DNS. Більшість інцидентів із split tunneling повʼязані зі split-brain DNS.

3) Що краще: VPN чи bastion host?

Для невеликих команд VPN-only підходить, якщо доступ до підмереж обмежено. Для вищого рівня гарантій використовуйте обидва: VPN для входу в приватну мережу, bastion/jump host для контролю та запису подальших дій.

4) Чому не просто змінити порт SSH на нестандартний і вважати справу зробленою?

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

5) Можу тримати RDP/SSH відкритими, але обмежувати за IP allowlist?

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

6) Яка найпоширеніша причина «VPN підключено, але нічого не працює»?

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

7) Як діяти при екстреному доступі, якщо VPN впав?

Спроєктуйте це заздалегідь: out-of-band консоль, окрема панель управління або другий VPN-шлюз/провайдер. Не тримайте публічний SSH/RDP «на випадок» — так «на випадок» перетворюється на «нас щойно зламали».

8) Чи безпечний WireGuard для підприємства?

Так, якщо керувати ключами і доступом правильно. Його простота — операційна перевага. Питання підприємства зазвичай про життєвий цикл: onboarding, offboarding, аудит і політики.

9) А як щодо мереж зберігання/адміністрування — особливі застереження?

Так: доступ до систем зберігання має високий імпакт. Тримайте інтерфейси управління на виділених підмережах, доступних лише через VPN і бажано через jump host. Аудитуйте інтенсивно.

10) Як довести, що ми більше не експортуємо RDP/SSH?

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

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

1. Інвентаризація експозицій: знайдіть всі публічно доступні SSH/RDP і закрийте їх. Якщо не можете закрити одразу — обмежте доступ за джерелом і додайте MFA, поки мігруєте.
2. Запустіть VPN-пілот: оберіть неперекриваючийся CIDR, розгорніть один шлюз, підключіть двох адміністраторів, маршрутуйте до однієї підмережі управління.
3. Виправте маршрути правильно: додавайте зворотні маршрути на внутрішніх маршрутизаторах, замість покладання на NAT, якщо це можливо і документовано.
4. Укріпіть цілі: привʼяжіть SSH/RDP до внутрішніх інтерфейсів, вимагайте ключі/NLA і обмежуйте фаєрволи хостів до VPN CIDR.
5. Напишіть рукбук: скопіюйте розділ «Швидкий плейбук діагностики» у ваші on-call документи і додайте конкретні IP-діапазони та інтерфейси з вашого середовища.
6. Прискорте відкликання: потренуйтеся видаляти peer/користувача VPN і перевіряти, що вони відключені. Якщо відкликання займає годину — це не відкликання, а зустріч.

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