RDP між офісами без відкритих портів: безпечна конфігурація «тільки RDP через VPN»

Що насправді означає «тільки RDP через VPN»

«Тільки RDP через VPN» — не модне гасло. Це набір конкретних контролів:

• Жодного публічного відкриття RDP. Не «безпека через невідомість» з іншим портом. Не «тільки біллістовані IP» на WAN. Просто ні.
• RDP слухає лише на внутрішніх інтерфейсах (або, практично, правила брандмауера гарантують, що він доступний лише з підмережі VPN).
• VPN — єдиний шлях вхідного трафіку з Офісу A до Офісу B для трафіку управління.
• Контроль ідентичності та пристроїв на VPN, бажано MFA і пристрої, прив’язані до сертифікатів.
• Логи, які можна використовувати. Не просто галочка. Реальна телеметрія, що показує, хто підключався, звідки і чи була невдала спроба.

Чому «просто відкрити 3389» — професійно принизливо

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

Модель загрози в одному абзаці

Головні ризики — це credential stuffing, brute force спроби, експлуатація вразливостей, пов’язаних з RDP, латеральний рух після проникнення та проста помилка конфігурації.
VPN не робить RDP «безпечним». Він робить RDP приватним, а потім ви зміцнюєте RDP та навколишню мережу, щоб компрометація не стала подією на рівні всієї компанії.

Одна цитата, яку варто тримати на липкій нотатці:
«Сподівання — це не стратегія.» — Ген. Гордон Р. Салліван

Жарт №1: Виставити 3389 в інтернет — як залишити двері офісу відкритими, бо ви купили кращий підніжок. Злодії в захваті від оновлення.

Цікаві факти та трохи історії

Розуміння контексту допомагає приймати кращі компроміси. Ось кілька конкретних пунктів, які часто дивують навіть ІТ-команди:

1. RDP існує з кінця 1990-х. Він виріс із епохи Terminal Services від Microsoft, задовго до того, як «zero trust» став презентаційним мемом.
2. TCP/3389 став магнітом для сканування через свою передбачуваність. Автоматизація атак живиться дефолтами. Багато «фонового шуму» інтернету — це просто боти, що постукають у двері.
3. Network Level Authentication (NLA) змінила правила гри. NLA вимагає автентифікацію до створення повної сесії робочого столу, зменшуючи витрати ресурсів і деякі класи атак на етапі доавтентифікації.
4. Крадіжка облікових даних, а не баги протоколу, — звичний шлях. У багатьох реальних інцидентах RDP — просто зручна точка входу після вгадування або повторного використання паролів.
5. «Безпека» RDP і «зручність» постійно конкурують. Вимкнення NLA або дозвіл старих налаштувань TLS часто трапляється тому, що «одна програма постачальника не працює», і так починається руйнація.
6. VPNи перейшли від апаратних пристроїв до програмно-визначених тунелів. Раніше були IPsec бокси; тепер WireGuard і сучасні стеки IKEv2 популярні, бо операційні команди хочуть простіші, спостережувані конфігурації.
7. «Зміна порту RDP» — не справжній захист. Це зменшує випадковий шум, але не зупинить цілеспрямованих нападників і може зламати інструменти та аудит.
8. Продуктивність RDP сильно залежить від затримки та втрат пакетів. Пропускна здатність важлива, але 30–60 мс затримки і невеликі втрати можуть зробити сесію відчутною як набирати текст через пудинг.

Вибір архітектури: site-to-site чи віддалений доступ

Опція A: Site-to-site VPN між офісами (рекомендовано для «офіс → офіс» RDP)

Якщо вимога — «з Офісу A до серверів в Офісі B», site-to-site VPN — найчистіше рішення. Він створює контрольовану приватну домену маршрутизації між двома мережами.
Ви можете дозволити RDP лише з конкретних вихідних підмереж або через jump host.

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

Опція B: VPN віддаленого доступу для окремих користувачів

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

Опція C: RDP Gateway (корисно, але не «без відкритих портів»)

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

Субʼєктивна рекомендація

Для «між офісами» побудуйте site-to-site VPN і застосуйте правило «RDP тільки з підмережі VPN» на брандмауерах Windows.
Додайте jump host (а краще — два) і змусьте адміністраторів RDP на jump host, а вже звідти — далі. Це дозволяє тримати RDP доступним при мінімальному радіусі ураження.

