GRE kirjutamisvead pptpd-s ei ole parooliprobleem
Protokoll 47 ei ole port 47. Lugege pptpd kaht teadet kahe erineva rikkena, lubage GRE seal, kus host edasi suunab, ja hoidke MPPE selle asemel, et see välja lülitada.
GRE kirjutamisviga logis, ja esimene instinkt on kasutaja parool lähtestada. See instinkt on peaaegu alati vale. Need teated kirjeldavad andmete teed, mitte mandaatide kontrolli: klient võis edukalt autentida ja seejärel takerduda etappi, kus ta end võrku registreerib. Kaks erinevat teadet osutavad kahele erinevale rikkele ja kumbagi ei lahenda uus parool.
Kaks teadet, kaks erinevat riket
Lugemisviga tähendab, et GRE paketid ei jõua kunagi deemonini või visatakse sissepoole tulemisel ära. Juhtühendus võib paista täiesti terve, samal ajal kui miski ei ületa andmete teed. Autentimine on ainus asi, mis tõestatavalt töötas.
Kirjutamisviga tähendab tavaliselt, et seanss läbirääkis midagi, mida kernel või klient ei saa kasutada. Juhtkanal lõppes ja selle vahetuse käigus kokku lepitud valikud ei vasta sellele, mida lõpp-punktid tegelikult teha saavad. See on konfiguratsioonierinevus, mitte autentimissündmus.
Lugege, kumb kahest ilmub, enne kui midagi muudate. Need viivad teid erinevatesse kihtidesse ja nende käsitlemine ühe sümptomina on põhjus, miks sama serverit plaastritakse kaks korda seotud põhjustel. Logirida on ainus tasuta diagnostika, mille saate.
Protokoll 47 ei ole port 47
PPTP kasutab kõne loomiseks TCP 1723 ja kasuliku koorma kandmiseks GRE. GRE on IP-protokoll 47, mitte pordi number, seega tulemüüri reegel, mis avab pordi 47, ei luba midagi kasulikku.
Marsruuteril teel on vaja PPTP passthrough funktsiooni või selget GRE luba. Ilma selleta lõpeb TCP käepigistus ja tunnel ei kanna kunagi paketti, mis tekitab täpselt ülaltoodud lugemisvea. Pordi 47 reeglid tulemüüris on selle protokolli kõige sagedamini raisatud pärastlõuna.
Jälgige serveris mõlemat suunda korraga, selle asemel et arvata, kumb pool liiklust ära viskab: tcpdump -ni any port 1723 or proto gre.
Kui 1723 näitab kõne loomist ja GRE jääb vaikseks, on blokeering hostist ülalpool. Kui GRE saabub ja deemon ikka ebaõnnestub, on probleem kohalik ja valikud on järgmine koht, kuhu vaadata.
Lubage GRE seal, kus host tegelikult edasi suunab
GRE jaoks forward-reegli lisamine on mõistlik test hostil, mis suunab tunneliliiklust edasi, ega ole poliitika. Testireegel, mis aktsepteerib kõike ühe protokolli kohta, on diagnostika, mitte disain. Jätke see piisavalt kauaks püsima, et midagi õppida, seejärel asendage see piiratud reegliga.
Lisage input-reegel serverile endale adresseeritud pakettide jaoks, sest forward-ahel ei näe neid. Seejärel jälgige reegli loendureid enne ja pärast ühenduse katset, mis ütleb, kas paketid üldse kohale jõuavad.
Tehke reegel püsivaks distributsiooni tulemüüriteenuse kaudu, selle asemel et käivitada see igal taaskäivitusel uuesti. nftables hostil sobitage ip protocol gre nii input- kui ka forward-ahelas.
Kinnitage, et ka moodul ppp_generic on laaditud, ja kontrollige, kas ühenduste jälgimine viskab tagasisuuna ära. Mõlemad tekitavad rikkeid, mis näevad välja nagu tulemüüri probleem ja ei ole seda. Puuduv kerneli moodul näeb täpselt välja nagu blokeeritud protokoll, kuni kontrollite.
Kohandage valikud kliendiga, mis teil tegelikult on
Teise raporti parandus asub failis /etc/ppp/pptpd-options, kus retsept keeldub PAP-ist, CHAP-ist ja MSCHAP-ist, kommenteerib vastavad require-read välja ja hoiab olekuga MPPE-d. See retsept kirjutati ühe kliendisegu jaoks ja pimesi kopeerimine rikub tavajuhu. Lugege keeldumisridu väitena selle kohta, millised kliendid autoril olid, mitte soovitusena.
Windowsi klient vajab tavaliselt MS-CHAPv2 koos MPPE-128-ga. Hoidke need nõuded ja eemaldage ainult need valikud, mida klient tõesti läbi rääkida ei saa.
# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128Krüpteerimise väljalülitamine ühenduse õnnestumiseks on alandamine, mitte parandus. Testige sellist varianti laborilingil ja taastage krüpteerimine enne, kui teenus kohtub päris klientidega. Ühendus, mis töötab ebaturvaliselt, on halvem kui see, mis ebaõnnestub ausalt.
Lugege kliendi vea numbrit
Kliendi numbriline kood kitsendab etappi kiiremini kui serveri logi. Lugege seda enne, kui loete midagi muud. 691 tähendab, et mandaadid lükati tagasi, 721 tähendab, et server ei vastanud kunagi, ja 619 tähendab, et ühendus katkes. Kaks minutit numbriga säästab tunni konfiguratsiooniga.
Võrrelge seda koodi serveri logiga enne, kui midagi muudate, ja testige iga muudatuse järel uuesti sama kliendiga. Muidu peidab teine rike end esimese taha ja parandus tundub ebaefektiivne.
Kui sisselogimine õnnestub ja liiklus ei liigu, jääb GRE kahtlusaluseks. See on hetk pöörduda tagasi püüdmise, mitte mandaadihoidla juurde.