PPTP — пастка: чому його слід уникати і що використовувати натомість

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

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

Що таке PPTP насправді (і чому воно поводиться дивно)

PPTP означає Point-to-Point Tunneling Protocol. Він був розроблений для тунелювання PPP (Point-to-Point Protocol) поверх IP-мереж.
Думайте про припущення епохи модемів, перепаковані для корпоративних мереж: аутентифікація через методи PPP, потім обгортання фреймів у тунель
і маршрутизація їх так, ніби ви «в локальній мережі».

PPTP використовує дві окремі частини:

• TCP-канал керування на порту 1723 для налаштування та управління тунелем.
• інкапсуляцію GRE (IP-протокол 47) для фактичних тунельованих даних.

Ця деталь з GRE має операційне значення. PPTP — це не «просто TCP-порт». Це TCP-сесія плюс окрема не-TCP інкапсуляція, яку багато брандмауерів,
NAT-пристроїв і груп безпеки в хмарі обробляють погано. Коли хтось каже «ми відкрили 1723 і все одно не працює», вони не нещасливі.
Вони стикаються з особливістю дизайну протоколу.

Аутентифікація зазвичай здійснюється через MS-CHAPv2, а шифрування — якщо ввімкнене — через MPPE (Microsoft Point-to-Point Encryption), що
базується на RC4. Це не «сучасний крипто-стек». Це музейний експонат, який випадково отримав доступ до мережі.

Чому варто уникати PPTP у 2025 році

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

1) MS-CHAPv2 робить захоплення паролів і їх злам практичними

У розгортаннях PPTP часто використовують MS-CHAPv2. Обмін може бути зафіксований активним нападником (або в деяких середовищах — пасивним),
і ефективна безпека часто зводиться до пошуку одного ключа DES через структуру протоколу. Переклад: у найкращому випадку ваша безпека
залежить від пароля, який ніколи не призначався для протистояння офлайн-скрейкінгу в масштабі.

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

2) MPPE/RC4 не те місце, де ви хочете будувати історію конфіденційності

Навіть якщо ви вимагатимете шифрування в PPTP, ви покладаєтесь на MPPE з RC4. RC4 має довгу історію зрушень і виключення з основних
стандартів безпеки. Більш важливо те, що загальний дизайн PPTP і слабкості аутентифікації означають, що історія шифрування не відокремлена
чисто від аутентифікації. Ви не можете сказати «криптографія в порядку; це просто тунель».

3) GRE через NAT: постійна операційна головоломка

Сучасні мережі сповнені NAT, балансувальників навантаження, стано-залежних брандмауерів, асиметричної маршрутизації і «пристроїв безпеки»,
які більше займаються маркетингом, ніж аналізом пакетів. GRE не поводиться як TCP/UDP потоки, і багато пристроїв важко відстежують його
надійно, особливо через NAT. Очікуйте періодичних збоїв, одностороннього трафіку й повідомлень «в мене працює на мобільному інтернеті, але не вдома».

4) MTU та фрагментація: часті збої, які легко неправильно діагностувати

PPTP додає накладні витрати. PPP додає накладні витрати. GRE додає накладні витрати. Якщо ви запускаєте його по шляхах з меншим ефективним MTU
(поширене в хмарі та у провайдерів), виникають проблеми PMTUD, чорні діри для фрагментів або загадково повільні з’єднання. Користувачі бачать
«VPN підключено, але SharePoint не працює», і ви витрачаєте години, перш ніж виявити, що це просто розмір пакетів.

5) Відповідність вимогам і позиція під час аудиту: ви програєте дискусії, яких не мали б вести

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

Жарт №1: безпека PPTP — як замкнути вхідні двері, але сховати ключ під каменем з написом «KEY». Там технічно є замок.

Факти та історія, що пояснюють цей безлад

PPTP не зло — воно просто продукт свого часу. Розуміння того часу пояснює, чому протокол виглядає так, як виглядає — і чому він зараз не підходить.