Рекомендований базовий рівень: WireGuard site-to-site зі суворими allowlist для RDP

Зразкова топологія мережі

• LAN Офіс A: 10.10.0.0/16
• LAN Офіс B: 10.20.0.0/16
• Підмережа тунелю WireGuard: 10.99.0.0/24
• VPN-шлюз Офіс A: office-a-vpn (Linux)
• VPN-шлюз Офіс B: office-b-vpn (Linux)
• Jump host Windows в Офіс B: jump-b01 (10.20.10.10)
• Цілі RDP в Офіс B: DC / прикладні сервери за потреби

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

Тримайте тунель вузьким. Маршрузуйте лише те, що потрібно. Уникайте «0.0.0.0/0 через тунель» для site-to-site, якщо вам не подобається пояснювати фінансам, чому дзвінки Teams звучать як підводний човен.

Чиста модель:

• Офіс A маршрутує 10.20.0.0/16 через тунель.
• Офіс B маршрутує 10.10.0.0/16 через тунель.
• Брандмауер Windows в Офіс B дозволяє TCP/3389 лише з 10.10.0.0/16 (або, краще, лише з підмережі jump host офісу A).

NAT: уникайте, якщо не потрібно

NAT у site-to-site VPN створює майбутні таємниці. Він може бути необхідним при перекритті підмереж (про це пізніше), але якщо можна уникнути — робіть це.
Маршрувані VPN з різними підмережами простіші для розуміння, налагодження та аудиту.

Скелет конфігурації WireGuard

WireGuard простий навмисно. Це — перевага. Більшість збоїв не у WireGuard; вони в маршрутизації та брандмауерах навколо нього.

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <redacted>

# Route Office B LAN through the tunnel
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT

[Peer]
PublicKey = <redacted>
AllowedIPs = 10.99.0.2/32, 10.20.0.0/16
PersistentKeepalive = 25

Зверніть увагу, що важливо: AllowedIPs — це і маршрутизація, і політика. Якщо випадково дозволити 0.0.0.0/0, ви тільки що сказали шлюзу приймати «усе» від цього пірінга.
В лабораторії це може бути нормально. У виробництві — інцидент, що чекає на нудного інтерна з Wireshark.

Зміцнення RDP: ті частини, які зупиняють інциденти

1) Обмежте, хто може дістатися до RDP (мережеві контролі)

Не покладайтеся на «надійні паролі» як перший барʼєр. Перший барʼєр — це: лише підмережа VPN (або jump host) може навіть ініціювати TCP-руклост.
RDP, до якого не можна дістатися, не можна брутфорсити.

2) Вимагайте NLA і сучасного шифрування

Увімкніть NLA. Примусьте TLS. Вимкніть застарілі рівні безпеки, якщо можете. Так, знайдеться один древній продукт постачальника, що скрипить. Ваше завдання — зробити це їхньою проблемою, а не вашим порушенням безпеки.

3) Використовуйте jump hosts, а не «RDP скрізь»

Створіть острів управління: один або два захищені Windows-хоста, які є єдиними системами, дозволеними для RDP до серверів.
Адміни RDP на jump host через VPN, а звідти — до внутрішніх цілей.

Це зменшує експозицію облікових даних (менше кінцевих точок у доменних адміністративних контекстах) і робить логи концентрованішими та кориснішими.

4) Ідентичність: мінімальні права, MFA і здорові робочі процеси для адміністраторів

MFA має бути на VPN. Якщо ваш VPN не підтримує MFA — замініть його або поставте попередній шар, що вимагає ідентифікацію.
У Windows використовуйте окремі адміністраторські облікові записи, видаляйте непотрібні членства в локальній групі Administrators і ставтеся до доступу RDP як до контрольованого дозволу, а не до права за замовчуванням.

5) Логи та алерти: вирішіть, що ви будете розслідувати

Ви хочете знати:

• події підняття/зниження peer VPN і коливання handshakes;
• успішні та невдалі входи Windows через RDP (logon type 10);
• відмови брандмауера для 3389 (щоб бачити помилкову маршрутизацію).

Зберігайте це дієвим. Логування всього без зберігання і перегляду — це просто дороге забування.

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

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

