Роздільне тунелювання PPTP не працює: спершу виправте шлях GRE

Спостерігайте, як піднімається з'єднання PPTP, і легко повірити, що складна частина позаду: клієнт проходить автентифікацію, з'являється адаптер ppp0 або WAN Miniport, і вікно стану стає зеленим. Далі перший запит до внутрішнього хоста вичерпує час, і профіль стає винним. На практиці треба пройти два незалежні шари: зовнішній транспорт, що несе TCP 1723 і GRE, та внутрішню політику, яка вирішує, які призначення використовують інтерфейс PPP. Зелений статус доводить лише те, що перший шар домовився; про другий він не каже нічого.

Простежте клієнт від профілю до керівного сокета

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

Підтвердьте керівне з'єднання в мережі, перш ніж торкатися будь-якого маршруту. На клієнті або дзеркальному порту захопіть TCP 1723 для однієї спроби з'єднання:

sudo tcpdump -ni any 'tcp port 1723' -c 20

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

GRE — це другий протокол, а не порт

PPTP несе корисне навантаження PPP усередині розширеного GRE, протоколу IP 47, який не має номера порту, за яким міг би стежити маршрутизатор. Тому правило, що дозволяє TCP 1723, усе одно може залишити тунель без шляху даних. Пристрої NAT зі станом мають розуміти ідентифікатор виклику всередині GRE, щоб повертати відповіді, і багато з них цього не роблять. Специфікація PPTP тримає керівний канал і корисне навантаження GRE окремими частинами, і ваш план тестування має бути таким самим.

Стежте за протоколом 47 у тому самому захопленні, потім порівняйте те, що виходить, з тим, що повертається:

sudo tcpdump -ni any 'proto gre' -c 20

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

Доведіть, що тунель передає один пакет

Щойно GRE пішов, узгодження PPP призначає адресу інтерфейсу клієнта. Прочитайте призначення, а не припускайте його:

ip -4 addr show ppp0

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

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

Напишіть роздільну політику, включно з DNS

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

Перевірте рішення, яке ядро ухвалює для однієї адреси в кожній категорії:

ip route get 10.20.5.10
ip route get 203.0.113.25

Перший має назвати ppp0, другий — звичайний шлюз. Якщо обидва називають той самий інтерфейс, політика зовсім не розділена. Додайте власну адресу DNS-сервера до тунельного списку, інакше розв'язання імен для внутрішніх хостів виходить через локальний резолвер і не повертає нічого корисного.

Повторювана перевірка в п'ять кроків

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

Компактна версія для клієнта Linux виглядає так:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

У Windows діє той самий порядок із route print і станом адаптера, показаним у клієнті. PPTP — застарілий протокол, і якщо сервер пропонує SSTP або IKEv2, перехід зазвичай краще використовує час, ніж налаштування шляху, що залежить від проходження протоколу 47 на кожному хопі. Перевірте сертифікат і договір автентифікації заміни, замість копіювання старого профілю в новий випуск.