Android-ի մեկ VPN-ի կանոնը չի արգելափակում հոսթավորված SSH սերվերը

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

Ինչ է իրականում սահմանափակում մեկ VPN-ի կանոնը

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

Այն ոչինչ չի ասում լսող socket-ների մասին։ SSH սերվերը չի կանչում VpnService-ը, չի ընդհատում փաթեթները և չի մրցում այդ տեղի համար։ Այն կապում է պորտ և ընդունում միացումներ, ինչը նույնն է, ինչ կաներ առանց VPN-ի տեղադրման։ Այսպիսով, առասպելը շփոթում է թունելի մատակարարների սահմանափակումը ցանցային միացումների սահմանափակման հետ, և այդ երկուսը կապ չունեն։

Լսողը նպատակակետ է, ոչ թե թունելի մաս

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

Կապման կանոնները սովորական SSH կոնֆիգուրացիա են՝ լսելու հասցեն և պորտը, և թե ով կարող է նույնականացում անցնել։ Android-ում այդ կարգավորումները գտնվում են հավելվածի սեփական կոնֆիգուրացիայում, և հավելվածի պրոցեսի սեփականատիրոջը կարող է թույլատրված չլինել օգտագործել արտոնյալ պորտեր, ուստի աշխատասեղանի սովորույթը՝ root-ով 22 պորտը կապելը, չի փոխանցվում անփոփոխ։

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

Պատասխանի ուղին այն տեղն է, որտեղ այն սովորաբար կտրվում է

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

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

Հավելվածը կարող է նաև իր socket-ները կապել կոնկրետ ցանցի, ինչը վերացնում է լռելյայնը։ Երբ կարդում եք զեկույց, որ ծառայությունը հասանելի է մի հասցեից և ոչ մյուսից, սովորաբար դա է դրա հետևում ընկած մեխանիզմը։

VPN-ը շրջանցելը չի վերանորոգում մուտքային ծառայությունը

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

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

Նախ որոշեք ծառայության հասցեն՝ հեռախոսի LAN հասցեն, դրա թունելի հասցեն կամ միտումնավոր փոխանցված վերջնակետը։ Յուրաքանչյուրն ունի իր հասանելիության և բացահայտման պայմանագիրը, և դրանք խառնելը հենց այն է, ինչ փոքր հասանելիության խնդիրը դարձնում է մշտական անցք։

Ախտորոշեք մեկ ուղղություն միաժամանակ

Նախքան կոնֆիգուրացիան փոխելը գրեք չորս փաստ. հասցեն, որին միանում է գործընկերը, լսողի վիճակը հեռախոսում, այն պահող հավելվածի և օգտատիրոջ համատեքստը, և յուրաքանչյուր ուղղությամբ դիտարկված ուղին։ Զեկույցը, որն ասում է, թե VPN-ն անջատում է SSH-ը, չի պարունակում դրանցից ոչ մեկը և չի կարող տարբերել հաճախորդի տրանսպորտի խնդիրը անհասանելի սերվերից։

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Պորտի ստուգումը գործարկեք գործընկերից, ոչ թե հեռախոսից, և կարդացեք SSH հաճախորդի մանրամասն ելքը՝ տեսնելու, թե արդյոք այն ձախողվում է TCP ձեռքսեղմումից առաջ թե հետո։ Socket-ը, որը երբեք չի միանում, և մերժված մուտքը տարբեր փուլեր են՝ տարբեր պատասխանատուներով։

Վրիպազերծման ընթացքում անփոփոխ պահեք հոսթի բանալու ստուգումը և հաշվի սահմանափակումները։ Հենց լսողի և թույլատրված օգտատերերի սահմանափակումն է հասանելի սերվերը ընդունելի դարձնում. դրանք թուլացնելը, որպեսզի միացումն աշխատի, մի խնդիր փոխանակում է ավելի վատի հետ։ OpenSSH սերվերի տեղեկատուն ներառում է լսելու և հասանելիության վերահսկիչները, եթե ձեր Android իրականացումը հետևում է նույն կոնֆիգուրացիայի անվանումներին։