Завдання 1: Підтвердьте стан інтерфейсу WireGuard

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

peer: ppppppppppppppppppppppppppppppppppppppppp=
  endpoint: 203.0.113.20:51820
  allowed ips: 10.99.0.2/32, 10.20.0.0/16
  latest handshake: 34 seconds ago
  transfer: 1.28 GiB received, 2.02 GiB sent
  persistent keepalive: every 25 seconds

Значення: Handshake свіжий; зона маршрутизації обмежена IP тунелю + LAN Офісу B. Лічильники передачі показують реальний трафік.

Рішення: Якщо «latest handshake» — хвилини/години тому, виправте досяжність (UDP, NAT, IP кінця) перед тим, як торкатися RDP.

Завдання 2: Перевірте маршрути ядра для віддаленої LAN

cr0x@server:~$ ip route show | grep 10.20.0.0
10.20.0.0/16 dev wg0 proto static scope link

Значення: Шлюз відправляє трафік Офісу B у тунель, а не до дефолтного шлюзу.

Рішення: Якщо цього маршруту немає, RDP ніколи не дійде. Виправте WireGuard AllowedIPs або додайте явні маршрути.

Завдання 3: Підтвердьте, що форвардинг увімкнений (site-to-site вимагає цього)

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

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

Рішення: Якщо це 0, увімкніть форвардинг; інакше ваш VPN — дорога прикраса.

Завдання 4: Перевірте правила брандмауера на VPN-шлюзі (шлях форвардингу)

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i wg0 -o eth0 -d 10.20.0.0/16 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -s 10.20.0.0/16 -j ACCEPT

Значення: За замовчуванням DROP з явним дозволом між wg0 і LAN. Так виглядає «сувора маршрутизація».

Рішення: Якщо FORWARD за замовчуванням DROP без allow-правил, ваш handshake буде вгору, але пакети не проходитимуть. Додайте специфічні правила, а не «ACCEPT all».

Завдання 5: Перевірте, що NAT НЕ відбувається (якщо ви цього не планували)

cr0x@server:~$ sudo iptables -t nat -S | head
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT

Значення: Немає правил NAT. Добре для чистої маршрутизації і точних логів.

Рішення: Якщо ви бачите MASQUERADE-правила для VPN-трафіку, підтвердіть, чи це потрібно (перекриття підмереж). Якщо не потрібно — видаліть, щоб уникнути плутанини «хто цей IP» пізніше.

Завдання 6: Перевірте досяжність порту RDP з боку Офісу A

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

Значення: Мережевий шлях і брандмауер Windows дозволяють TCP/3389 з вашого джерела.

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

Завдання 7: Підтвердьте, що RDP не доступний з публічного інтернету (негативний тест)

cr0x@server:~$ nc -vz 198.51.100.45 3389
nc: connect to 198.51.100.45 port 3389 (tcp) failed: Connection timed out

Значення: Добре. Публічна IP-адреса не відповідає на 3389. Таймаути зазвичай кращі за «refused», бо менше інформації розкривають.

Рішення: Якщо підключення вдається — стоп. Ви відкрили RDP. Закрийте його на зовнішньому брандмауері і перевірте, чи немає port-forward або правила в cloud security group, що його витікають.

Завдання 8: Виміряйте затримку і втрати в тунелі (відчуття RDP залежить від цього)

cr0x@server:~$ ping -c 10 10.20.10.10
PING 10.20.10.10 (10.20.10.10) 56(84) bytes of data.
64 bytes from 10.20.10.10: icmp_seq=1 ttl=127 time=23.9 ms
64 bytes from 10.20.10.10: icmp_seq=2 ttl=127 time=24.1 ms
64 bytes from 10.20.10.10: icmp_seq=3 ttl=127 time=24.3 ms
64 bytes from 10.20.10.10: icmp_seq=4 ttl=127 time=24.0 ms
64 bytes from 10.20.10.10: icmp_seq=5 ttl=127 time=26.8 ms
64 bytes from 10.20.10.10: icmp_seq=6 ttl=127 time=24.2 ms
64 bytes from 10.20.10.10: icmp_seq=7 ttl=127 time=24.1 ms
64 bytes from 10.20.10.10: icmp_seq=8 ttl=127 time=24.3 ms
64 bytes from 10.20.10.10: icmp_seq=9 ttl=127 time=24.0 ms
64 bytes from 10.20.10.10: icmp_seq=10 ttl=127 time=24.4 ms

