Раздвоенае тунеляванне 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, пераход звычайна мbельш выкарыстоўвае час, чым наладка шляху, які залежыць ад праходжання пратаколу 47 на кожным хопе. Праверце сертыфікат і дамову аўтэнтыфікацыі замены замест капіявання старога профілю ў новы выпуск.