1. PPTP з’явився в середині 1990-х, коли віддалений доступ означав dial-up модеми, а «корпоративна мережа» була набором довірених підмереж.
2. Він тісно асоціювався з екосистемою Microsoft, прагнучи зробити віддалений доступ у Windows нативним і простим для підприємств.
3. PPTP тунелює PPP, тому ви бачите риси епохи PPP: MS-CHAP, MPPE і шаблони переговорів, що передують сучасному дизайну VPN.
4. Для даних використовується GRE — не UDP — тому що дизайн припускав співпрацю мережі й GRE тоді був поширеним інструментом інкапсуляції.
5. MS-CHAPv2 широко розповсюдився через інтеграцію з Windows і очікуваннями епохи Active Directory.
6. Практичні серйозні атаки на MS-CHAPv2 були продемонстровані публічно роки тому, і спільнота безпеки пішла далі, навіть якщо багато мереж — ні.
7. Кілька великих постачальників ОС декомізували або видалили підтримку PPTP з часом, змушуючи використовувати сторонні клієнти або обхідні шляхи в сучасних парках пристроїв.
8. NAT став всюдисущим уже після того, як архітектура PPTP була закладена, і стосунки GRE з NAT відтоді незручні.
9. Сучасні VPN зсунулися до UDP і надійного обміну ключами (IKEv2, TLS-орієнтовані VPN, Noise-протоколи на кшталт WireGuard), бо інтернет ворожий і хаотичний.

Як PPTP відмовляє в реальному світі (модель загроз, не маркетинг)

Нападник, якого слід вважати реальним

Вам не потрібна держава-актор, щоб мати поганий день. Реалістичні загрози — це:

• Захоплення облікових даних та офлайн-злам після перехоплення рукопотискання або фішингу з наступними брутфорс-спробами VPN.
• Атакуючі на шляху передачі у кав’ярнях, готелях і в деяких ISP/корпоративних середовищах, де трафік можна спостерігати або модифікувати.
• Некоректно налаштовані проміжні пристрої, які «іноді» пропускають GRE, створюючи непостійні інциденти доступності, що виглядають як помилки користувача.
• Внутрішній латеральний рух після того, як скомпрометований пристрій успішно аутентифікується і отримує мережеву опору.

Режим відмови: «Шифрування ввімкнено», але безпека все одно руйнується

У PPTP люди часто чіпляються за чекбокс: «Вимагати MPPE». Проблема в тому, що якщо аутентифікацію можна примусити або зламати,
шифрування не врятує. Крипто — не магічний амулет. Це система. Система PPTP крихка.

Режим відмови: «Підключено», але трафік додатків зламаний

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

Режим відмови: реагування на інцидент без корисної телеметрії

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

Принцип надійності, що тут застосовується

Цитата (перефразована), приписувана Richard Cook: «Успіх ховає слабкості системи; невдача їх виявляє.» PPTP зазвичай виглядає добре до того дня, коли воно
не працює, і тоді ви виявляєте, наскільки мала у вас була маржа безпеки.

Що використовувати натомість: WireGuard, IKEv2/IPsec, OpenVPN та інші

WireGuard: сучасний дефолт для багатьох команд

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

Де він блискуче працює:

• VPN для віддалених користувачів з сучасним парком клієнтів
• Тунелі site-to-site, включно cloud-to-on-prem
• Висока пропускна здатність з низьким навантаженням на CPU

Де потрібно подумати:

• Процеси розподілу ключів і їх ротації (робіть це так само свідомо, як SSH-ключі)
• Інтеграція ідентичності та стану пристрою (часто поєднують з рівнем контролю доступу)

IKEv2/IPsec: нудно, стандартизовано, широко підтримується

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

Де він блискуче працює:

• Підприємства з керованими Windows/macOS/iOS/Android пристроями
• Сильна інтеграція з аутентифікацією на основі сертифікатів
• Ситуації, де «без додаткових клієнтів» — політична вимога

Де потрібно подумати:

• Складність: більше налаштувань, і люди люблять крутити ручки
• NAT traversal: зазвичай вирішується UDP-інкапсуляцією, але потрібні правильні правила брандмауера

OpenVPN (на базі TLS): зріла і гнучка, іноді важча

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

Де він блискуче працює:

• Середовища, що потребують глибокої інтеграції аутентифікації (RADIUS, LDAP, MFA-гітвеї)
• Мережі з незвичайними обмеженнями, де потрібно TCP-fallback
• Команди, які хочуть зрілу екосистему і встановлені операційні практики

SSL VPN-портали і рівні доступу «zero trust»