--- 10.20.10.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9018ms
rtt min/avg/max/mdev = 23.9/24.6/26.8/0.8 ms

Значення: 25 ms з 0% втратою зазвичай працює добре для RDP.

Рішення: Якщо ви бачите втрати > 1% або стрибки jitter, виправляйте мережу перед тим, як звинувачувати налаштування RDP.

Завдання 9: Перевірте проблеми MTU (поширено для VPN)

cr0x@server:~$ ping -c 3 -M do -s 1372 10.20.10.10
PING 10.20.10.10 (10.20.10.10) 1372(1400) bytes of data.
1372 bytes from 10.20.10.10: icmp_seq=1 ttl=127 time=25.1 ms
1372 bytes from 10.20.10.10: icmp_seq=2 ttl=127 time=25.3 ms
1372 bytes from 10.20.10.10: icmp_seq=3 ttl=127 time=25.2 ms

--- 10.20.10.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.1/25.2/25.3/0.1 ms

Значення: Path MTU підтримує ~1400-байтні фрейми. Це зазвичай безпечно для WireGuard.

Рішення: Якщо це не проходить, але менші розміри працюють — зменшіть MTU WireGuard (наприклад, до 1380) і повторно протестуйте; MTU blackholes викликають «рандомні зависання» RDP.

Завдання 10: Підтвердьте, що Windows слухає на 3389 (з Windows-хоста через SSH або консоль)

cr0x@server:~$ ssh admin@10.20.10.10 "netstat -ano | findstr :3389"
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1140
  TCP    [::]:3389              [::]:0                 LISTENING       1140

Значення: TermService слухає на IPv4 та IPv6, PID 1140.

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

Завдання 11: Перевірте, що брандмауер Windows дозволяє RDP лише з VPN/офісної підмережі

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter | Select-Object -First 5\""
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16
RemoteAddress : 10.10.0.0/16

Значення: Правила RDP обмежені підмережею Офісу A. Це точка застосування «тільки через VPN», яка найчастіше цікавить аудитора.

Рішення: Якщо ви бачите RemoteAddress : Any, звузьте. «Any» врешті-решт стане «anyone» через майбутню помилку маршрутизації.

Завдання 12: Переконайтеся, що NLA увімкнено

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"(Get-ItemProperty -Path 'HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp' -Name UserAuthentication).UserAuthentication\""
1

Значення: 1 означає, що NLA обовʼязковий.

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

Завдання 13: Перевірте журнали подій Windows для входів RDP (успішні/невдалі)

cr0x@server:~$ ssh admin@10.20.10.10 "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 3 | Select-Object TimeCreated, Id, Message\""
TimeCreated            Id Message
-----------            -- -------
12/28/2025 08:34:11 4625 An account failed to log on.
12/28/2025 08:32:07 4625 An account failed to log on.
12/28/2025 08:29:52 4625 An account failed to log on.

Значення: Є невдалі входи. Далі корелюйте IP джерела, імʼя облікового запису та тип входу. Якщо вони прийшли зсередини VPN, можливо, скомпрометовано облікові дані або доступ надто широкий.

Рішення: Якщо бачите сплески — звузьте доступ VPN, увімкніть MFA і розгляньте політику блокування облікових записів (обережно — блокування можна використати як DoS).

Завдання 14: Підтвердьте, що VPN — єдиний шлях (перевірка маршрутизації)

cr0x@server:~$ traceroute -n 10.20.10.10 | head -n 6
traceroute to 10.20.10.10 (10.20.10.10), 30 hops max, 60 byte packets
 1  10.99.0.1  1.032 ms  0.981 ms  0.965 ms
 2  10.20.0.1  22.412 ms  22.376 ms  22.341 ms
 3  10.20.10.10  23.918 ms  23.882 ms  23.851 ms

Значення: Трафік входить у тунель і потрапляє в Офіс B. Жодних дивних обʼїздів через інтернет.

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

Завдання 15: Дивіться живий трафік, щоб підтвердити, що потоки RDP йдуть через тунель

