UDP-ն միշտ ավելի արագ չէ. OpenVPN-ի տրանսպորտի ընտրությունը

Բոլոր ուղեցույցներն ասում են, որ OpenVPN-ի համար UDP-ն ավելի լավն է, քան TCP-ն, և այդ խորհուրդը լռելյայն ընտրություն է, ոչ չափում։ Տրանսպորտը փոխում է, թե ինչպես են փաթեթները հասցվում և ինչ է լինում, երբ ուղին դեն է նետում դրանք, ոչ թե ինչպես է գաղտնագրվում թունելը։ Captive portal-ի կամ միայն 443 պորտը թույլատրող պրոքսիի ետևում դանդաղ տարբերակն է այն, որն ընդհանրապես միանում է։ Հետևյալը բաժանում է այն, ինչ անում է արձանագրությունը, նրանից, ինչ թույլատրում է ձեր մուտքի ցանցը։

Ինչ է իրականում փոխում տրանսպորտը

TCP-ն ապահովում է հուսալի, դասավորված բայթային հոսք և վերստուգում է կորցրածը, ինչպես սահմանում է RFC 9293-ը։ UDP-ն տվյալագրման միավորները հանձնում է ցանցին, և OpenVPN-ն այդ սոքեթի վրա աշխատացնում է իր հուսալիության շերտը։ TCP-ն TCP-ի մեջ փաթեթավորելը կուտակում է երկու վերականգնող օղակ, ուստի մեկ կորցրած սեգմենտը կարող է պահել ներքին հոսքը, մինչև արտաքին վերահաղորդումը հասնի։ Հենց այդ փոխազդեցությունն է UDP-ի օգտին իրական փաստարկը, և այն դրսևորվում է որպես ուշացում, ոչ թե որպես թողունակություն։

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

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

Որտեղ է TCP-ն վաստակում իր տեղը

Մուտքի ցանցերը TCP-ն ընտրելու սովորական պատճառն են։ Հյուրանոցը, օդանավակայանը կամ հյուրային ցանցը կարող է թույլատրել ելքային 443-ը և դեն նետել մնացած ամեն ինչ, և այդ պորտի TCP լսողը միակ աշխատող պրոֆիլն է։ Դա հասանելիություն է, ոչ արտադրողականություն, և ինքնին բավական լավ պատճառ է։

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

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

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

Ստուգեք, թե որ լսողն ունեք իրականում

Նախքան արտադրողականությունը համեմատելը հաստատեք, որ երկու կողմերը համաձայն են տրանսպորտի և պորտի շուրջ։ Կլիենտի ֆայլում proto udp-ը proto tcp-ով փոխարինելը սերվերի լսող չի ստեղծում։ Սերվերը պետք է կարգավորված լինի այդ արձանագրության համար, և պրոֆիլը պետք է համապատասխանի դրան։

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep-ը տպում է, թե ինչ է ասվել սերվերին օգտագործել, մինչդեռ սոքեթների երկու ցանկերը ցույց են տալիս, թե ինչին է այն կապված։ UDP լսողը հայտնվում է միայն առաջին ցանկում, իսկ TCP լսողը՝ միայն երկրորդում, ուստի բացակայող տողը ամենաարագ ճանապարհն է գտնելու պրոֆիլ, որը երբեք չի կիրառվել։ Համեմատեք նաև պորտը, որովհետև 1194-ի TCP պրոֆիլը մուտքի ցանցերի մեծ մասում այլ կերպ է վարվում, քան 443-ինը։ Փոփոխությունից հետո վերագործարկեք ծառայությունը և կարդացեք կապի մասին հաղորդող մատյանային տողը։

Կլիենտի կողմում հաստատումը էժան է. գործարկեք կապը --verb 4-ով և կարդացեք տրանսպորտի տողը մատյանում։ Եթե կլիենտն ասում է UDP, մինչ սերվերը լսում է TCP, ձեռքսեղմումը երբեք չի սկսվում, և ոչ մի կարգավորում չի օգնի։

Համեմատեք աշխատանքային ծանրաբեռնվածությունը, ոչ տրանսպորտի պիտակը

Արդար համեմատությունը բոլոր բաները հաստատուն է պահում, բացի տրանսպորտից։ Նույն սարքը, նույն մուտքի ցանցը, նույն նպատակակետ հոսթը, նույն հավելվածը և իդեալականում նույն սերվերը։ Եթե երկու պրոֆիլները մատնանշում են տարբեր հոսթեր, դուք չափում եք նաև այդ հոսթերին։

Յուրաքանչյուր գործարկման համար գրանցեք երեք արդյունք. արդյոք թունելը հաստատվում է, արդյոք այն մնում է, և արդյոք առաջադրանքը ավարտվում է։ Փոքր հարցումները, որոնք աշխատում են, մինչ մեծ փոխանցումները կանգ են առնում, մատնանշում են փաթեթի չափին և MTU-ին, ոչ տրանսպորտին։ Կրկնվող վերամիացումները մատնանշում են ուղուն կամ միջանկյալ սարքի ժամկետի ավարտին։

Պահեք այն պրոֆիլը, որն աշխատում է ձեր իրական հանդիպող պայմաններում, և պահեք մյուսը։ Ընտրությունը պատկանում է ցանցին, ոչ մարդուն, այդ պատճառով ցանկացած մեկ լռելյայն պատասխան ինչ-որ տեղ սխալ է։