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