cr0x@server:~$ sudo tcpdump -ni wg0 tcp port 3389 -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
08:41:22.112233 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [S], seq 12223344, win 64240, options [mss 1360,sackOK,TS val 111 ecr 0], length 0
08:41:22.134455 IP 10.20.10.10.3389 > 10.10.50.25.51432: Flags [S.], seq 99887766, ack 12223345, win 65160, options [mss 1360,sackOK,TS val 222 ecr 111], length 0
08:41:22.134900 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [.], ack 1, win 64240, options [TS val 112 ecr 222], length 0
08:41:22.145000 IP 10.10.50.25.51432 > 10.20.10.10.3389: Flags [P.], length 64
08:41:22.150000 IP 10.20.10.10.3389 > 10.10.50.25.51432: Flags [P.], length 128

Значення: SYN/SYN-ACK на wg0 доводить, що сесія проходить тунельним інтерфейсом VPN.

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

Завдання 16: Визначте вузьке місце на Linux-шлюзі (CPU/interrupt pressure)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 08:44:01 up 37 days,  2:11,  2 users,  load average: 0.62, 0.71, 0.68
Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.2 us,  2.1 sy,  0.0 ni, 89.9 id,  0.1 wa,  0.0 hi,  0.7 si,  0.0 st
MiB Mem :   3932.1 total,    812.5 free,    701.1 used,   2418.5 buff/cache
MiB Swap:   1024.0 total,   1024.0 free,      0.0 used.   2978.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1890 root      20   0  131456  24192  10432 S   6.0   0.6  18:22.11 wg-quick
 1022 root      20   0       0      0      0 S   1.3   0.0  12:10.23 ksoftirqd/0

Значення: Достатньо вільного CPU; немає ознак, що шлюз є вузьким місцем.

Рішення: Якщо CPU завантажений або softirq високий, можливо, ви недообладнані або маєте проблеми з драйвером NIC. Масштабуйте шлюз або налаштуйте offload-опції з обережністю (і тестом).

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

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

Коли хтось каже «RDP не працює», не починайте з перевстановлення Remote Desktop Services або перезавантаження фаєрвола як ритуалу.
Дотримуйтесь чіткої послідовності, що знайде вузьке місце за кілька хвилин.

Спочатку: доведіть, що шлях VPN живий

1. Перевірте handshake тунелю. Якщо тунель не піднятий, нічого іншого не має значення. Використовуйте wg show (Завдання 1) або ваш інструмент статусу IPsec.
2. Перевірте маршрути. Підтвердіть, що віддалена LAN маршрутується в тунель (Завдання 2). Неправильні маршрути виглядають точно як «RDP не працює».
3. Перевірте форвардинг + фаєрвол на шлюзах. Якщо тунель вгору, але форвардинг ріже трафік, ви побачите handshakes, але без сесій (Завдання 3–4).

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

1. TCP-тест до 3389. Використовуйте nc -vz (Завдання 6). Таймаут проти refused каже, куди дивитися.
2. Підтвердіть, що служба слухає. netstat на цільовому хості (Завдання 10). Немає слушача — немає RDP.
3. Підтвердіть скопінг фаєрвола Windows. Переконайтеся, що правила RDP обмежені VPN/офісними діапазонами (Завдання 11). Надто вузьке правило так само погане, як надто широке — просто з меншою гучною історією.

По-третє: діагностика «повільно» через фізику мережі, а не відчуття

1. Ping і втрати/jitter. Завдання 8. Втрата валить відчуття RDP як втрачені клавіші.
2. MTU-тест. Завдання 9. MTU blackholes викликають переривчасті зависання, які користувачі описують як «іноді зависає».
3. Спостерігайте живий трафік тунелю. Завдання 15. Якщо трафік не на wg0, користувач може не використовувати запланований шлях.
4. Перевірте навантаження шлюзу. Завдання 16. Шифрування і форвардинг — реальна робота; не запускайте це на забутому VM з 1 vCPU і сподівайтесь на диво.

Що робити, коли тунель піднятий, але RDP все одно не працює

На цьому етапі зосередьтеся на контролях зі сторони Windows:

• NLA увімкнений (Завдання 12)
• Права облікових записів і членства в групах (Remote Desktop Users проти локальних Administrators)
• Журнали подій для невдалих спроб (Завдання 13)
• Правильність DNS (клієнти підключаються до правильної IP)

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

