PPTP се поврзува и потоа заглавува зад Linux NAT: GRE помошникот

Некој пренасочува 1723, клиентот стигнува до серверот, започнува автентикацијата и потоа сето запира без грешка. Природниот заклучок е погрешна лозинка, па лозинката се внесува повторно три пати. Пренасочувањето беше во ред и акредитивите беа во ред. Она што се скрши е втор протокол што пренасочувањето никогаш не го покривало, и стандардната вредност на јадрото што тивко престана да помага со него.

Пренасочувањето никогаш не беше проблемот

Правило за пренасочување на порта опишува TCP или UDP сообраќај. Не може да опише товар што преминува на друг IP протокол на средина од сесијата, а PPTP прави токму тоа.

Затоа врската изгледа здрава до моментот кога ќе заглави. Делот што правилото за порта може да го контролира успеа, а делот што не може да го контролира е делот што не успеа.

TCP за контрола, GRE за податоци

Повикот се договара преку TCP 1723. Откако ќе се подигне, товарот преминува во GRE, IP протокол 47, кој воопшто не носи броеви на порти. Правилото што се потпира на порти нема што да совпадне.

Она што GRE го носи е идентификатор на повик во неговото заглавие, и NAT преведувачот мора доследно да го препише тоа поле во двете насоки, инаку двете половини од сесијата престануваат да се согласуваат. Едната насока препишана, а другата не, создава сесија што се автентификува и потоа го отфрла секој пакет со податоци. Токму таква е формата на симптомот: успех, потоа тишина.

Гол GRE без PPTP не бара такво препишување, затоа обичен GRE тунел може да работи низ рутер што не успева за PPTP клиент на истиот пат.

Четири модули и sysctl што ги исклучи

Два модули се грижат за рамкирањето, nf_conntrack_proto_gre и nf_nat_proto_gre. Уште два се грижат за идентификаторот на повик, nf_conntrack_pptp и nf_nat_pptp. Вчитувањето на последниот ги влече останатите преку зависности, така што списокот со модули треба да ги покаже сите четири.

Постарите упатства користат префикс ip_ од ерата на 2.6. Тим команди може да изгледаат како да работат додека не вчитуваат ништо, затоа проверете го вчитаниот список, а не излезниот статус.

Нивното вчитување веќе не е доволно. Од Linux 4.7 sysctl net.netfilter.nf_conntrack_helper е 0 по стандард, што го исклучува автоматското доделување на помошник за нови текови. Рутерот може да ги има сите модули и сепак ништо да не преведува. Проверете ја ефективната вредност пред повторно да го погледнете списокот со модули.

Или повторно вклучете го автоматското доделување глобално, или прикачете го помошникот на тековите на кои им треба и оставете сето друго на мира:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Втората опција е подобра. Таа го ограничува однесувањето на PPTP сообраќајот наместо повторно да го овозможи автоматското доделување низ целиот рутер.

Отворање протокол што нема порти

Правило на огнената граница што дозволува 1723 не кажува ништо за протоколот 47. Во firewalld дозволете го протоколот во зоната свртена кон клиентот. Во обичен iptables прифатете го протоколот gre во влезниот синџир.

Потоа снимајте на двете страни. Пакети што го напуштаат клиентот без одговори што пристигнуваат значат дека повратниот пат е филтриран, и тоа е друга дефект од одбиени акредитиви.

Откако ќе се поврзе, границата на големината

GRE вметнува заглавие, а PPP внатре додава уште, така што работната врска пријавува MTU значително под 1500. Малите одговори се вчитуваат, а големите заглавуваат, што изгледа како втор, неповрзан проблем што се појавува во моментот кога првиот е решен.

Прочитајте го MTU на PPP адаптерот на клиентот и усогласете го со сопствената пресметка на рутерот наместо да ги намалувате броевите додека нешто не проработи. Пакети со полна големина што излегуваат без ништо да се врати укажуваат на таа граница, а не на преводот.

Поправката на патеката го враќа корисникот во работа, и тоа не го прави PPTP добар избор. MS-CHAPv2 и RC4 одамна се застарени, затоа вчитувањето на модулите третирајте го како привремена поправка и планирајте премин кон одржуван протокол.