Android SSH SOCKS վստահված սերվեր. ինչու է միանում ձեր հավելվածների միայն կեսը

Դուք մուտք եք գործում SSH-ով, ավելացնում -D 1080, և հրամանը հաջողվում է։ Հիմա հեռախոսում SOCKS լսող կա, և հավելվածների կեսը դեռ դուրս է գալիս բջջային տվյալներով։ Սա նորմալ արդյունք է, ոչ թե կոտրված թունել. ssh -D-ը ստեղծում է վստահված սերվերի վերջնակետ, և Android հավելվածները վստահված սերվեր օգտագործում են միայն այն դեպքում, երբ ինչ-որ բան ստիպում է նրանց։ Շղթան քայլ առ քայլ անցնելը ցույց է տալիս, թե որտեղ է իրականում գտնվում աշխատանքի յուրաքանչյուր մասը։

Սկսեք այնտեղից, որտեղից սկսվում է երթևեկությունը

Ընտրեք մեկ հավելված, որը պետք է օգտագործի թունելը, և ստուգեք՝ ունի՞ արդյոք իր սեփական վստահված սերվերի կարգավորումը։ SOCKS դաշտով դիտարկիչը հեշտ դեպքն է. ուղղեք այն 127.0.0.1:1080-ին, միացրեք հեռավոր DNS-ը, եթե կարգավորումը կա, և հարցումն անցնում է։ Զրույցի հաճախորդը, քարտեզի հավելվածը կամ նման դաշտ չունեցող խաղը ոչ մի կերպ չի կարող օգտագործել լսողը, և ոչինչ, ինչ գրեք SSH հրամանում, դա չի փոխում։

Նախքան որևէ այլ բան ներառելը, ապացուցեք, որ լսողն աշխատում է հեռախոսի սեփական shell-ից՝ ուղիղ SOCKS խոսող հաճախորդով.

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Վերադարձող հասցեն պետք է լինի SSH սերվերի հասցեն, ոչ հեռախոսինը։ Եթե այդպես է, վստահված սերվերի կեսն ավարտված է, և մնացած աշխատանքը ծածկույթի մասին է։ Եթե ոչ, նախ ուղղեք SSH կողմը. բանալիով նույնականացում, սերվերի՝ նպատակակետին հասնելու ունակությունը և SSH սերվերի սեփական ելքը։

Ավելացրեք այն մասը, որն անհրաժեշտ է Android-ին

Առանց վստահված սերվերի կարգավորման հավելվածներին անհրաժեշտ է մի բան, որ բռնի նրանց փաթեթները և դարձնի վստահված սերվերի միացումներ։ Առանց root սարքում դա VPN ծառայության ադապտեր է. հավելված, որը վերցնում է վիրտուալ ինտերֆեյսը և ընտրված երթևեկությունը փոխանցում տեղական SOCKS լսողին։ Շղթան դառնում է հավելված, ադապտեր, SOCKS լսող, SSH միացում, նպատակակետ։

Տեղադրեք ադապտերը, տվեք նրան VPN թույլտվություն և ընտրեք այն հավելվածները կամ երթուղիները, որոնք այն պետք է բռնի։ Կարգավիճակի տողի բանալու պատկերակն այնուհետև ներկայացնում է ադապտերը, ոչ թե առանձին առևտրային VPN։ Android-ը թույլատրում է մեկ ակտիվ VPN ծառայության միացում մեկ օգտվողի պրոֆիլի համար, այնպես որ երկրորդ VPN հավելվածը չի ավելացնում շերտ շղթայի վրա. այն մրցում է նույն դերի համար։

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

Պահեք SSH տրանսպորտը բռնելուց դուրս

SSH միացումը ինքը չպետք է հետ վերադարձվի այն SOCKS թունելը, որը նա պահպանում է։ Եթե ադապտերը բռնում է SSH հավելվածի երթևեկությունը, թունելը կախված է միացումից, որը սպասում է թունելին, և արդյունքը օղակ է, որը կանգ է առնում կամ ձախողվում է հենց ադապտերը սկսելուն պես։

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

Ստուգեք բացառումը դրսից. նորից միացրեք ադապտերը, ապա հաստատեք, որ SSH նստաշրջանը գոյատևում է, և վստահված հարցումը դեռ հայտնում է սերվերի հասցեն։ Նստաշրջանը, որն աշխատում է մինչև ադապտերի մեկնարկը և հետո սառչում է, հենց այդ օղակն է։

Հետևեք DNS-ին և UDP-ին մինչև շղթայի վերջը

OpenSSH-ի դինամիկ փոխանցումը տեղափոխում է TCP միացումներ։ Դա UDP-associate կամ ICMP տրանսպորտ չէ, և ադապտերը չի կարող UDP փոխանցում հորինել՝ ընդունելով UDP փաթեթներ։ Ամեն ինչ, որ պնդում է UDP, ներառյալ QUIC-ը և WebRTC մեդիան, կամ կձախողվի, կամ կընկնի TCP-ի, կախված հավելվածից։

DNS-ն ունի իր որոշումը։ Հավելվածը, որը անունը լուծում է տեղում, հարցումն ուղարկում է սովորական լուծիչով նախքան միանալը, այնպես որ թունելը տեղափոխում է միացումը, բայց ոչ որոնումը։ Վստահված սերվերին տեղյակ հաճախորդը հեռավոր DNS տարբերակով խուսափում է դրանից. բռնված հավելվածը առանց դրա՝ ոչ։ Ստուգեք, թե որ լուծիչը պատասխանեց, փոխարենը ենթադրելու, որ ադապտերը փոխել է այն։

Պահեք SOCKS լսողը loopback-ին կապված, առաջին օգտագործման ժամանակ ստուգեք SSH սերվերի host բանալին, և վերջնական կայքի համար թողեք սովորական HTTPS վավերացումը տեղում։ SSH-ը պաշտպանում է հեռախոս-սերվեր հատվածը. այն չի գաղտնագրում այն, ինչ սերվերն անում է հետո։

Ստուգեք երկու կյանքը և որոշեք

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

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

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