1) Інцидент через хибне припущення: «всередині — значить безпечно»

Середня компанія мала два офіси і site-to-site VPN. Вони зробили «правильно», не виставляючи RDP публічно.
Вони також зробили «класично», дозволивши RDP з «будь-якої внутрішньої підмережі», бо так було простіше, ніж керувати правилами.

Хибне припущення було тонким: вони трактували VPN як магічне перетворення обох боків на довірені.
Насправді в Офісі A було багато незадокументованих пристроїв: ноутбук постачальника, що приходив і йшов, кілька кіосків і Wi‑Fi, який був не так сегментований, як вважали.

Спроба credential stuffing проти одного слабкого локального адміністративного пароля вдалася — не тому, що RDP був публічний, а тому, що його можна було дістати з багатьох внутрішніх місць.
Після цього зловмисник отримав точку опори на одному сервері в Офісі B, запитав AD, розпилив облікові дані і перемістився латерально.

Постмортем не про екзотичні вразливості. Він про досяжність і межі довіри.
Вони виправили це, впровадивши jump hosts і звузивши правила брандмауера RDP лише до підмережі jump host, а також увімкнули MFA для VPN віддаленого доступу для адміністраторів.
VPN лишився. Модель довіри змінилася.

2) Оптимізація, що дала зворотний ефект: «Давайте розділимо тунелювання для продуктивності»

Інша організація мала справжні скарги: RDP сесії відчувалися повільно в пікові години.
Хтось запропонував split tunneling для всієї офісної мережі: інтернет-трафік залишити локальним, а корпоративні підмережі — через VPN. На папері звучить розумно.

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

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

Виправлення не було «ніколи split tunneling». Це було: чітко визначити політику, забезпечити DNS і видалити інструменти обходу.
Вони впровадили умовний DNS з ясними правилами, обмежили менеджмент-трафік до VLAN jump host і додали алерти, коли RDP надходив з поза очікуваних підмереж.
Продуктивність покращилась, але лише після відновлення детермінізму.

3) Нудна, але правильна практика, що врятувала день: «Одне правило, одне джерело, одна мета»

Компанія фінансового спрямування діяла жорстко. Мережева команда наполягала на надто специфічних правилах брандмауера:
RDP до серверів дозволявся лише з двох jump hosts, а ці jump hosts були доступні тільки через VPN.

Здавалось це бюрократією. Люди скаржилися, бо не могли просто RDP з робочих столів «на пʼять хвилин».
Команда безпеки лише стверджувала ту саму фразу: «Доступ адміністрування має єдиний контролюючий вузол».

Потім ноутбук підрядника заразився поза офісом і потім підключився до офісної мережі. Шкідливе ПО спробувало звичну стратегію: сканувати, поширюватися, брутфорсити.
Воно багато чого побачило, але не могло дістатися RDP на серверах, бо правила брандмауера Windows були звужені лише до jump hosts.

Інцидент все одно потребував роботи — ізоляція, перевстановлення, скидання облікових даних — але ніколи не став захопленням серверів.
«Нудне правило» не зупинило зараження ноутбука. Воно завадило зараженню стати катастрофою для бізнесу.
Це та сама нудна практика, яка вам потрібна.

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

1) Симптом: VPN показує «підключено», але RDP таймаутиться

Корінь проблеми: Тунель піднятий, але форвардинг або правила брандмауера відкидають трафік між wg0 і LAN (або IP forwarding вимкнений).

Виправлення: Підтвердьте маршрути (Завдання 2), увімкніть форвардинг (Завдання 3) і додайте явні дозволи FORWARD (Завдання 4). Перевірте з tcpdump (Завдання 15).

2) Симптом: RDP працює з деяких ПК, але не з інших

Корінь проблеми: Існують кілька шляхів (split tunnel, інший VPN, застарілий DNS або прямий інтернет-шлях). Деякі клієнти фактично не використовують site-to-site VPN.

Виправлення: Використайте traceroute (Завдання 14) з непрацюючих і працюючих клієнтів, виправте маршрути/DNS і видаліть інструменти обходу. Обмежте доступ брандмауером до відомих підмереж.

3) Симптом: RDP підключається, але випадково зависає на секунди

Корінь проблеми: MTU blackhole або періодична втрата пакетів на шляху тунелю.

