Հակադարձ թեթերինգ Android-ի համար USB-ով՝ հրամաններ, ստուգումներ, վերականգնում
Հակադարձ թեթերինգը հեռախոսի տրաֆիկը փոխանցում է հոսթի ռելեով։ Կառուցեք ուղին հեռախոսից հոսթ, հոսթի VPN-ը պահեք օղակում և ստուգեք յուրաքանչյուր թռիչք։
Հակադարձ թեթերինգը հեռախոսի տրաֆիկը տեղափոխում է համակարգիչ և դուրս բերում այդ համակարգչի միացումով։ Միայն USB մալուխը դա չի անում՝ հեռախոսին պետք է որսման ծառայություն, որն ստանձնում է նրա երթուղավորումը, իսկ համակարգչին՝ ռելե, որն այդ փաթեթները տանում է առաջ։ Ուղին ունի չորս թռիչք՝ հավելված, որսում հեռախոսում, USB ռելե և հոսթի ելք, և յուրաքանչյուրն ունի տարբեր սեփականատեր։ Այս ձեռնարկը կառուցում է այդ ուղին, տեղադրում հոսթի VPN-ը իր տեղում և ստուգում յուրաքանչյուր թռիչք նախքան արդյունքին վստահելը։
Քարտեզագրեք թռիչքները նախքան որևէ բան գործարկելը
Յուրաքանչյուր թռիչք կիրառում է իր քաղաքականությունը, դրա համար էլ մի ծայրում աշխատող արդյունքը ոչինչ չի ասում մյուսի մասին։ Հավելվածն ընտրում է նպատակակետ և լուծիչ, որսման ծառայությունը որոշում է, թե որ տրաֆիկը մտնի ռելե, ռելեն փոխանցում է հոսթի սոքեթներին, իսկ հոսթի երթուղավորումն ու VPN-ը որոշում են այն հասցեն, որը նպատակակետը վերջում տեսնում է։
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
Միաժամանակ հեռախոսի որսման դերը կարող է պահել VPN ծառայության միայն մեկ հաճախորդ, ուստի երկրորդ սովորական VPN հավելվածը չի շերտավորվում ռելեի վրա։ Եթե VPN-ը պատկանում է համակարգչին, որսման ծառայությունը դեպի այդ համակարգիչ տանող մուտքի օղակն է, ոչ թե ապացույց, որ հեռավոր թունելն արդեն պաշտպանում է արդյունքը։
Պատրաստեք ռելեն նախքան հեռախոսին դիպչելը
Gnirehtet այս ճարտարապետության փաստաթղթավորված օրինակն է՝ root-ի կարիք չունեցող VPN ծառայության հաճախորդ հեռախոսում և ADB-ով հոսթ տեղափոխվող ռելե, որն աջակցում է TCP-ին և UDP-ին IPv4-ի վրա։ Նրա պահոցը նաև նշում է, որ նախագիծն այլևս ակտիվորեն չի պահպանվում, ուստի վերաբերվեք դրան որպես հղումային նախագծի և լաբորատորիայի համար աշխատող գործիքի, ոչ որպես աջակցվող արտադրանքի, որ կարելի է ստանդարտացնել կառավարվող սարքախմբում։
adb devices
adb shell getprop ro.build.version.release
gnirehtet runՆախ գործարկեք adb devices-ը։ Հեռախոսը, որը չի ընդունել հոսթի վրիպազերծման բանալին, հաղորդվում է որպես չարտոնված, և ռելեն չի միանա, քանի դեռ սարքի հուշումը չի ընդունվել։ gnirehtet run-ը տեղադրում է հաճախորդը, գործարկում ռելեն և ակտիվացնում որսումը՝ այն տարբերակում, որտեղ քայլերն առանձնացված են, փոխարենը օգտագործեք փաստաթղթավորված install, relay և start ենթահրամանները։
ADB մուտքը սարքի կառավարման հարաբերություն է, ոչ ցանցի կարգավորում։ Լիազորեք միայն ձեր կառավարած համակարգիչը և պլանավորեք այդ լիազորությունը հետ կանչել աշխատանքի ավարտին։
Վերադարձրեք հոսթի VPN-ը ուղի
Ռելեն սովորական հոսթային գործընթաց է, ուստի նրա հետագա միացումները հետևում են հոսթի երթուղային աղյուսակին։ Լրիվ թունելի պրոֆիլը տանում է դրանք, բաժանված թունելը գուցե ոչ։ Եթե հոսթի VPN-ը օգտագործում է հավելվածով պայմանավորված կառավարում, ավելացրեք ռելեի բինարը թույլատրված բազմությանը, հակառակ դեպքում ռելեն կշարունակի օգտագործել ֆիզիկական ինտերֆեյսը, մինչ դիտարկիչը պաշտպանված է թվում։
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relayԳործարկեք առաջին երկու հրամանները հոսթի VPN-ին միանալուց առաջ և հետո։ Եթե հասցեն չի փոխվում, ռելեն թունելի վրա չէ, ինչ էլ ասի հաճախորդի պատուհանը։ Միայն մասնավոր թունելը նաև հանրային նպատակակետերը թողնում է հոսթի սովորական ելքի վրա, ինչը արտահոսքի է նման, բայց ձեր սահմանած քաղաքականությունն է։
DNS-ը լուծվում է հոսթում ռելեով անցնող տրաֆիկի համար, ուստի հոսթի լուծիչը որոշում է, թե որ սերվերն է տեսնում անունները։ Հեռախոսի մասնավոր DNS կարգավորումը չի անցնում ռելեով, և հեռախոսի կողմի լուծիչի փորձարկումը չի նկարագրի հոսթի հարցումները։
Ստուգեք յուրաքանչյուր թռիչք առանձին
Երեք ստուգում այս հերթականությամբ՝ հեռախոսը հասնում է ռելեին, ռելեն հասնում է նպատակակետին հոսթի քաղաքականության ներքո, և հավելվածը ճիշտ լուծում և օգտագործում է այդ նպատակակետը։ Կանգ առեք առաջին ձախողման ժամանակ՝ էջերը վերբեռնելու և գուշակելու փոխարեն։
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:VVPN ցանցի գրառում միացության արտապատկերում ցույց է տալիս, որ որսման ծառայությունն ակտիվ է, ռելեի սեփական մատյանը ցույց է տալիս՝ հոսքերը գալիս են, թե ոչ։ Դրանցից մեկում բացակայությունը խնդիրը մաքուր բաժանում է՝ որսում չկա՝ հեռախոսի կողմ, հոսքեր չկան՝ հոսթի կողմ։
Հոսթում աշխատող դիտարկիչը ապացուցում է հոսթի դիտարկիչի ուղին, ոչ ռելեի գործընթացի ուղին։ Համեմատեք այն հասցեները, որ հաղորդում է յուրաքանչյուրը, և փորձարկեք ինչպես մասնավոր ռեսուրս, այնպես էլ հանրային էջ, քանի որ միայն մասնավոր թունելը կարող է երթուղավորել մեկը և ոչ մյուսը։
Ապամոնտաժեք և ընտրեք ձախողման վարքը
Վերականգնումը ձեռնարկի մաս է։ Կանգնեցրեք և հեռացրեք ռելեն, ապատեղադրեք որսման հաճախորդը և հետ կանչեք հոսթի վրիպազերծման լիազորությունը հեռախոսի մշակողի ընտրանքներից, երբ աշխատանքն ավարտված լինի։
gnirehtet stop
gnirehtet uninstall
adb kill-serverՈրոշեք, թե հեռախոսը ինչ պետք է անի, երբ ռելեն անհետանա։ Առանց հստակ ընտրության այն կարող է վերադառնալ բջջային տվյալներին և արտահոսել այն տրաֆիկը, որը փորձում էիք երթուղավորել, ուստի գիտակցաբար սահմանեք միացումների արգելափակման վարքը կամ VPN քաղաքականությունը և փորձարկեք ապամոնտաժումը նախքան դրա վրա հենվելը։
Գրանցեք, թե որ հոսթն է լիազորվել, ռելեի տարբերակը, հոսթի թունելի քաղաքականությունը և ապամոնտաժման քայլերը։ Այդ գրանցումն է, որ հաջորդ հակադարձ թեթերինգի կարգավորումը դարձնում է կրկնելի՝ վերագտնման ևս մեկ կեսօրի փոխարեն։