Ang mga pagkabigo sa pagsulat ng GRE sa pptpd ay hindi problema sa password

Pagkabigo sa pagsulat ng GRE sa log, at ang unang instinct ay i-reset ang password ng gumagamit. Ang instinct na iyon ay halos palaging mali. Inilalarawan ng mga mensaheng ito ang landas ng datos, hindi ang pagsusuri ng kredensyal: maaaring matagumpay na na-authenticate ang kliyente at pagkatapos ay natigil sa yugto kung saan ito nagrerehistro sa network. Dalawang magkaibang mensahe ang tumutukoy sa dalawang magkaibang fault, at wala sa kanila ang nasosolusyunan ng bagong password.

Dalawang mensahe, dalawang magkaibang fault

Ang pagkabigo sa pagbasa ay nangangahulugang hindi kailanman umabot ang mga packet ng GRE sa daemon, o itinatapon ito sa pagpasok. Maaaring ganap na malusog ang hitsura ng control connection habang walang tumatawid sa landas ng datos. Ang authentication ang tanging bagay na napatunayang gumana.

Ang pagkabigo sa pagsulat ay karaniwang nangangahulugang may napagkasunduan ang session na hindi magamit ng kernel o ng kliyente. Nakumpleto ang control channel, at ang mga opsyong napagkasunduan sa palitan na iyon ay hindi tugma sa aktwal na kayang gawin ng mga endpoint. Ito ay hindi pagkakasundo sa configuration, hindi kaganapan ng authentication.

Basahin kung alin sa dalawa ang lumilitaw bago baguhin ang anuman. Dinadala ka nila sa magkaibang layer, at ang pagtrato sa kanila bilang isang sintomas ang dahilan kung bakit ang parehong server ay na-patch nang dalawang beses dahil sa walang kaugnayang dahilan. Ang linya sa log ang tanging libreng diagnosis na nakukuha mo.

Ang protocol 47 ay hindi port 47

Gumagamit ang PPTP ng TCP 1723 upang i-set up ang tawag at GRE upang magdala ng payload. Ang GRE ay IP protocol 47, hindi numero ng port, kaya ang firewall rule na nagbubukas ng port 47 ay walang pinapayagang kapaki-pakinabang.

Ang router sa landas ay nangangailangan ng passthrough na tampok ng PPTP o malinaw na pahintulot sa GRE. Kung wala iyon, natatapos ang TCP handshake at hindi kailanman nagdadala ng packet ang tunnel, na lumilikha ng eksaktong pagkabigo sa pagbasa sa itaas. Ang mga patakaran sa port 47 sa firewall ang pinakamadalas na nasasayang na hapon sa protocol na ito.

Obserbahan ang parehong direksyon nang sabay sa server sa halip na hulaan kung aling panig ang nagtatapon ng trapiko: tcpdump -ni any port 1723 or proto gre.

Kung ang 1723 ay nagpapakita ng pag-set up ng tawag habang tahimik ang GRE, ang pagharang ay nasa itaas ng host. Kung dumarating ang GRE at nabigo pa rin ang daemon, lokal ang problema at ang mga opsyon ang susunod na titingnan.

Payagan ang GRE kung saan talagang nagpapasa ang host

Ang pagpasok ng forward rule para sa GRE ay makatwirang pagsubok sa host na nagpapasa ng trapiko ng tunnel, at hindi ito patakaran. Ang test rule na tumatanggap ng lahat ng isang protocol ay diagnosis, hindi disenyo. Iwanan ito nang sapat na katagalan upang may matutunan, pagkatapos ay palitan ng limitadong patakaran.

Magdagdag ng input rule para sa mga packet na nakadirekta sa server mismo, dahil hindi sila nakikita ng forward chain. Pagkatapos ay tingnan ang mga counter ng patakaran bago at pagkatapos ng pagtatangkang kumonekta, na nagsasabi kung dumarating man lang ang mga packet.

Gawing permanente ang patakaran sa pamamagitan ng firewall service ng distribution sa halip na patakbuhin itong muli pagkatapos ng bawat reboot. Sa host na nftables, itugma ang ip protocol gre sa input at forward chain.

Kumpirmahin na nakarga rin ang module na ppp_generic, at tingnan kung itinatapon ng connection tracking ang pabalik na direksyon. Pareho silang gumagawa ng mga pagkabigong mukhang problema sa firewall at hindi naman. Ang kulang na kernel module ay mukhang eksaktong naka-block na protocol hanggang sa suriin mo.

Itugma ang mga opsyon sa kliyenteng talagang mayroon ka

Ang pagwawasto mula sa kabilang ulat ay nasa /etc/ppp/pptpd-options, kung saan tinatanggihan ng recipe ang PAP, CHAP at MSCHAP, kinokomento ang kaukulang require na linya at pinapanatili ang MPPE na may estado. Ang recipe na iyon ay isinulat para sa isang halo ng kliyente, at ang bulag na pagkopya ay sumisira sa karaniwang kaso. Basahin ang mga linya ng pagtanggi bilang pahayag tungkol sa kung anong mga kliyente mayroon ang may-akda, hindi bilang rekomendasyon.

Ang kliyenteng Windows ay karaniwang nangangailangan ng MS-CHAPv2 kasama ng MPPE-128. Panatilihin ang mga pangangailangang iyon at alisin lamang ang mga opsyong talagang hindi maaaring pag-usapan ng kliyente.

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

Ang pag-off ng encryption upang magtagumpay ang koneksyon ay pagbaba ng antas, hindi pag-aayos. Subukan ang gayong variant sa laboratory link, pagkatapos ay ibalik ang encryption bago harapin ng serbisyo ang tunay na mga kliyente. Ang koneksyong gumagana nang hindi secure ay mas masama kaysa sa nabigo nang tapat.

Basahin ang numero ng error ng kliyente

Ang numerikong code ng kliyente ay nagpapaliit ng yugto nang mas mabilis kaysa sa log ng server. Basahin ito bago magbasa ng anupaman. Ang 691 ay nangangahulugang tinanggihan ang kredensyal, 721 ay nangangahulugang hindi kailanman sumagot ang server, at 619 ay nangangahulugang naputol ang koneksyon. Dalawang minuto kasama ang numero ay nakakatipid ng isang oras sa configuration.

Ihambing ang code na iyon sa log ng server bago mag-edit ng anuman, at muling subukan gamit ang parehong kliyente pagkatapos ng bawat pagbabago. Kung hindi, nagtatago ang pangalawang pagkabigo sa likod ng una at mukhang walang bisa ang pagwawasto.

Kapag nagtagumpay ang pag-log in at walang gumagalaw na trapiko, nananatiling suspek ang GRE. Iyon ang sandali upang bumalik sa pagkuha sa halip na sa imbakan ng kredensyal.