Виправлення: Запустіть MTU-проби (Завдання 9) і перевірки втрат/jitter (Завдання 8). Зменшіть MTU WireGuard, виправте WAN-проблеми або пріоритезуйте VPN-трафік на edge.

4) Симптом: Користувачі постійно отримують запити облікових даних, потім «The logon attempt failed»

Корінь проблеми: NLA + невідповідність політик, зсув часу, що впливає на Kerberos, або обмеження облікового запису. Іноді користувач використовує локальний обліковий запис, якому не дозволено RDP.

Виправлення: Перевірте статус NLA (Завдання 12), журнали подій (Завдання 13), синхронізацію часу і переконайтеся, що користувач у Remote Desktop Users (або еквівалент) і дозволений політикою.

5) Симптом: Після «посилення безпеки» ніхто не може більше RDP

Корінь проблеми: Remote address scope в правилах брандмауера Windows встановлено занадто вузько (не та підмережа), або ви відрізали самі jump hosts.

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

6) Симптом: RDP доступний з інтернету, незважаючи на «ми його не відкривали»

Корінь проблеми: Edge NAT/port-forward, правило cloud security group або модем провайдера з «корисним» форвардингом. Іноді другий фаєрвол робить неочікуваний UPnP.

Виправлення: Зробіть негативний тест ззовні (Завдання 7), а потім аудитуйте edge NAT і upstream-пристрої. Вимкніть UPnP. Розглядайте будь-яку публічну експозицію RDP як інцидент і замініть облікові дані.

7) Симптом: VPN стабільний, але продуктивність RDP жахлива лише у певні часи

Корінь проблеми: Bufferbloat або насичення WAN, або VPN-шлюз обмежений по CPU під навантаженням.

Виправлення: Перевірте навантаження шлюзу (Завдання 16), впровадьте QoS/traffic shaping на edge і забезпечте шлюзи запасом потужності. Не моріть шифрування на крихітній VM.

8) Симптом: RDP працює, але аудитори скаржаться «немає MFA»

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

Виправлення: Увімкніть MFA для автентифікації VPN, обмежте доступ VPN за групами і тримайте RDP доступним лише з VPN/jump hosts.

Контрольні списки / покроковий план

Покроково: побудувати «тільки RDP через VPN» між двома офісами

1. Перелічіть підмережі та виправте перекриття. Якщо обидва офіси використовують однаковий RFC1918 діапазон — вирішіть зараз, чи будете ви перенумеровувати або робити NAT. Перенумерація болісна один раз; NAT заплутує назавжди.
2. Виберіть тип VPN. Для двох фіксованих сайтів оберіть site-to-site (WireGuard або IPsec/IKEv2). Віддавайте перевагу тому, що ваша команда зможе оперувати о 3 ранку.
3. Визначте діапазон IP тунелю. Використайте невеликий /24 або /30, зарезервований для VPN-ендпоінтів (наприклад, 10.99.0.0/24).
4. Реалізуйте маршрутизацію. Додайте маршрути для віддалених LAN у тунель; уникайте тунелювання за замовчуванням, якщо це не потрібно.
5. Заблокуйте форвардинг на шлюзах. За замовчуванням DROP, потім дозволити лише необхідний трафік між сайтами (RDP до jump hosts, AD/LDAP якщо потрібно, моніторинг тощо).
6. Розгорніть jump host(и). Захистіть їх, патчуйте, моніторьте. Вони — ваша контрольна точка.
7. Звузьте правила брандмауера Windows. Дозвольте TCP/3389 лише з підмережі VPN або підмережі jump host. Для серверів краще «лише з jump hosts».
8. Увімкніть NLA і сучасний TLS. Не погоджуйтеся на древні клієнти; оновіть їх або ізолюйте.
9. Впровадьте MFA на доступі VPN. Зробіть VPN воротами. Також обмежте, які користувачі/групи можуть підключатися.
10. Централізуйте логи. Збирайте події VPN і журнали безпеки Windows, релевантні для RDP.
11. Виконайте негативні тести. Перевірте, що 3389 не доступний публічно. Перевірте, що RDP не працює без VPN.
12. Задокументуйте шлях. Запишіть очікувані IP джерел, IP цілей і дозволені порти. Майбутнє «ви» подякує сьогоднішньому «ви».

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

