Ինչու OpenVPN պրոֆիլը տանը աշխատում է, իսկ հյուրանոցում՝ ոչ

Գրասենյակի Wi-Fi-ը և հյուրանոցային սենյակը կարող են նույն նոութբուքին տալ երկու բոլորովին տարբեր ցանցեր, և նրանց միջև գտնվող պրոֆիլը այդ մասին ոչինչ չգիտի։ Այն, ինչ աշխատում է տանը, ենթադրում է թույլատրող վերին կապուղի, աշխատող անվանման լուծում և տեղական ենթացանց, որը չի բախվում թունելի փոխադրած ոչնչի հետ։ Այդ ենթադրություններից յուրաքանչյուրը կարող է առանձին ձախողվել։

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

Չորս ցանցային փաստ փոխվում են վայրերի միջև

Առաջին փաստն այն է, թե տեղական ցանցը ձեզ ընդհանրապես դուրս է թողնում արդյոք։ Մուտքի պորտալը սարքին ներս է թողնում մուտքի էջով և արգելափակում է մնացած ամեն ինչ, քանի դեռ էջը լրացված չէ, ինչը նշանակում է՝ թունելը չի կարող սկսվել, որքան էլ պրոֆիլը ճիշտ լինի։

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

Երրորդը տրանսպորտի զտումն է։ Ցանցերը, որոնք ուզում են թույլատրել միայն զննարկում, անցկացնում են TCP 443-ը դեպի կամայական նշանակակետեր և գցում են գրեթե մնացած ամեն ինչ, ներառյալ UDP-ն։

Չորրորդը հասցեավորումն է։ Տեղական ենթացանցը կարող է համընկնել թունելի հետևի ցանցի հետ, կամ վերին կապուղին ընդհանրապես ոչ մի օգտագործելի IPv4 ուղի չի տրամադրում։

Անվանման լուծումը և մուտքի պորտալը

Պրոֆիլում հոսթի անունը փոխարինեք սերվերի թվային հասցեով և նորից փորձեք։ Եթե IP-ն միանում է, իսկ անունը՝ ոչ, մեղավոր է անվանման լուծումը, և պրոֆիլն ինքնին կարգին է։

VPN-ին դիպչելուց առաջ բացեք դիտարկիչ և փորձեք սովորական HTTP էջ։ Մուտքի էջ վերահասցեավորումը նշանակում է, որ պորտալը դեռ սպասում է. ավարտեք այն, ապա նորից միացեք։ Շատ հյուրանոցներ նաև մի քանի ժամից ավարտում են նստաշրջանը, ինչը կեսօրյա անջատման տեսք ունի, ոչ թե մուտքի խնդրի։

Եթե թվային հասցեն նույնպես ձախողվում է, անվանման լուծումը բացատրություն չէ, ուրեմն անցեք տրանսպորտին։ Պահեք ձեր ստուգած հասցեն, որովհետև այն հաջորդ ստուգմանն ասում է՝ փաթեթները ընդհանրապես լքե՞լ են մեքենան։

Տրանսպորտի զտում. սկզբում UDP, TCP 443 որպես պահուստ

UDP 1194-ի վրայով OpenVPN հոսքը նման չէ որևէ բանի, ինչ հյուրանոցային հրամուրք ճանաչում է, ուստի այն գցվում է առանց սխալի։ Հաճախորդը կրկնում է փորձը մինչև իր ժամկետի լրանալը, և օգտատերը տեսնում է կապ, որը երբեք չի հաստատվում, այլ ոչ թե մերժում։ Նման վարվող հրամուրքերը հազվադեպ են գրանցում գցումը տեսանելի տեղում։ Մերժման բացակայությունն ինքնին հուշում է։

TCP 443-ը հուսալի պահուստն է, քանի որ ցանցը չի կարող այն տարբերել սովորական HTTPS-ից։ Օգտագործեք օպերատորի TCP պրոֆիլը, երբ այն կա, քանի որ սերվերը նույնպես պետք է լսի այդ տրանսպորտով և պորտով. փոխելով միայն հաճախորդը՝ ստանում եք այլ տեսակի ձախողում։ Եթե TCP պրոֆիլ չկա, հարցրեք օպերատորին՝ պորտը խմբագրելով նորը հորինելու փոխարեն։ Սերվերի կողմը նույնպես պետք է համաձայնի, և անհամապատասխանությունը կրկին հրամուրքի խնդրի տեսք ունի։

Սպասեք արդյունավետության գնի։ TCP-ն TCP-ի ներսում ուժեղացնում է կրկնակի փոխանցումները կորուստներով կապուղում, ուստի աշխատող TCP թունելը կարող է դեռ դանդաղ թվալ ծանրաբեռնված հյուրանոցային ցանցում։ Սա հասանելիության փոխանակում է, ոչ թե հետապնդելի թերություն։

Հասցեների բախումներ և IPv4-ից զուրկ վերին կապուղիներ

Թունելը կարող է հաստատվել և այնուամենայնիվ ոչինչ չփոխադրել։ Երբ տեղական LAN-ը և հեռավոր ցանցը կիսում են այնպիսի նախադիր, ինչպիսին 192.168.1.0/24-ն է, հաճախորդը հեռավոր հոսթը համարում է ուղիղ միացված և փաթեթն ուղարկում է տեղական կապուղուն՝ թունելի փոխարեն։ Ախտանիշը հաջող կապն է մեկ անհասանելի ենթացանցով, ինչը հեշտ է սխալ կարդալ որպես սերվերի կողմի երթուղու խնդիր։

Մշտական լուծումը հեռավոր LAN-ը անսովոր մասնավոր տիրույթ տեղափոխելն է։ Տանը ոչ ոքի չօգտագործած տիրույթ ընտրելը, օրինակ 10.42.0.0/24-ը, կանխում է խնդիրը մեկի փոխարեն յուրաքանչյուր ապագա վայրի համար։ Տեղական շրջանցումը այդ հյուրանոցից, հոթսփոթից կամ երթուղիչից խուսափելն է, ինչն ամենևին լուծում չէ։

Բջջային վերին կապուղիները երկու տարբերակ են ավելացնում։ Օպերատորի մակարդակի NAT-ը նշանակում է, որ մուտքային կապերը չեն հասնում, ինչը կարևոր է, եթե սերվեր եք հյուրընկալում, բայց ոչ ելքային հաճախորդի համար։ NAT64 թարգմանությամբ միայն IPv6-ով կարգավորված APN-ը կարող է ձախողել հաճախորդին, որը պահանջում է իրական IPv4 ուղի, և սովորական միջոցը APN արձանագրությունը IPv4 կամ կրկնակի կույտի փոխելն է։

Ախտանիշներ թունելի բարձրանալուց հետո

Թունելը, որը միանում է և հետո լռում, սովորաբար keepalive-ի կամ MTU-ի խնդիր է, ոչ արգելափակված պորտ։ Կապը, որն ընկնում է ֆիքսված րոպեներից հետո, մատնանշում է keepalive-ի կամ վերաբանակցման ժամաչափ։ Կարգավորեք հաճախորդին ստուգել իր զուգընկերոջը և վերսկսվել, երբ պատասխանները դադարեն, և փորձեք ավելի փոքր թունելի MTU, եթե ping-երը անցնում են, բայց մեծ փոխանցումները կանգ են առնում։

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