Іноді вам не потрібен повноцінний L3 VPN. Іноді потрібен доступ лише до кількох внутрішніх додатків з сильною перевіркою ідентичності та стану пристрою.
Сучасні проксі доступу можуть значно зменшити зону ураження. Якщо ваш випадок використання PPTP — «дозволити постачальникам RDP на один сервер»,
давати їм повний мережевий тунель — неправильний інструмент.

Чого не варто робити: «Просто залишимо PPTP, але додамо MFA»

MFA допомагає проти повторного використання паролів і деяких фішингових атак. Воно не виправляє слабку архітектуру тунелю, крихкість GRE або
ширшу депрекацію екосистеми. Додавати MFA на PPTP — як встановити сучасну сигналізацію в авто без гальм: ви дізнаєтесь, коли розіб’єтесь.

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

Коли трапляється інцидент з PPTP, важлива швидкість. Потрібно швидко відповісти на три питання: чи блокується воно, чи відбулося аутентифікування,
і чи фактично передаються дані?

По-перше: підтвердіть, чи проходить GRE (не тільки TCP 1723)

• Перевірте правила брандмауера/груп безпеки на предмет TCP/1723 і IP-протоколу 47 (GRE).
• На сервері прослухайте трафік GRE під час спроби підключення.
• Якщо ви бачите лише TCP-контрольний трафік і жодного GRE, це проблема мережевого шляху, а не пароля.

По-друге: валідуйте метод аутентифікації та логи

• Підтвердіть, чи сервер використовує MS-CHAPv2 і чи клієнти його погоджують.
• Шукайте повторювані невдалі рукопотискання; політики лімітування та блокування важливі.
• Якщо аутентифікація проходить, але трафік не йде, перестаньте сперечатися про облікові дані і почніть дивитися на MTU і маршрутизацію.

По-третє: перевірте MTU/фрагментацію та вибір маршруту

• Протестуйте path MTU за допомогою проб «не фрагментувати».
• Перевірте, чи клієнт прокачує маршрут за замовчуванням або використовує split tunneling.
• Шукайте асиметричну маршрутизацію між концентратором VPN і внутрішніми мережами.

Дерево рішень (практичне)

• GRE не спостерігається → виправте брандмауер/NAT/шлях або припиніть використання PPTP.
• GRE є, але аутентифікація не проходить → виправте облікові дані/політику аутентифікації; розгляньте негайну депрекацію, якщо ризик зламу реалістичний.
• Аутентифікація проходить, трафік нестабільний → MTU/PMTUD/маршрути; розгляньте міграцію, бо це повториться.

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

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

Task 1: Confirm the PPTP control port is listening

cr0x@server:~$ sudo ss -lntp | grep ':1723'
LISTEN 0      128          0.0.0.0:1723      0.0.0.0:*    users:(("pptpd",pid=1412,fd=6))

Значення: Демон слухає на TCP/1723 на всіх інтерфейсах.

Рішення: Якщо ніхто не слухає, ви не налагоджуєте «проблему VPN», ви налагоджуєте розгортання сервісу. Запустіть/увімкніть сервіс або припиніть вдавати, що PPTP існує.

Task 2: Check firewall rules for TCP/1723 and GRE

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    tcp dport 1723 accept
  }
}

Значення: TCP/1723 дозволений, але немає явного прийому для GRE (ip протокол 47).

Рішення: Якщо GRE не дозволено, PPTP «підключиться», а потім відмовить або зависне. Або додайте дозвіл для GRE (і прийміть ризик), або мігруйте.

Task 3: Verify GRE packets arrive during a connection attempt

cr0x@server:~$ sudo tcpdump -ni eth0 'proto 47 or port 1723' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:11:03.120981 IP 203.0.113.44.51120 > 198.51.100.10.1723: Flags [S], seq 311541, win 64240, options [mss 1460,sackOK,TS val 711 ecr 0,nop,wscale 7], length 0
12:11:03.121220 IP 198.51.100.10.1723 > 203.0.113.44.51120: Flags [S.], seq 144211, ack 311542, win 65160, options [mss 1460,sackOK,TS val 155 ecr 711,nop,wscale 7], length 0
12:11:05.542110 IP 203.0.113.44 > 198.51.100.10: GREv1, call 17, seq 0, len 156

Значення: Ви бачите і TCP-рукопотискання, і GRE-пayload. Мережевий шлях принаймні пропускає GRE.