• Uptime тунелю VPN / свіжість handshake та їхні коливання
• Втрати пакетів / jitter між шлюзами
• Невдалі входи Windows (4625) зі сплесками типу входу 10
• Логи відмов брандмауера для 3389 з несподіваних джерел
• Відповідність патчам на jump hosts та RDP-цілях

Чекліст безпеки: що заборонити явно

• Жодних публічних входів на 3389, ніколи
• Жодного «Any» в RemoteAddress правилах брандмауера Windows
• Ніяких спільних адміністративних облікових записів для RDP
• Ніяких незадокументованих пристроїв з адміністративним доступом через VPN
• Жодних «тимчасових» виключень без дати закінчення і відповідального

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

1) Чи достатньо «тільки RDP через VPN», або потрібне ще й зміцнення RDP?

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

2) Що обрати: WireGuard чи IPsec для site-to-site?

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

3) Чи можна просто змінити порт RDP замість використання VPN?

Ні. Зміна порту зменшить випадкове сканування; вона не вирішує цілеспрямовані атаки, credential stuffing або дрейф конфігурації.
Якщо щось потрібно виставити публічно, виставте ідентифікаційно-орієнтовану фронтальну службу, а не сире RDP.

4) Чи потрібен нам jump host, якщо VPN уже обмежений?

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

5) Як найкраще обмежити RDP у Windows?

Скопуйте правила брандмауера Windows для «Remote Desktop» до довірених вихідних діапазонів (підмережа VPN або jump hosts).
Не покладайтеся виключно на edge-файєрволи; локальні правила запобігають випадковій експозиції через майбутні зміни маршрутизації.

6) Чому RDP відчувається повільним, хоча пропускна здатність в порядку?

RDP чутливий до затримки і втрат. Швидке посилання з jitter і втратою буде відчуватися гірше, ніж повільніше, але стабільніше.
Спершу перевірте ping втрати/jitter і MTU (Завдання 8 і 9).

7) Чи варто вмикати split tunneling?

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

8) Що робити, якщо обидва офіси використовують однакові підмережі (перекриття)?

Перекриття підмереж — класична прихована міна. Чисте вирішення — перенумерація одного сайту.
Якщо не можете — доведеться робити NAT у VPN і ретельно відображати адреси (наприклад, перекласти 192.168.1.0/24 однієї сторони у невідповідний віртуальний діапазон). Документуйте це агресивно і готуйтеся до додаткового часу на налагодження назавжди.

9) Як довести аудиторам, що RDP не виставлено публічно?

Надайте політику брандмауера (edge-правила показують відсутність inbound 3389), негативні тести зовні (Завдання 7) і скопінг брандмауера Windows (Завдання 11).
Аудитори люблять шарові контролі, бо вважають, що помилки трапляються. Вони праві.

10) Чи можна повністю відмовитись від RDP?

Іноді можна. Для адміністрування серверів PowerShell Remoting, Windows Admin Center або інструменти управління можуть зменшити потребу у інтерактивному RDP.
Але вам все одно знадобиться «break glass» інтерактивний шлях для аварій — просто тримайте його VPN-only і дуже звуженим.

Висновок: практичні наступні кроки

Найбезпечніша конфігурація «RDP між офісами» не хитра. Вона дисциплінована: site-to-site VPN, сувора маршрутизація, скопінг брандмауера Windows, jump hosts, MFA на VPN і логи, які ви дійсно читаєте.
Жодного відкритого 3389. Жодних вічних винятків. Жодних таємних шляхів.

Зробіть наступне, у порядку пріоритету:

1. Виконайте негативний тест зовні і підтвердіть, що публічний RDP вимкнений (Завдання 7).
2. Звузьте правила брандмауера Windows для RDP до VPN/jump джерел (Завдання 11) і перевірте досяжність (Завдання 6).
3. Впровадьте (або посильте) маршрутизацію site-to-site і правила форвардингу (Завдання 1–4).
4. Перевірте затримки/втрати і MTU, щоб уникнути квитків «іноді зависає» (Завдання 8–9).
5. Налаштуйте choke point: jump hosts, MFA і централізовані логи (Завдання 13 як початкова мітка).

Зробіть це нудним. І тримайте це нудним. Саме так продовжує працювати продакшн.