TCP վերակայումը չի ապացուցում, որ ձեր VPN-ը արգելափակվում է

Հաճախորդի մատյանում հայտնվում է «միացումը վերակայվեց, վերագործարկում», և եզրակացությունը գալիս է ապացույցից առաջ։ Ինչ-որ մեկը որոշում է, որ ցանցը արգելափակում է VPN-ը, կամ վկայականը սխալ է, կամ ինչ-որ երկիր միջամտում է։ Վերակայումը TCP փաթեթ է, որը վերջացնում է միացումը, և մատյանի տողը գրանցում է, որ ձեր հաճախորդը ստացել է մեկը։ Այն չի նշում ուղարկող սարքը և ոչ էլ պատճառը։

Վերակայումը փաթեթ է, ոչ դատավճիռ

TCP-ն սահմանում է վերակայման մշակումը. RST դրոշով սեգմենտը անմիջապես վերջացնում է միացումը։ Ստացողը չի բանակցում, չի կրկնում փորձը և չի հարցնում ինչու։ Այն հաղորդում է վերակայման մասին և շարունակում։

Այսքանը գիտի հաճախորդը։ RST-ն կարող էր գալ սերվերից, պրոքսիից, firewall-ից կամ վիճակը կորցրած բեռնվածքի հավասարակշռիչից։

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

Հաստատեք, թե որ միացումն է վերակայվել

Նախ ստուգեք, որ ակտիվ պրոֆիլն իրոք օգտագործում է TCP։ UDP թունելի վրա վերակայումը իմաստ չունի, և HTTP պրոքսիի մատյանը կարող է վերաբերել VPN-ից տարբեր TCP հատվածի։

Գրանցեք նպատակակետը, պորտը, փորձի ժամանակը և այն փուլը, որին հասել էր հաճախորդը։

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

Համեմատեք ուղու երկու ծայրերը

Եթե դուք կառավարում եք սերվերը, համեմատեք նրա իրադարձությունները նույն փորձի համար։ Արդյո՞ք այն ընդունեց միացումը։ Արդյո՞ք այն դիտավորյալ փակեց այն։ Արդյո՞ք պատասխանը լքեց մի սահման և երբեք չհասավ հաջորդին։

Գրավեք հաճախորդի և սերվերի մոտ, եթե կարող եք։ Վերակայումը, որը երևում է հաճախորդի մոտ, բայց ոչ սերվերի մոտ, չի առաջացել սերվերում։

Ուշադիր եղեք RST սեգմենտներին երկու ուղղություններով.

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Նեղացրեք վերահսկվող համեմատությամբ

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

Սա դեռ չի նույնականացնում մեկ միջանկյալ սարք։ Այն նեղացնում է շրջանակը մինչև երթուղի, ինչը օգտակար և ազնիվ արդյունք է։

Պահեք տարբերությունը «այս ուղին ձախողվում է» և «այս անվանված գործողն է դա առաջացրել» միջև։ Առաջինը ստուգելի է, երկրորդը սովորաբար ոչ՝ մեկ հաճախորդից։

Ստուգեք շտկումը՝ չփոխելով վստահության կարգավորումները

Չանջատեք TLS ստուգումը, չվերականգնեք հավատարմագրերը և մի հայտարարեք արգելափակման քաղաքականություն մեկ վերակայման տողի հիման վրա։ Այս փոփոխություններից յուրաքանչյուրը փոխում է փորձարկվող համակարգը և անիմաստ դարձնում հաջորդ համեմատությունը։

Շտկեք հայտնաբերված բաղադրիչը դրա սեփականատիրոջ միջոցով, ապա կրկնեք նույն պրոֆիլը և նույն դիտարկումը.

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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