Рішення: Якщо бачите TCP, але немає GRE — перестаньте гнатися за аутентифікацією і MTU; виправте шлях або переходьте на VPN на базі UDP.

Task 4: Confirm IP forwarding (server acting as gateway)

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

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

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

Task 5: Inspect kernel logs for GRE/PPTP errors

cr0x@server:~$ sudo journalctl -k --since "30 min ago" | tail -n 8
Dec 27 12:03:41 server kernel: pptp: GRE: bad checksum from 203.0.113.44
Dec 27 12:03:41 server kernel: ppp0: renamed from pptp0
Dec 27 12:03:43 server kernel: IPv4: martian source 192.168.0.10 from 203.0.113.44, on dev ppp0

Значення: Можливий пошкоджений трафік, дивна поведінка NAT або неправильно маршрутизовані приватні IP («martian source») всередині тунелю.

Рішення: Якщо ви бачите помилки контрольної суми або martian warnings, підозрюйте проміжні пристрої або перекривання підмереж. Це структурний ризик; плануйте міграцію.

Task 6: Check whether ppp interfaces are coming up

cr0x@server:~$ ip link show | grep -E 'ppp|pptp'
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3

Значення: Існує PPP-інтерфейс і він вгору; MTU 1400 (часто зменшують, щоб зменшити фрагментацію).

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

Task 7: Verify routing and whether VPN clients can reach internal subnets

cr0x@server:~$ ip route show
default via 198.51.100.1 dev eth0
10.10.0.0/16 via 10.99.0.1 dev eth1
192.168.200.0/24 dev ppp0 proto kernel scope link src 192.168.200.1

Значення: Сервер має маршрут до внутрішньої 10.10.0.0/16 через eth1 і підмережу клієнтів VPN на ppp0.

Рішення: Переконайтеся, що на внутрішніх маршрутизаторах є зворотні маршрути до 192.168.200.0/24, або зробіть NAT трафіку VPN навмисно (і задокументуйте компроміс).

Task 8: Confirm NAT rules if you’re masquerading VPN clients

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,80p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 192.168.200.0/24 -o eth1 -j MASQUERADE

Значення: Підмережа клієнтів VPN маскується при виході через eth1 до внутрішніх мереж.

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

Task 9: Detect MSS/MTU trouble with a DF ping test

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

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

Значення: Ваш path MTU = 1400 (або менше). Великі пакети відкидатимуться, якщо фрагментація заблокована.

Рішення: Зменшіть MTU/MSS на тунелі або виправте PMTUD/фільтрацію ICMP. Також: це причина випадкових інцидентів PPTP у різних мережах.

Task 10: Check for blocked ICMP (PMTUD breaker)

cr0x@server:~$ sudo nft list ruleset | grep -n 'icmp' | head
27:    ip protocol icmp accept

Значення: ICMP дозволений (добре), що допомагає PMTUD.

Рішення: Якщо ICMP блокується, ви отримаєте чорні діри MTU. Дозвольте потрібні типи ICMP або затисніть MSS на egress.

Task 11: Verify PPTP user auth attempts (example: Debian/Ubuntu with pptpd + PAM)

cr0x@server:~$ sudo journalctl -u pptpd --since "2 hours ago" | tail -n 12
Dec 27 10:44:12 server pptpd[1412]: CTRL: Client 203.0.113.44 control connection started
Dec 27 10:44:13 server pppd[18891]: Plugin /usr/lib/pppd/2.4.9/pptp.so loaded.
Dec 27 10:44:13 server pppd[18891]: CHAP authentication succeeded
Dec 27 10:44:13 server pppd[18891]: MPPE 128-bit stateless compression enabled
Dec 27 10:44:13 server pppd[18891]: local  IP address 192.168.200.1
Dec 27 10:44:13 server pppd[18891]: remote IP address 192.168.200.10

Значення: Аутентифікація пройшла; MPPE ввімкнено; IP-адреси призначені. Це не інцидент «неправильний пароль».

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

Task 12: Check DNS behavior for VPN clients (a classic “it’s connected but nothing works”)

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

