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 су одавно застарели, зато учитавање модула третирајте као привремену поправку и планирајте прелазак на одржавани протокол.