Hitilafu za uandishi wa GRE kwenye pptpd si tatizo la nenosiri

Hitilafu ya uandishi wa GRE kwenye kumbukumbu, na silika ya kwanza ni kuweka upya nenosiri la mtumiaji. Silika hiyo ni mbaya karibu kila wakati. Jumbe hizi zinaelezea njia ya data, si ukaguzi wa vitambulisho: mteja anaweza kuwa amejithibitisha kwa mafanikio na kisha kukwama katika hatua anayojisajili kwenye mtandao. Jumbe mbili tofauti zinaonyesha hitilafu mbili tofauti, na hakuna inayotatuliwa kwa nenosiri jipya.

Jumbe mbili, hitilafu mbili tofauti

Hitilafu ya kusoma inamaanisha kwamba pakiti za GRE hazifikii daemon, au zinatupwa wakati wa kuingia. Muunganisho wa udhibiti unaweza kuonekana mzima kabisa wakati hakuna kinachovuka njia ya data. Uthibitishaji ndio kitu pekee kilichofanya kazi kwa uthibitisho.

Hitilafu ya uandishi kwa kawaida inamaanisha kikao kilijadili kitu ambacho kernel au mteja hawawezi kutumia. Kituo cha udhibiti kilikamilika, na chaguo zilizokubaliwa wakati wa mabadilishano hayo haziendani na kile ambacho ncha za mwisho zinaweza kufanya kwa kweli. Hii ni kutokubaliana kwa usanidi, si tukio la uthibitishaji.

Soma ni ipi kati ya hizo mbili inaonekana kabla ya kubadilisha chochote. Zinakupeleka kwenye tabaka tofauti, na kuzichukulia kama dalili moja ndio sababu seva hiyo hiyo inarekebishwa mara mbili kwa sababu zisizohusiana. Mstari wa kumbukumbu ndio utambuzi pekee wa bure unaoupata.

Itifaki 47 si bandari 47

PPTP hutumia TCP 1723 kuanzisha simu na GRE kubeba mzigo. GRE ni itifaki ya IP 47, si namba ya bandari, kwa hivyo kanuni ya firewall inayofungua bandari 47 hairuhusu kitu chochote cha maana.

Kipanga njia kilicho njiani kinahitaji kipengele cha passthrough cha PPTP au idhini ya wazi ya GRE. Bila hiyo, makubaliano ya TCP yanakamilika na handaki haibebi pakiti kamwe, jambo ambalo hutoa hitilafu ya kusoma iliyo juu. Kanuni za bandari 47 kwenye firewall ni mchana uliopotea zaidi katika itifaki hii.

Angalia pande zote mbili kwa wakati mmoja kwenye seva badala ya kukisia upande gani unatupa trafiki: tcpdump -ni any port 1723 or proto gre.

Ikiwa 1723 inaonyesha uanzishaji wa simu wakati GRE inakaa kimya, kizuizi kiko juu ya mwenyeji. Ikiwa GRE inafika na daemon bado inashindwa, tatizo ni la ndani na chaguo ndio mahali pa kuangalia baadaye.

Ruhusu GRE mahali mwenyeji anapeleka kwa kweli

Kuingiza kanuni ya forward kwa GRE ni jaribio la busara kwenye mwenyeji anayepeleka trafiki ya handaki, na si sera. Kanuni ya jaribio inayokubali kila kitu cha itifaki moja ni utambuzi, si muundo. Iache kwa muda wa kutosha kujifunza kitu, kisha ibadilishe na kanuni iliyopunguzwa.

Ongeza kanuni ya input kwa pakiti zinazoelekezwa kwa seva yenyewe, kwa sababu mnyororo wa forward hauzioni. Kisha angalia vihesabu vya kanuni kabla na baada ya jaribio la muunganisho, jambo linalokuambia kama pakiti zinafika kabisa.

Fanya kanuni iwe ya kudumu kupitia huduma ya firewall ya usambazaji badala ya kuiendesha tena baada ya kila kuwasha upya. Kwenye mwenyeji wa nftables, linganisha ip protocol gre kwenye mnyororo wa input na wa forward.

Thibitisha kwamba moduli ya ppp_generic pia imepakiwa, na angalia kama ufuatiliaji wa muunganisho unatupa mwelekeo wa kurudi. Zote mbili huzalisha hitilafu zinazoonekana kama tatizo la firewall na sivyo. Moduli ya kernel inayokosekana inaonekana sawa na itifaki iliyozuiwa hadi uangalie.

Linganisha chaguo na mteja ulio nao kwa kweli

Marekebisho kutoka ripoti nyingine yako katika /etc/ppp/pptpd-options, ambapo kichocheo kinakataa PAP, CHAP na MSCHAP, kinatoa maoni kwenye mistari ya require inayolingana na kinahifadhi MPPE yenye hali. Kichocheo hicho kiliandikwa kwa mchanganyiko mmoja wa wateja, na kunakili kwa upofu huvunja hali ya kawaida. Soma mistari ya kukataa kama tamko kuhusu wateja aliokuwa nao mwandishi, si kama pendekezo.

Mteja wa Windows kwa kawaida anahitaji MS-CHAPv2 pamoja na MPPE-128. Hifadhi mahitaji hayo na uondoe tu chaguo ambazo mteja hawezi kujadili kwa kweli.

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

Kuzima usimbaji fiche ili muunganisho ufanikiwe ni kushusha kiwango, si ukarabati. Jaribu lahaja kama hiyo kwenye kiungo cha maabara, kisha rejesha usimbaji fiche kabla huduma haijakutana na wateja halisi. Muunganisho unaofanya kazi kwa njia isiyo salama ni mbaya kuliko ule unaoshindwa kwa uaminifu.

Soma namba ya hitilafu ya mteja

Msimbo wa namba wa mteja hupunguza hatua kwa kasi zaidi kuliko kumbukumbu ya seva. Soma kabla ya kusoma kitu kingine chochote. 691 inamaanisha vitambulisho vilikataliwa, 721 inamaanisha seva haikujibu kamwe, na 619 inamaanisha muunganisho ulikatika. Dakika mbili na namba huokoa saa moja na usanidi.

Linganisha msimbo huo na kumbukumbu ya seva kabla ya kuhariri chochote, na ujaribu tena na mteja huyo huyo baada ya kila mabadiliko. Vinginevyo hitilafu ya pili inajificha nyuma ya ya kwanza na marekebisho yanaonekana hayafai.

Wakati kuingia kunafanikiwa na hakuna trafiki inayosonga, GRE bado ni mshukiwa. Huo ndio wakati wa kurudi kwenye kunasa badala ya hifadhi ya vitambulisho.