Грешки при запис на GRE в pptpd не са проблем с паролата

Грешка при запис на GRE в журнала, и първият инстинкт е да нулирате паролата на потребителя. Този инстинкт почти винаги е грешен. Тези съобщения описват пътя на данните, а не проверката на идентификационните данни: клиентът може да се е удостоверил успешно и след това да е заседнал на етапа, в който се регистрира в мрежата. Две различни съобщения сочат към два различни отказа и нито един не се решава с нова парола.

Две съобщения, два различни отказа

Отказ при четене означава, че пакетите GRE никога не достигат до демона или се изхвърлят по пътя навътре. Контролната връзка може да изглежда напълно здрава, докато нищо не преминава по пътя на данните. Удостоверяването е единственото, което очевидно е проработило.

Отказ при запис обикновено означава, че сесията е договорила нещо, което ядрото или клиентът не могат да използват. Контролният канал е завършил и опциите, договорени при този обмен, не съвпадат с това, което крайните точки реално могат да правят. Това е разминаване в конфигурацията, а не събитие по удостоверяване.

Прочетете кой от двата се появява, преди да промените каквото и да е. Те ви насочват към различни слоеве и третирането им като един симптом е причината един и същ сървър да бъде коригиран два пъти по несвързани причини. Редът в журнала е единствената безплатна диагностика, която получавате.

Протокол 47 не е порт 47

PPTP използва TCP 1723, за да установи връзката, и GRE, за да пренася полезния товар. GRE е IP протокол 47, а не номер на порт, така че правило в защитната стена, което отваря порт 47, не разрешава нищо полезно.

Маршрутизаторът по пътя се нуждае от функция PPTP passthrough или от изрично разрешение за GRE. Без него TCP ръкостискането завършва и тунелът никога не пренася пакет, което произвежда точно отказа при четене по-горе. Правилата за порт 47 в защитната стена са най-често пропиляният следобед в този протокол.

Наблюдавайте двете посоки едновременно на сървъра, вместо да гадаете коя страна изхвърля трафика: tcpdump -ni any port 1723 or proto gre.

Ако 1723 показва установяване на връзка, а GRE остава безмълвен, блокирането е над хоста. Ако GRE пристига, а демонът все още се проваля, проблемът е локален и опциите са следващото място за гледане.

Разрешете GRE там, където хостът действително препраща

Вмъкването на forward правило за GRE е разумна проверка на хост, който препраща тунелен трафик, и не е политика. Тестово правило, което приема всичко от един протокол, е диагностика, а не дизайн. Оставете го достатъчно дълго, за да научите нещо, след което го заменете с ограничено правило.

Добавете input правило за пакети, адресирани до самия сървър, защото forward веригата не ги вижда. След това наблюдавайте броячите на правилото преди и след опит за връзка, което ви казва дали пакетите изобщо пристигат.

Запазете правилото чрез услугата за защитна стена на дистрибуцията, вместо да го пускате отново след всяко рестартиране. На хост с nftables съпоставете ip protocol gre и в input, и във forward веригата.

Уверете се, че модулът ppp_generic също е зареден, и проверете дали проследяването на връзки изхвърля обратната посока. И двете създават откази, които изглеждат като проблем със защитната стена, но не са. Липсващият модул на ядрото изглежда точно като блокиран протокол, докато не проверите.

Съобразете опциите с клиента, който действително имате

Поправката от другия доклад е в /etc/ppp/pptpd-options, където рецептата отказва PAP, CHAP и MSCHAP, коментира съответните require редове и запазва MPPE със запазване на състоянието. Тази рецепта е написана за един набор клиенти и сляпото ѝ копиране чупи обичайния случай. Четете редовете за отказ като твърдение за това какви клиенти е имал авторът, а не като препоръка.

Клиент на Windows обикновено се нуждае от MS-CHAPv2 с MPPE-128. Запазете тези изисквания и премахнете само опциите, които клиентът наистина не може да договори.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Изключването на криптирането, за да успее връзка, е понижение, а не поправка. Тествайте такъв вариант на лабораторна връзка, след което възстановете криптирането, преди услугата да срещне реални клиенти. Връзката, която работи несигурно, е по-лоша от тази, която се проваля честно.

Прочетете номера на грешката на клиента

Цифровият код на клиента стеснява етапа по-бързо от сървърния журнал. Прочетете го, преди да четете каквото и да е друго. 691 означава, че идентификационните данни са отхвърлени, 721 означава, че сървърът никога не е отговорил, а 619 означава, че връзката е прекъснала. Две минути с номера спестяват час с конфигурацията.

Сравнете този код със сървърния журнал, преди да редактирате каквото и да е, и тествайте отново със същия клиент след всяка промяна. Иначе втори отказ се крие зад първия и поправката изглежда неефективна.

Когато входът успее и трафикът не се движи, GRE остава заподозреният. Това е моментът да се върнете към прихващането, а не към хранилището на идентификационни данни.