Seva ya PPTP nyuma ya ruta ya nyumbani: rekebisha 1723 na GRE kwanza

PPTP nyuma ya ruta ya nyumbani inashindwa kwa njia mbili zisizohusiana, na kuzichanganya kunagharimu jioni nzima. Hitilafu moja ni pengo katika upelekaji: ruta inaruhusu TCP 1723 kupita na kutupa itifaki ya IP 47, kwa hiyo mteja anabaki ametundikwa kwenye hitilafu 619. Nyingine ni tatizo la ukubwa: handaki inainuka, inathibitishwa, kisha inaganda wakati pakiti ya ukubwa kamili inapaswa kupita. Kujua ni ipi kati ya hizo unayo ni hatua ya kwanza ya kweli; iliyobaki inalinganisha kile ruta yako inaweza kueleza, sio chapa ipi ni bora.

Wasafirishaji wawili, na mmoja tu ana bandari

PPTP inagawanyika katika wasafirishaji wawili: muunganisho wa udhibiti kwenye TCP 1723, na fremu za PPP zilizofungwa katika GRE iliyopanuliwa, ambayo ni itifaki ya IP 47. GRE haina namba ya bandari, kwa hiyo kanuni iliyoandikwa kama upelekaji wa bandari 1723 haiwezi kuifunika, kivyovyote kiolesura cha wavuti kinavyoita uwanja huo. Ruta ya nyumbani kwa kawaida hutoa kisanduku kinachoitwa upitishaji wa PPTP badala ya kanuni ya itifaki, na kisanduku hicho hufanya kazi mbili: huruhusu itifaki 47 kupita kwenye ukuta wa moto, na hufundisha NAT kufuata mtiririko wa GRE. Kwenye ruta ya Linux kazi hizo ni moduli tofauti na kanuni tofauti, ndiyo sababu upitishaji uliosanidiwa nusu bado hutoa chaneli ya udhibiti inayofanya kazi. Gundua ni nusu ipi iliyopo kabla ya kubadilisha chochote.

Ukuta wa moto wa seva yenyewe pia lazima uruhusu itifaki 47 kutoka anwani ya ruta. Ukuta wa moto wa mwenyeji unaokubali 1723/tcp pekee huzalisha tena hitilafu 619 kutoka ndani ya LAN, jambo linalofanya upelekaji uliovunjika na kanuni ya mwenyeji iliyovunjika zionekane sawa.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Ikiwa moduli hazipo, zipakie kwa sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre na ufanye upakiaji kuwa wa kudumu, kwa sababu kuwasha upya kunakosahau msaidizi hurudisha handaki inayofanya kazi kwenye hitilafu 619. Kanuni ya upelekaji inapaswa kukubali itifaki 47 kuelekea anwani ya seva pekee, sio LAN nzima. Ufafanuzi katika RFC 2637 hutenganisha njia ya udhibiti na ya data, ndiyo sababu hakuna skrini moja ya upelekaji wa bandari inayoelezea PPTP kikamilifu.

Kisanduku cha upitishaji au kanuni bayana ya itifaki

Kisanduku cha upitishaji kinachofungua ukuta wa moto pekee kiko karibu na kilicho sahihi kuliko ALG inayoandika upya vitambulisho vya simu. Nusu ya ukuta wa moto inatabirika, kwa sababu itifaki 47 inakubaliwa au inatupwa, na vihesabu vinaeleza ipi. Nusu ya uandikaji upya ni mahali ambapo watengenezaji wanatofautiana, kwa sababu vitambulisho vya simu vya PPTP ni vya kila handaki na NAT inayovihariri lazima ifuate kila simu inayogusa. Wateja mmoja wanapounganishwa na wawili hawajaunganishwa, ALG ndiye mtuhumiwa wa kwanza.

Kanuni ya NAT ya lengo kwa 1723 pia ina tatizo la umiliki. Ikiwa kanuni ya zamani bado inatuma 1723 kwa mwenyeji aliyeacha kuendesha seva, pakiti zinaanguka kwenye bandari iliyofungwa na huduma ya PPTP ya ruta yenyewe inaacha kujibu, jambo linalosomwa kama kushindwa kwa ukuta wa moto lakini kwa kweli ni lengo lililopitwa na wakati. Soma kanuni na lengo lake kabla ya kuongeza ya pili. Kwenye ruta zinazomaliza PPTP zenyewe, kanuni ya WAN inashindana na huduma iliyojengwa ndani, kwa hiyo chagua mmiliki mmoja kwa 1723 na itifaki 47.

Wateja wawili nyuma ya NAT moja ndiyo kesi inayotenganisha upelekaji rahisi na wenye werevu. Kupeleka itifaki 47 bila kuandika upya vitambulisho vya simu kwa kawaida hufanya vizuri zaidi kuliko msaidizi anayejaribu kuvirekebisha.