Link 7 (ppp0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53

Значення: Система налаштована використовувати внутрішній DNS через інтерфейс VPN.

Рішення: Якщо клієнти VPN не можуть розв’язувати внутрішні імена, виправте налаштування DNS, що штовхаються, або split-DNS. Якщо ви не можете надійно штовхати DNS на клієнти PPTP — мігруйте.

Task 13: Identify a client stuck behind a NAT that breaks GRE (server-side conntrack)

cr0x@server:~$ sudo conntrack -L -p tcp --dport 1723 2>/dev/null | head -n 5
tcp      6 431999 ESTABLISHED src=203.0.113.44 dst=198.51.100.10 sport=51120 dport=1723 src=198.51.100.10 dst=203.0.113.44 sport=1723 dport=51120 [ASSURED] mark=0 use=1

Значення: Контрольний канал встановлено. Це не підтверджує, що GRE передається.

Рішення: Зіставте з tcpdump-захопленням GRE. Якщо контрольний канал увімкнений, але GRE відсутній — шлях NAT/брандмауера винен.

Task 14: Validate whether internal services see the real client IP (auditing question)

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.10.20.15 and port 445 -c 3
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:19:41.221033 IP 10.99.0.10.54812 > 10.10.20.15.445: Flags [S], seq 390011, win 64240, options [mss 1460,sackOK,TS val 921 ecr 0,nop,wscale 7], length 0

Значення: Джерельна IP — 10.99.0.10 (ймовірно NAT-шлюз VPN), а не реальний клієнт. Ось як працює NAT.

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

Task 15: Confirm if the path blocks GRE at the perimeter (cloud security groups often do)

cr0x@server:~$ sudo iptables -S INPUT | sed -n '1,80p'
-P INPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 1723 -j ACCEPT

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

Рішення: Розгляньте це як примусову дію: оберіть WireGuard/IKEv2/OpenVPN і рухайтеся далі. Не будуйте лабіринт винятків для GRE.

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

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

Середня компанія успадкувала налаштування PPTP під час поглинання. Воно «працювало», і так спадщинні системи заробляють собі довговічність.
Нова мережна команда мігрувала пограничні брандмауери до керованого хмарного сервісу. Вони відкрили TCP/1723, перевірили досяжність порту і пішли далі.
Наступного ранку почалися заявки: «VPN підключається, але я нічого не бачу».

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

Рішення не було в хитрому правилі брандмауера. Продукт керованого фаєрвола не підтримував IP-протокол 47 у потрібний спосіб, а там, де його можна було ввімкнути,
upstream NAT ламав відстеження сесій. Вони швидко зробили proof-of-concept на WireGuard на невеликому інстансі, перевірили його з тими самими користувачами,
і заявки припинилися.

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

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

Інша організація зберегла PPTP, бо воно здавалося «легким». Вони розгортали віддалений доступ для сезонних працівників і хотіли мінімальні накладні витрати
на маленьку VPN-VM. Хтось помітив, що проблеми з MTU часті, і вирішив «оптимізувати», агресивно знизивши MTU тунелю і затиснувши MSS на вихідному трафіку,
щоб зупинити фрагментацію раз і назавжди.

Це спрацювало — частково. Скарги на підключення зменшилися, і вони оголосили перемогу. Потім почалися скарги на продуктивність: передача файлів повзла,
віддалений робочий стіл відчувався «липким», а внутрішні веб-додатки дивно повільні під навантаженням. Команда думала, що проблема в шарі додатків. Це
не було так. Вони створили стелю пропускної здатності і посилили неефективність TCP. Малий MTU означає більше пакетів для того ж тіла даних; більше пакетів —
більше накладних витрат; більше накладних витрат — більше CPU та більше шансів втрат.

Під навантаженням CPU інстансу підскакував у softirq і обробці пакетів. Користувачі бачили «VPN повільний». SRE бачив «чому маленький VM виглядає як DDoS?».
Їхня «оптимізація» перетворила крихкий тунель на ще крихкіший тунель, що не може переносити дані.

Зрештою вони замінили PPTP на IKEv2/IPsec, використовуючи адекватні налаштування MTU і правильний NAT traversal. Продуктивність стабілізувалася, і служба
підтримки перестала збирати ті самі тікети в трохи іншому шрифті.

Урок: коли ви компенсуєте структурну слабкість протоколу, ви не оптимізуєте — ви накопичуєте побічні ефекти.

Міні-історія 3: Сумна, але правильна практика, що врятувала ситуацію

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

У них був централізований логінг для подій аутентифікації, синхронізація часу і алерт на незвичну поведінку логінів (нові географії, повторні невдачі,
раптове збільшення успішних сесій). Правило було суворим: облікові записи PPTP були відокремлені від звичайних, з коротким строком дії. Постачальники отримували
персональні облікові записи, а не спільні креденшіали. Це було набридливо. Але в цьому й сенс.

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

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

Жарт №2: запускати PPTP в продакшені — як тримати факс «на всякий випадок». Його обов’язково використають у найгірший можливий момент.

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

Невдачі PPTP повторюються. Вони не загадкові; вони шаблонні. Ось ті, що крадуть найбільше часу.

1) Симптом: «VPN підключається, але трафік не проходить»

