Грешки при пишување 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 сѐ уште е осомничениот. Тоа е моментот да се вратите на снимањето, а не во складиштето на акредитиви.