Tor-ը պատրաստ VPN-ից առաջ՝ մեկնարկային դարպասի ճիշտ հերթականություն

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

Քայլ 1՝ ընտրեք այն տրանսպորտը, որն իրականում ունեք

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

Այնուհետև հաստատեք, որ ձեր հաճախորդն ընդհանրապես կարող է հասնել SOCKS վստահված սերվերի։ OpenVPN 2.6-ը փաստագրում է socks-proxy ընտրանքը TCP պրոֆիլների համար, և տարբեր հաճախորդներ տարբեր վստահված սերվերի աջակցություն են առաջարկում։ Մեկնարկիչը, որն անաղմուկ անտեսում է վստահված սերվերի ընտրանքը, կմիանա ուղղակիորեն և կթվա, թե աշխատում է, ինչը վատթար է ձախողումից։

Գրեք ընտրված տրանսպորտը runbook-ում, քանի որ յուրաքանչյուր հետագա ստուգում կախված է դրանից։

Քայլ 2՝ կարդացեք bootstrap փուլը, ոչ թե գործընթացների ցանկը

Tor-ի կառավարման արձանագրությունը GETINFO status/bootstrap-phase հարցմանը պատասխանում է ամենավերջին bootstrap վիճակով, ներառյալ առաջընթացի տոկոսը և ամփոփիչ պիտակը։ Այդ պատասխանը օգտակար է հենց այն պատճառով, որ կարգավորիչը կարող է միանալ այն բանից հետո, երբ դեմոնն արդեն ավարտել է bootstrap-ը։ Վերակացուն, որը լսում է միայն իրադարձություններին, բաց կթողնի այն դեպքը, երբ Tor-ն արդեն պատրաստ էր մինչև վերակացուի մեկնարկը։

Ճիշտ նույնականացրեք կառավարման կապը։ Կառավարման պորտը վարչական ինտերֆեյս է, և յուրաքանչյուրը, ով կարող է խոսել դրա հետ, կարող է վերակազմաչափավորել դեմոնը։ Պահեք այն localhost-ում, պահեք cookie-ով կամ գաղտնաբառով նույնականացումը միացված և մի հեռացրեք դրանցից ոչ մեկը՝ մեկնարկային սկրիպտը պարզեցնելու համար։

Կարդացեք փուլը մեկ անգամ մեկնարկի ժամանակ, ապա բաժանորդագրվեք առաջընթացի իրադարձություններին ուղիղ դիտման համար։

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

100 առաջընթացով և done պիտակով պատասխանը նշանակում է, որ դեմոնն ավարտել է իր իսկ մեկնարկը։ Դա դեռ չի նշանակում, որ ձեր նպատակակետի համար գոյություն ունի օգտագործելի շղթա։

Քայլ 3՝ սպասեք հաճախորդի շղթայի իրադարձությանը

Tor-ի իրադարձությունների արձանագրությունը սահմանում է CIRCUIT_ESTABLISHED, որը հաղորդում է, որ հաճախորդն ունի օգտագործելի շղթա։ Սա է այն պատրաստակամության ազդանշանը, որը ցանկանում է կրիչի դարպասը, քանի որ այն ավելի մոտ է ձեզ անհրաժեշտ ունակությանը, քան տոկոսը։ Բաժանորդագրվեք իրադարձությանը և գրանցեք անցումը, որպեսզի մատյանը ցույց տա, թե երբ կրիչը դարձավ օգտագործելի, և ոչ թե երբ հայտնվեց գործընթացը։

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

Կոդում երկու պայմանները պահեք առանձին։ ready անունով մեկ բուլյան արժեքը կմիավորի դրանք և հաջորդ միջադեպը կդարձնի անընթեռնելի։

Քայլ 4՝ դարպասեք VPN-ը նրա սեփական ձեռքսեղմումով

VPN-ն ունի իր պատրաստակամության պայմանը, և միայն այն է ապացուցում, որ թունելը բարձրացել է։ Սպասեք, որ հաճախորդը հաղորդի նշանակված հասցայով միացված վիճակի մասին, ապա ստուգեք, որ վստահված սերվերի պահանջը մնացել է ուժի մեջ։ Կրկնափորձի օղակը, որը մեկ ձախողումից հետո թողնում է socks-proxy ընտրանքը, կմիանա ուղղակիորեն և անաղմուկ կխափանի ամբողջ դիզայնը։

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

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

Ստուգեք այն չորս անցումները, որոնք դուք պետք է վերապրեք

Չորս դեպք ընդգրկում են դիզայնը՝ սառը մեկնարկ, երբ Tor-ը բարձրանում է առաջինը, վերակացու, որը միանում է արդեն պատրաստ Tor-ին, անհասանելի VPN գործընկեր և կրիչի կորուստ, երբ թունելը վերևում է։ Յուրաքանչյուրն ունի տարբեր սպասվող անցում, և յուրաքանչյուրը տարբեր մատյանային տող է արտադրում, եթե դարպասը ճիշտ է գրված։

Գործարկեք դրանք դիտավորյալ, մեկ առ մեկ, և կարդացեք վիճակի փոփոխությունները, ոչ թե գործընթացների ցանկը։

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

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