PPTP падключаецца і затым завісае за Linux NAT: памочнік GRE

Хтосьці перасылае 1723, кліент дасягае сервера, пачынаецца аўтэнтыфікацыя, і потым усё спыняецца без памылкі. Натуральная выснова — няправільны пароль, таму пароль уводзіцца яшчэ тры разы. Перасылка была ў парадку, і ўліковыя даныя былі ў парадку. Зламаўся другі пратакол, які перасылка ніколі не пакрывала, і тыповае значэнне ядра, якое ціха перастала дапамагаць з ім.

Перасылка ніколі не была праблемай

Правіла перасылкі партоў апісвае трафік TCP або UDP. Яно не можа апісаць нагрузку, якая пасярэдзіне сесіі перамыкаецца на іншы пратакол IP, і PPTP робіць менавіта гэта.

Таму злучэнне выглядае здаровым аж да моманту, калі яно завісае. Частка, якой можа кіраваць правіла партоў, спрацавала, а частка, якой яно не можа кіраваць, — гэта тая частка, што не спрацавала.

TCP для кіравання, GRE для даных

Выклік узгадняецца праз TCP 1723. Пасля ўсталявання нагрузка пераходзіць у GRE, пратакол IP 47, які ўвогуле не нясе нумароў партоў. Правіла, якое абапіраецца на парты, не мае з чым супаставіцца.

GRE нясе ідэнтыфікатар выкліку ў сваім загалоўку, і транслятар павінен перазапісваць гэтае поле ўзгоднена ў абодвух кірунках, інакш дзве паловы сесіі перастаюць дамаўляцца адна з адной. Перазапісаны адзін кірунак і не перазапісаны другі ствараюць сесію, якая аўтэнтыфікуецца і потым адкідвае кожны пакет даных. Менавіта так выглядае сімптом: поспех, потым цішыня.

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