Поделениот тунел на 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 уредите со состојба мора да го разберат ID на повикот во 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 на секој скок. Проверете го сертификатот и договорот за автентикација на замената наместо да копирате стар профил во ново издание.