OpenVPN-ը աշխատում է տանը, բայց ոչ մեկ ցանցում՝ UDP թե TCP։

Նույն պրոֆիլը տնից միանում է և կանգ է առնում հյուրանոցային, համալսարանական կամ մասնաճյուղային ցանցում։ Մուտքի տվյալները չեն փոխվել, ուստի հետաքրքիր փոփոխականը ուղին է՝ ինչ է պատահում փաթեթներին նախքան OpenVPN դրանք կարդալը։ Չորս հնարավոր պատճառների համեմատությունը այն հերթականությամբ, որով դրանք կարելի է ստուգել, ավելի լավ է, քան վկայագրերի շուրջ գուշակելը։ Յուրաքանչյուրը տարբեր հետք է թողնում, և հենց հետքն է դրանք բաժանում։

Որ փուլը ձախողվեց, ցույց է տալիս, թե որ համեմատությունն է կարևոր

Հաճախորդի մատյանն արդեն գրանցում է, թե որքան հեռու հասաք։ Տողը, որ ասում է, թե TLS բանալու բանակցությունը չկայացավ ժամկետի ընթացքում, նշանակում է, որ առաջին փաթեթը դուրս եկավ, և ոչ մի օգտակար բան չվերադարձավ, ինչը մատնանշում է ուղին։ Վկայագրի մերժումը բոլորովին այլ տեսք ունի՝ պատասխան է գալիս, ապա կոնկրետ ստուգման սխալը նշում է պատճառը։ Ուշադրություն դարձրեք կրկնափորձի ցիկլից առաջ վերջին տողին, որովհետև հենց այդ արժեքն եք համեմատում ցանցերի միջև։

Ձայնագրեք կրկնափորձի ընթացքում, ոչ թե հետո։ Հաճախորդի վրա tcpdump -ni any udp port 1194 ցույց է տալիս՝ ընդհանրապես պատասխան վերադառնում է, թե ոչ։ Կրկնեք դա ձեր կառավարած սերվերի WAN միջերեսում, ինչը բացահայտում է՝ այդ փաթեթները հասնում են հեռավոր ծայրին, թե ոչ։

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

UDP-ի զտումը՝ փակ պորտի դիմաց

Շատ մուտքի ցանցեր շարունակական UDP-ն կասկածելի են համարում, և որոշ ISP-ներ համաձայն են նրանց հետ։ Փակ պորտը հաճախորդի կողմից ստեղծում է նույն լռությունը։ Տարբերությունը ընտրողականության մեջ է. զտիչը հակված է ընտրելու, թե որ նպատակակետերն ու պորտերն է գցում, մինչդեռ փակ պորտը մերժում է այդ մեկ պորտին ուղղված ամեն ինչ։

443 պորտի TCP պրոֆիլը սովորական լուծումն է, որովհետև այն նման է սովորական HTTPS հոսքի և անցնում է կապտիվ պորտալների ու ելքի զտիչների մեծ մասով։ Երկու պայման պետք է պահպանվի։ Սերվերը պետք է լսի proto tcp-server-ով, իսկ հաճախորդը պետք է համապատասխանի proto tcp-client-ով, և օպերատորը պետք է հրապարակի այդ այլընտրանքային վերջնակետը։ Աշխատող UDP պրոֆիլը վերաշարադրելը, որ պնդի TCP 443, ոչ մի տեղ չի հասնում, երբ մյուս ծայրում ոչ ոք չի լսում։

Փակ պորտը կազմաձևման խնդիր է, ոչ թե գրաքննության։ Տնային երթուղիչի հետևում գտնվող սերվերը պահանջում է UDP պորտի փոխանցում, և երթուղիչի firewall-ը պետք է դա թույլատրի։ Երբ պորտը երբեք չի թույլատրվել, յուրաքանչյուր հաճախորդ ձախողվում է բանակցության ժամանակ՝ անկախ մուտքի տվյալներից, և ձախողումը հետևում է սերվերին, ոչ թե ցանցին։

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

Երբ կոմուտատորն է, որ գցում է փաթեթները

