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