Корінна причина: GRE (IP-протокол 47) заблокований брандмауером, групою безпеки, NAT-пристроєм або неправильно відстеженим станом.

Виправлення: Підтвердіть через tcpdump на предмет GRE; дозвольте GRE наскрізь, якщо мусите; інакше мігруйте на VPN на базі UDP (WireGuard/IKEv2/OpenVPN).

2) Симптом: «Працює в офісі, не працює на домашньому ISP»

Корінна причина: Домашні роутери/ISP CGNAT неправильно обробляють GRE або не підтримують PPTP passthrough надійно.

Виправлення: Перестаньте покладатися на GRE. Використайте WireGuard або IKEv2 з NAT traversal.

3) Симптом: «Підключено, але внутрішні сайти частково завантажуються / завантаження зависають»

Корінна причина: MTU/PMTUD чорна діра; ICMP блокується; фрагментація відкидається проміжними пристроями.

Виправлення: Тест DF ping; дозволіть ICMP fragmentation-needed; затисніть MSS; обережно знижуйте MTU тунелю. Розглядайте це як тригер для міграції.

4) Симптом: Часті підказки пароля або повторні розриви

Корінна причина: Несумісність переговорів аутентифікації (MS-CHAPv2 vs інші), або зміни політик у бекенді ідентичності.

Виправлення: Закріпіть підтримувані методи аутентифікації; перевірте логи; розгляньте аутентифікацію на основі сертифікатів у IKEv2/IPsec або сучасний доступ на основі ідентичності.

5) Симптом: «Повільно, але CPU низький»

Корінна причина: Втрата/фрагментація, що призводить до TCP backoff; малий MTU і нестабільність шляху. Не завжди прив’язано до CPU.

Виправлення: Виміряйте втрати пакетів, повторні передачі і MTU. Не «оптимізуйте» простим зменшенням MTU; виправте шлях або замініть протокол.

6) Симптом: Внутрішні системи бачать лише IP шлюзу VPN

Корінна причина: Використано NAT (masquerade) щоб уникнути додавання маршрутів для підмережі клієнтів.

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

7) Симптом: «Деякі користувачі можуть підключитись, інші завжди падають»

Корінна причина: Перекривання IP-діапазонів між домашніми мережами клієнтів і корпоративними підмережами (класика 192.168.0.0/24).

Виправлення: Використовуйте неперекривні пулі VPN-адрес, обережно впроваджуйте split tunneling або переходьте на доступ до додатків. Перекриття не вирішиться з часом.

8) Симптом: Команда безпеки одразу фіксує VPN

Корінна причина: PPTP широко визнано застарілим і слабким, незалежно від локальних мігів.

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

Контрольні списки / поетапний план: безпечно застаріти PPTP

Крок 0: Визначте заміну на основі обмежень

• Якщо потрібна простота й продуктивність: WireGuard.
• Якщо потрібна нативна підтримка ОС і сертифікати: IKEv2/IPsec.
• Якщо потрібна гнучкість і глибока інтеграція аутентифікації: OpenVPN.
• Якщо потрібні лише кілька додатків: не розгортайте повний VPN; використайте доступ через проксі/доступ на основі додатків.

Крок 1: Інвентаризація використання PPTP (користувачі, пристрої, мережі, залежності)

• Перелічіть кінцеві точки PPTP (сервери, маршрутизатори, апарати).
• Перелічіть, хто ним користується (співробітники, постачальники, сервісні акаунти).
• Перелічіть, до чого вони підключаються (підмережі, додатки, порти).
• Захопіть, коли вони ним користуються (робочі години, поза годинами, пакетні завдання).

Крок 2: Помістіть PPTP у бокс із обмеженням (поки воно існує)

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

