Մեկ PPTP հաճախորդի երեք սխալի հաղորդագրությունները սովորաբար նկարագրում են երեք տարբեր խափանումներ։ 800 սխալը նշանակում է, որ թունելը երբեք չձևավորվեց, 812 սխալը նշանակում է, որ սերվերը մերժեց նույնականացման եղանակը, իսկ մեկ րոպե անց կտրումը keepalive ժամաչափ է, որը որոշում է, որ առողջ զուգընկերը գնացել է։ Յուրաքանչյուր փուլ ձախողվում է իր պատճառով, ուստի յուրաքանչյուրին պետք է իր ստուգումը։

800 սխալը նշանակում է, որ թունելը երբեք չձևավորվեց

Windows-ը 800 սխալ է բարձրացնում, երբ ընդհանրապես չի կարող կառուցել թունելը, իսկ անհասանելի սերվերի կամ ոչ պիտանի անվտանգության պարամետրերի մասին տեքստը ամփոփում է, ոչ թե ախտորոշում։ PPTP-ին ցանցից երկու առանձին բան է պետք, նախքան որևէ հավատարմագիր կստուգվի։ TCP 1723-ը կրում է կառավարման ալիքը, իսկ IP 47 արձանագրությունը՝ GRE-ն, կրում է ինկապսուլված բեռը։

Փորձարկեք այդ արտաքին ուղին ձեր սեփական LAN-ից դուրս, որովհետև գրասենյակում աշխատող կապը ոչինչ չի ապացուցում եզրի մասին։

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Եթե 1723-ը պատասխանում է, իսկ գրավումը դատարկ է մնում, մինչ հաճախորդը փորձում է միանալ, ուղին գցում է 47 արձանագրությունը։ 1723-ը փոխանցված, բայց PPTP-ի անցումը անջատված երթուղիչը տալիս է հենց այդ պատկերը՝ TCP ձեռքսեղմումը ավարտվում է, հետո GRE փաթեթները անհետանում են, այնպես որ խափանումը նմանվում է հավատարմագրի խնդրի, թեև ոչ մի մուտք չի փորձվել։

Ուղղեք փոխանցումը սերվերի ընթացիկ LAN հասցեին, միացրեք PPTP-ի անցումը այնտեղ, որտեղ երթուղիչը առաջարկում է, և նորից փորձեք նույն արտաքին կետից։ Երբ GRE-ն զտվում է վերևում և դուք չեք կարող դա փոխել, SSTP-ն TCP 443-ի վրա կամ L2TP/IPsec-ը UDP 500 և 4500-ի վրա ավելի լավ հնարավորություն ունի, քան Windows-ի կողմում ձեր ցանկացած փոփոխությունը։

812 սխալը սերվերի կողմից ձեր նույնականացման եղանակի մերժումն է

812 սխալը վերադառնում է այն բանից հետո, երբ թունելը վեր է կանգնել, դրա համար էլ այն թվում է գաղտնաբառի խնդիր։ Սերվերը մերժում է կապի համար պայմանավորված նույնականացման եղանակը, ոչ պարտադիր հենց գաղտնաբառը։ Հաճախորդում բացեք VPN մուտքը, անցեք անվտանգության ներդիրին, տեսակը դրեք Point-to-Point Tunneling Protocol, ընտրեք հստակ արձանագրությունների ցանկը և նշեք Microsoft CHAP տարբերակ 2-ը։

Ընթացիկ կարգավորումը կարող եք կարդալ առանց երկխոսության մեջ սեղմելու։

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2 պահանջող սերվերը մերժում է PAP-ի վրա կամ ավտոմատ տեսակի վրա թողնված հաճախորդին, որը պայմանավորվում է ավելի թույլ բանի շուրջ, և սխալը գալիս է նախքան օգտվողի որևէ գաղտնաբառի գնահատումը։ Հաշվի ձևաչափը նույն մերժման մյուս կեսն է։ Մի դեպքում Windows-ը ուղարկեց MicrosoftAccount\[email protected] ձևի Microsoft հաշվի ինքնություն, մինչ սերվերը ցանկանում էր տեղական կամ տիրույթի հաշիվ։ SERVERNAME\username մուտքագրելը Windows-ին ասաց, թե որ հաշիվների պահոցին դիմել, և վերացրեց սխալը։ Անունը մուտքագրեք ձեռքով, փոխարենը թույլ տալու պահված հավատարմագրին կրկնել նախորդ ձևաչափը։

Մեկ րոպե անց կտրումները keepalive որոշում են

Երբ թունելը միանում է, մի փոքր երթևեկություն բաց թողնում և հետո անջատվում, նախքան հաճախորդին դիպչելը նայեք սերվերի LCP արձագանքի պահվածքին։ Դեմոնը պարբերաբար խնդրում է զուգընկերոջը հաստատել, որ նա դեռ այնտեղ է։ Եթե սահմանված բյուջեի ընթացքում շատ քիչ պատասխաններ են գալիս, նստաշրջանը քանդվում է, թեև օգտվողը դեռ աշխատող կապ ունի։

Linux pptpd սերվերի վրա այդ արժեքները ապրում են /etc/ppp/options.pptpd-ում, և սովորական վերանորոգումը բյուջեն լայնացնելն է, ոչ թե ինտերվալը կրճատելը։

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Հինգ վայրկյան ինտերվալով երեսուն բաց թողնվածը ներում է կարճ կանգառը՝ փոխարենը զուգընկերոջը գնացած հայտարարելու։ Թիվը մեկ կամ երկուսի իջեցնելը թարգմանված ուղու սովորական ցնցումը դարձնում է մոտավորապես ամեն րոպե անջատում։ Եթե ձեր սերվերը pptpd-ի փոխարեն Windows RRAS է, փոխարենը նայեք PPP նստաշրջանի ժամանակի սահմանին և պարապ վիճակում անջատելու քաղաքականությանը։ Դրանք ապրում են այլ տեղ, և գոյություն չունեցող pppd ֆայլը խմբագրելը ոչինչ չի փոխի։

Համընկնող ենթացանցերը կոտրում են տվյալների ուղին

PPTP թունելը կարող է մաքուր նույնականացվել և այնուամենայնիվ ոչ մի տեղ չհասնել, երբ երկու տեղամասերն օգտագործում են նույն մասնավոր տիրույթը, օրինակ՝ 192.168.1.0/24-ը գրասենյակում և տանը։ Հաճախորդը չի կարող ասել, թե տրված հասցեն որ հոսթին է վերաբերում, և որոշ կույտեր ընդհանրապես հրաժարվում են տեղադրել երթուղին՝ փոխարենը մեկը ընտրելու։

Դա համարեք նախագծման թերություն և վերահամարակալեք մի կողմը, կամ հաճախորդին տվեք դիտավորյալ թարգմանված մուտքի տիրույթ։ PPTP հաճախորդի վրիպազերծումը չի կարող ուղղել երկու անգամ գոյություն ունեցող հասցեային տարածությունը, և ախտանիշը կշարունակի նմանվել պատահական կտրման։

Սկսեք այն փուլից, որը ձախողվեց՝ GRE-ն 800-ի համար, եղանակն ու հաշվի տողը 812-ի համար, արձագանքի կարգավորումները ժամանակացույցով մահացող թունելի համար։

Առնչվող հոդվածներ