Pima handaki kabla ya kulaumu ruta

PPTP hupunguza mzigo muhimu, na upungufu huo ni hesabu, sio fumbo. Kila pakiti ya handaki hubeba kichwa cha IP cha nje, kichwa cha GRE kilichopanuliwa, kichwa cha PPP na, pamoja na usimbaji fiche, kichwa cha MPPE. Wakati njia haiwezi kubeba fremu inayotokana, pakiti ndogo hupita, kuingia hukamilika, na kikao huacha mara ya kwanza uhamishaji wa faili au kupeana mkono kwa TLS kunapotuma pakiti ya ukubwa kamili.

Hesabu namba badala ya kukisia. GRE iliyopanuliwa hugharimu baiti 8, PPP hugharimu 4, MPPE hugharimu 4, na kichwa cha IP cha nje hugharimu 20, kwa hiyo handaki hula baiti 36 kabla ya mzigo wowote. Kwenye WAN ya PPPoE inayoishia 1492, PPP MTU kubwa zaidi inayotoshea ni 1492 toa 36, yaani 1456. Weka mtu na mru kwenye thamani hiyo katika chaguo za PPP na ujaribu tena kwa ping bila kugawanya.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Ping hupima njia, sio handaki: baiti 1464 za mzigo pamoja na baiti 28 za vichwa vya IP na ICMP hujaza fremu ya baiti 1492 kwa usahihi. Ikiwa ping hiyo itashindwa, punguza namba hadi ipite kisha toa 36 kutoka kwa matokeo. MTU ya handaki iliyowekwa juu ya kikomo cha njia huzalisha kuganda bila mstari mmoja wa kumbukumbu unaotaja ukubwa.

PPTP, L2TP/IPsec au OpenVPN kwenye ruta moja

Ruta hiyo hiyo inaweza kubeba yoyote ya handaki tatu za kawaida, na tofauti ni kile inachopaswa kueleza. PPTP inahitaji kanuni mbili katika tabaka mbili tofauti. L2TP juu ya IPsec inahitaji UDP 500 na 4500 kwa kubadilishana funguo na, isipokuwa NAT-T iibebe, itifaki 50 kwa mzigo. OpenVPN inahitaji bandari moja ya UDP na hakuna msaidizi kabisa.

Safu ya L2TP si rafiki kwa moja kwa moja kuliko GRE. ESP ni itifaki ya IP 50 na pia haina bandari, kwa hiyo ruta inayopata shida na itifaki 47 inaweza kupata shida na itifaki 50 kwa sababu hiyo hiyo. NAT-T ipo ili kufunga ESP ndani ya UDP 4500, na pande zote mbili zinapoiunga mkono kanuni ya itifaki 50 inakuwa isiyo ya lazima. Hiyo ni sifa ya ncha, sio ya kisanduku cha PPTP cha ruta. Thibitisha usimbaji gani mteja alijadiliana kweli kabla ya kuandika kanuni kwa zote mbili.

OpenVPN ni chaguo lenye sehemu chache zinazosogea upande wa ruta. Bandari moja ya UDP, upelekaji mmoja, hakuna msaidizi wa kufuatilia miunganisho na hakuna kuandika upya vitambulisho vya simu. Ubadilishanaji ni mteja anayepaswa kusakinishwa badala ya kipiga simu kilichojengwa ndani, na mara nyingi hiyo ndiyo sababu pekee ambayo PPTP inabaki kwenye mazungumzo.

Nini cha kurekebisha na nini cha kubadilisha

Kurekebisha upelekaji na MTU hukupa handaki inayofanya kazi, sio ile unayopaswa kuihifadhi. Uthibitishaji wa MSCHAPv2 wa PPTP umekuwa shambuliwa kwa miaka, na handaki inayofanya kazi huhamisha vitambulisho vinavyoweza kurejeshwa nje ya mtandao. Ikiwa kifaa cha mbali kinaweza kuendesha L2TP/IPsec au OpenVPN, chukua ukarabati kama hatua ya muda iliyo na tarehe.

Uamuzi unategemea kile ncha ya mbali inaunga mkono na mpango unapaswa kudumu kwa muda gani. Kifaa cha zamani kinachozungumza PPTP pekee kinapata ukarabati; kila kitu kinachoweza kusakinisha mteja huhamishwa.

Kabla ya kufunga tikiti, thibitisha mteja anastahimili uhamishaji mkubwa na sio kuingia pekee, na ruta bado inashikilia kanuni yake ya itifaki 47 baada ya kuwasha upya. Handaki inayopita nakala moja ya faili na kufa baada ya sasisho la firmware linalofuata haikukamilika kamwe.