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

Запишіть стек, перш ніж щось чіпати

Три шари зливаються в слово PPTP, і кожен ламається по-своєму. Тунель — це сам PPTP, GRE плюс TCP 1723. Автентифікація — це той метод PPP, який пропонує сервер, тут MS-CHAPv2. Захист каналу — MPPE, ключі якої виводяться з того самого обміну автентифікації. Назвати всі три означає, що пізніше виправлення не потрапить не на той шар.

Читайте живу конфігурацію, а не довіряйте вікі-сторінці, і запишіть файл, слухача та останні сеанси, що пройшли автентифікацію.

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

У ролі віддаленого доступу Windows той самий інвентар постає з двох команд, і друга важлива, бо роль може оголошувати кілька методів одразу, тоді як клієнти в полі завжди домовляються лише про найслабший.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Вирішіть, що тунель насправді несе сьогодні

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

Далі спитайте, що отримає зловмисник, який може спостерігати за обміном під час входу або впливати на нього. У разі MS-CHAPv2 відповідь містить матеріал, що дозволяє офлайн відновити пароль користувача, і саме тому довжина й ротація не виправляють проєкт: відновлений секрет чинний у кожній системі, де користувач застосував його повторно.

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

Ані коротка обідня перерва, ані мала кількість користувачів не перетворюють криптографічну властивість на політичну.

Проведіть міграцію в одному вікні обслуговування

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

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

Закрийте шлях через міжмережевий екран у тому ж вікні. У GRE немає порту, який треба пам'ятати, тож правило, що дозволяє протокол 47 за номером, легко проґавити, і воно лишає службу доступною навіть після зникнення демона. Запишіть вилучене правило, його попереднє положення та причину, щоб пізніший огляд змін не відновив його випадково.

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

Перевірте, що заміна виконує ту роботу, яку виконував PPTP

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

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

Адреса на інтерфейсі доводить, що узгодження завершилося. Вона не доводить, що віддалена сторона авторизувала очікуваний вами маршрут, а запит вище відповідає лише за цей хост, не за пересилану LAN. Відповідь розв'язувача доводить доступність розв'язувача, а не те, що політика розділеного DNS надсилає туди правильні імена.

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

Відкат, відкликання та запис, який ви лишаєте

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

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

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

Схожі статті