Крок 3: Побудуйте новий VPN паралельно

• Виберіть одну-дві внутрішні підмережі для першого відкриття.
• Спроектуйте адресацію, щоб уникнути перекриття з поширеними домашніми діапазонами.
• Розв’яжіть питання split tunnel vs full tunnel свідомо.
• Вирішіть поведінку DNS (повний DNS, split DNS, внутрішні резолвери).

Крок 4: Пілотуйте з реальними користувачами і ворожими мережами

• Тестуйте з домашніх ISP, мобільних хотспотів і готельного Wi‑Fi.
• Виміряйте затримки, пропускну здатність, поведінку повторного підключення і обробку збоїв.
• Переконайтеся, що команда підтримки може швидко діагностувати (логи, метрики, runbooks).

Крок 5: Міграція хвилями з чіткою датою завершення

• Почніть з IT та power users.
• Потім мігруйте команди з передбачуваними потребами.
• Залиште постачальників і «особливі» робочі процеси наостанок, але не дозволяйте їм відкладати дату.

Крок 6: Виведіть PPTP з експлуатації радикально

• Заблокуйте створення нових акаунтів.
• Видаліть PPTP-конфігурації з керування пристроями.
• Вимкніть сервіс, закрийте TCP/1723 і видаліть дозволи на GRE.
• Моніторте спроби підключення після цього — очікуйте кілька; розглядайте їх як відсталих мігрантів, а не причину відновлення сервісу.

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

Чи завжди PPTP небезпечний, чи тільки при слабких паролях?

Він структурно слабкий у типових реальних розгортаннях, бо MS-CHAPv2 дає практичні офлайн-атаки. Сильні паролі допомагають, але не перетворюють
PPTP на сучасний дизайн і не вирішують крихкість GRE/NAT.

Чи можна зробити PPTP прийнятним, примусивши MPPE 128-bit?

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

Яка найпростіша заміна для невеликої команди?

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

Потрібна «вбудована підтримка клієнтів» у Windows і iOS. Що вибрати?

IKEv2/IPsec з аутентифікацією на основі сертифікатів — типова відповідь. Воно широко підтримується без сторонніх клієнтів і може працювати
так, щоб команда безпеки визнала це за належну практику.

OpenVPN ще хороший вибір, чи це теж «застаріло»?

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

Чому PPTP ламається саме в деяких готелях або домашніх мережах?

Тому що GRE часто неправильно обробляють NAT-пристрої й брандмауери. TCP/1723 може проходити, даючи ілюзію підключення, тоді як GRE-пейлоад
блокується або неправильно відстежується.

Краще використовувати повний тунель VPN чи split tunnel при міграції?

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

А що з «L2TP/IPsec»? Чи краще це за PPTP?

Загалом це значне покращення над PPTP, особливо при налаштуванні з сучасною криптографією і сертифікатною аутентифікацією. Але у багатьох командах
IKEv2/IPsec краще справляється з мобільністю і сучасними умовами мережі.

Ми маємо пристрій постачальника, що підтримує тільки PPTP. Що робити?

Помістіть його за контрольованим шлюзом, який ззовні говорить сучасним VPN, а всередині — PPTP лише в жорстко обмеженому сегменті, і плануйте заміну пристрою.
Розглядайте підтримку PPTP як баг постачальника, а не як вимогу.

«VPN підключено, але DNS не працює» — це проблема PPTP?

Це проблема «VPN загалом», але клієнти PPTP відомі своєю непослідовністю по платформах, і старі клієнти можуть не коректно приймати штовхані DNS-настроювання.
Якщо коректність DNS важлива (а вона важлива), оберіть VPN-стек з надійною поведінкою клієнтів і централізованим управлінням.

Висновок: що зробити в понеділок вранці

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

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

• Офіційно застарійте PPTP всередині організації з реальною датою вимкнення, а не декларацією бажань.
• Виберіть заміну (WireGuard для простоти/продуктивності, IKEv2/IPsec для нативних клієнтів, OpenVPN для гнучкості).
• Ізолюйте існуючий PPTP-сервіс поки він працює: правила найменших привілеїв, відокремлені акаунти, централізовані логи і алерти.
• Запустіть паралельний пілот у ворожих мережах, а не тільки в офісному LAN.
• Після завершення — видаліть дозволи на GRE і закрийте 1723. Не залишайте закинуті порти.