Разделено тунелиране на PPTP не работи: оправете първо пътя на GRE

Разделеното тунелиране на 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

Направете ping към адреса на партньора, показан като дестинация на връзката точка-точка. Отговор на този етап доказва, че инкапсулираният път работи от край до край и че сървърът отговаря вътре в тунела. Ако партньорът отговаря, а вътрешните хостове не, външният транспорт е наред и повредата се е преместила навътре.

Направете това преди да добавите какъвто и да е разделен маршрут. Промяна на маршрут, направена при счупен транспорт, създава втора променлива и скрива първата.

Напишете разделената политика, включително 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 на всеки хоп. Проверете сертификата и договора за удостоверяване на замяната, вместо да копирате стар профил в нова версия.

Подобни статии