Կառավարվող կոմուտատորը կարող է դիտմամբ գցել թունելը։ HPE-ի և Aruba-ի որոշ մոդելներ ընդլայնված անվտանգության բաժնում առաջարկում են UDP հեղեղումների պաշտպանության կառավարում, երբեմն Prevent UDP Blat Attack պիտակով։ Երբ այդ կառավարումն ակտիվ է, կոմուտատորի հետևում գտնվող սերվերը ոչինչ չի պատասխանում, և յուրաքանչյուր հաճախորդ նույն կերպ հասնում է ժամկետի ավարտի։ Այն անջատելը և ընթացիկ կազմաձևը պահելը ողջ վերանորոգումն է, բայց միայն այն բանից հետո, երբ հաստատեք, որ կոմուտատորն իսկապես ուղու վրա է։

Հակափաստարկներն են, որ տարբերում են կոմուտատորի գցումը մատակարարի արգելափակումից։ Կարդացեք միջերեսի հաշվիչները և հեղեղումների պաշտպանության մատյանը՝ նախքան ISP-ի մոտ տոմս բացելը։ DoS կամ հեղեղումների պաշտպանությամբ սպառողական երթուղիչները ձախողվում են նույն ձևով, և նույնը՝ ցանկացած միջանկյալ սարք՝ UDP-ի կարճ անգործության ժամկետով։ Ձեռքսեղմումը, որը երբեք չի ավարտվում, ցույց է տալիս գցում, մինչդեռ մի քանի րոպե լռությունից հետո մահացող թունելը՝ ժամկետը։

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

Հասցեների վերադրում, որը նման է DNS ձախողմանը

10.0.0.0/8-ի ներսում համարակալված մուտքի ցանցը կարող է վերադրվել թունելի լողավազանին, և լուծիչը սովորաբար ապրում է այդ լողավազանի ներսում։ Երբ նոութբուքը Wi-Fi-ում ստանում է 10.184.178.50-ի նման հասցե /8 դիմակով, 10.x-ի յուրաքանչյուր նպատակակետ ըստ սահմանման տեղական է։ 10.4.0.1-ի փաթեթներն այնուհետև գնում են LAN, թունելը մնում է բարձրացված, և անունների լուծումը ձախողվում է։

ip addr մեկ հայացքով բացահայտում է վերադրումը, և ip route get 10.4.0.1 ցույց է տալիս, թե որտեղ իրականում կհանձնվեր փաթեթը։ Քանի որ տեսանելի ախտանիշը լուծիչի ձախողումն է, այս դեպքը հաճախ վերապրում է DNS փոփոխությունների մի քանի փուլ։

Վերահամարակալեք լողավազանը կամ այդ մուտքի ցանցը պահեք շրջանակից դուրս։ Հաճախորդի կողմի ոչ մի կարգավորում չի վերականգնվում վերադրումից։

Ընտրություն TCP պահուստի և ուղու ուղղման միջև

Ընտրեք TCP պահուստը, երբ չեք վերահսկում ուղին, և օգտատերերը պետք է աշխատեն այսօր, և ընդունեք դրա ծախսերը. TCP-ն TCP-ի ներսում վատ է վարվում կորուստներով գծերում, և պահուստը պահանջում է լսող, որը դուք եք շահագործում։ Ընտրեք ուղու ուղղումը, երբ արգելափակումը ձեր սեփական ենթակառուցվածքի վրա է, որովհետև firewall-ի կանոնն ավելի էժան է, քան երկրորդ լսողը։ Ամեն դեպքում անցեք շերտերով հերթականությամբ՝ կապ, արտաքին տրանսպորտ, բանակցություն, ներքին երթուղավորում։ Այն փուլը, որը ձախողվեց այդ ցանցում, միակ կարևոր փաստն է։

Արդյունքը գրանցեք ըստ ցանցի, ոչ ըստ օգտատիրոջ։ Նույն ձախողման հաջորդ հաշվետվությունն այնուհետև սկսվում է հայտնի փուլից՝ վկայագրի տեսության փոխարեն։ Այդ գրառումն է նաև, որ արդարացնում է մշտական երկրորդ լսողը, եթե երբևէ անհրաժեշտ լինի։