Իրոք օգնում է TCP 443-ը. միայն եթե սերվերը այնտեղ լսում է
TCP պրոֆիլը պահուստային լուծում է, ոչ թե քողարկում։ Ստուգեք, որ սերվերը լսում է այդ պորտին, ապա կշռեք կրկնակի TCP-ի գինը անհասանելիության դեմ։
TCP 443-ը նախապայման ունեցող պահուստային լուծում է, ոչ թե քողարկում, որը թունելը սահեցնում է ցանկացած զտիչի կողքով։ Այն օգնում է, երբ օպերատորն արդեն հրապարակում է TCP լսորդ այդ պորտին, և ուղին հանդուրժում է ժամերով բաց մնացող միացում։ Այն ձախողվում է, սովորաբար որպես ժամանակի սպառում, երբ այդ երկուսից մեկը բացակայում է, և ժամանակի սպառումը հազվադեպ է ասում, թե որն է։ Փոխելու որոշումը պահանջում է երեք հարց, և դրանցից միայն մեկն է պորտի համարի մասին։
Պորտի համարը տրանսպորտի խոստում չէ
Պորտը անվանում է վերջնակետ. TCP-ն այն վերածում է կարգավորված բայթերի հոսքի. OpenVPN-ն է որոշում, թե ինչ է անցնում այդ հոսքի ներսում։ Նույն համարի վրա գտնվող վեբ սերվերն օգտագործում է բոլորովին այլ հավելվածային դասավորություն, ուստի 443 պորտի համատեղ օգտագործումը երկուսին զտիչի համար նմանեցնում է և ոչ ավելին։ Համարը զտիչի կարդացած ակնարկն է, ոչ թե հատկություն, որը փոխում է փաթեթների բովանդակությունը։ Երկուսին նույնը համարելը, քանի որ նրանք կիսում են պորտը, այստեղի շփոթության մեծ մասի հետևում կանգնած սխալն է։
Միջանկյալ սարքերը հազվադեպ են պորտի վերաբերյալ պարզ թույլատրել-կամ-արգելել որոշում կայացնում։ Շատերը ստուգում են առաջին բայթերը, ոմանք ամրացնում են նպատակակետը, իսկ ոմանք վերակայում են չափազանց երկար բաց մնացող միացումները։ Այդ պատճառով նույն պրոֆիլը կարող է աշխատել մի ցանցից և ժամանակի սպառում տալ մյուսից, և այդ պատճառով արժե պահուստային լուծումը փորձարկել որպես աջակցվող տարբերակ, այլ ոչ թե վստահել որպես խոստում։ Երբ զտիչը ստուգում է երթևեկությունը, պորտի համարը միայն առաջին բանն է, որին նայում է։
Հաստատեք լսորդը, նախքան պրոֆիլին դիպչելը
Սերվերը պետք է կարգավորված լինի TCP-ի համար այդ պորտին, և հաճախորդի պրոֆիլը պետք է պահանջի նույն տրանսպորտը։ UDP պրոֆիլը TCP պահանջելու համար վերաշարադրելը չի ստեղծում լսորդը, և առաջացած ժամանակի սպառումը չի տարբերվում պորտը գցող հրային պատից։ Ներբեռնեք օպերատորի սեփական TCP պրոֆիլը, երբ այն կա, քանի որ որոշ ծառայություններ հրապարակում են առանձին վերջնակետ և առանձին ինքնության կարգավորումներ յուրաքանչյուր տրանսպորտի համար։ Ձեռքով խմբագրումը լավ է վերահսկվող փորձարկման համար և վատ միջոց մատակարարի նախատեսած կարգավորումը գուշակելու համար։
Այդ համապատասխանության երկու կողմերը երևում են կարգավորման մեջ, որտեղ OpenVPN նախագծի կապի ընտրանքները նկարագրում են երկու ձևերն էլ, և նվազագույն զույգն այսպիսի տեսք ունի։
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Երեք պայման են որոշում՝ արդյոք պահուստային լուծումն արժե իր գինը
Առաջին պայմանն այն է, որ օպերատորն ընդհանրապես առաջարկում է տրանսպորտը, և առանց դրա մնացածն անկարևոր է։ Երկրորդն այն է, որ ուղին կենդանի է պահում երկարատևորդ սեսիան, քանի որոշ ցանցեր վերակայում են բաց մնացող միացումները՝ պորտը լրիվ արգելափակելու փոխարեն։ Երրորդն այն է, թե արդյոք պահուստային լուծումը դիտավորյալ բացառություն է, թե ժամանակավոր լուծում, որը թաքցնում է ձեր չուղղած խափանումը։
Յուրաքանչյուր պայման ունի էժան ստուգում։ Դրանցից որևէ մեկում ձախողումը հաճախորդի կողմից նույնն է երևում.
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Նախքան տրանսպորտները համեմատելը՝ ավարտեք ցանկացած մուտք գործումը գրավող պորտալում։ Ցանցը, որը չի ընդունել ձեր սարքը, արգելափակում է երկու տրանսպորտներն էլ, և այդ դեպքում համեմատությունը չափում է պորտալը, ոչ թե թունելը։ Մուտք գործեք, հաստատեք, որ սովորական զննարկումն աշխատում է, և միայն դրանից հետո սկսեք փորձարկումը։
Այն գինը, որ դուք ընդունում եք. TCP-ն TCP-ի ներսում
TCP-ն վերահաղորդում է կորցրած հատվածները և պահպանում դրանց հերթականությունը։ Երբ հավելվածը, որն ինքն էլ օգտագործում է TCP, աշխատում է TCP թունելի ներսում, վերականգնման երկու շերտ արձագանքում են նույն կորստին, և հենց այդ փոխազդեցությունն է թունելը դանդաղ դարձնում կորուստներով ուղու վրա։ Ախտանիշը ուշացումն ու ցնցումն է, ոչ թե մաքուր խափանում, ինչը հեշտացնում է հեռավոր կողմին մեղադրելը։ Չափեք հաճախորդի կողմից երկու տրանսպորտներում էլ, նախքան եզրակացնելը։
UDP-ն խուսափում է այդ ներդնումից, և դա է հիմնական պատճառը, որ օպերատորները նախընտրում են այն և TCP-ն առաջարկում միայն որպես այլընտրանք։ Կայուն TCP միացումը դեռ ավելի օգտակար է, քան անհասանելի UDP միացումը, ուստի համեմատությունը երկու իրական գների միջև է, ոչ թե լավ ու վատ տարբերակի միջև։ Համեմատելիս սարքը և մուտքի ցանցը պահեք անփոփոխ, այլապես արդյունքը կնկարագրի սխալ փոփոխականը։
Հաճախորդի որոշ գործառույթներ փաստագրված են միայն մեկ տրանսպորտի համար, ուստի պահուստային պրոֆիլը կարող է լուռ կորցնել ձեր հենված պահվածքը։ Կարդացեք ընտրանքի տրանսպորտային պահանջը, նախքան TCP պրոֆիլը որպես պարզ փոխարինում դիտարկելը։
Խափանումներ, որոնց այլ տրանսպորտը չի դիպչում
Ժամկետանց վկայագիրը դեռ պահանջում է ժամացույցի ստուգում կամ թարմացում, և մերժված հաշիվը դեռ պահանջում է ճիշտ հավատարմագրեր։ Պահեք օպերատորի տրամադրած սերվերի ինքնության ստուգումները, քանի որ ծանոթ պորտի համարը ոչ մեկին չի նույնականացնում։ Պատասխանող պորտը միայն ասում է, որ ինչ-որ բան լսում է։
Եթե թունելը բարձրանա, և նպատակակետերը դեռ ձախողվեն, մնացած խնդիրը միացումից հետո երթուղավորումն է կամ անունների լուծումը, ոչ թե տրանսպորտը։ Հետևեք այդ ուղուն՝ պորտերի միջև պտտվելու փոխարեն, քանի որ հենց այդպես է անհետանում կեսօրը։ Պրոֆիլը ասում է, թե որ տրանսպորտը փորձել. այն երբեք չի ասում, թե ինչու UDP ուղին ձախողվեց։