Памылкі запісу 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 застаецца падазроным. Гэта момант вярнуцца да захопу, а не да сховішча ўліковых даных.