Ինչպես մեկ հավելվածն անցկացնել VPN-ով առանց ամբողջ մեքենայի

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

Ինչու երթուղային աղյուսակը չի տեսնում ձեր ծրագիրը

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

Սրանցից ոչ մեկը գործընթացով երթուղի չէ։ Յուրաքանչյուրը որոշումը տեղափոխում է շերտ, որը տեսնում է ծրագիրը, օգտատիրոջը կամ հավելվածի սեփական կարգավորումը։

Մեկ նպատակակետը դեռ երթուղի է, ոչ ծրագրի կանոն։ macOS-ում սովորական բաղադրատոմսը «Ուղարկել ամբողջ երթևեկությունը VPN-ով» նշումը հանելն ու հոսթ-երթուղի ավելացնելն է՝ sudo route add -host internal-tuner.example -interface ppp0, որը նորից հանվում է sudo route delete -host internal-tuner.example -interface ppp0-ով։ Նախ կարդացեք միջերեսի անունը ifconfig-ից, քանի որ ppp0 միայն օրինակ է։ Վայրի քարտերը հոսթ-երթուղում չեն աշխատում, ուստի մի քանի անվան հետ խոսող ծառայությանը պետք է մեկ գրառում յուրաքանչյուր անվան համար, և կանոնը ընդգրկում է մեքենայի բոլոր գործընթացները, ոչ թե ձեր մտքում եղածը։

Կապեք սոքեթը թունելի հասցեին

Երբ հաճախորդը ձեր վերահսկողության տակ է, կապումը ամենաէժան ընտրիչն է։ Թունելի տեղական հասցեին կապված սոքեթը դուրս է գալիս այդ միջերեսով, քանի դեռ այնտեղ կա երթուղի դեպի նպատակակետը, և մեքենայի մնացած ամեն ինչ պահպանում է իր սովորական ուղին։ Նրբությունը նրանում է, որ կապումը ընտրում է աղբյուրի հասցեն, մինչ երթուղային աղյուսակը դեռ ընտրում է ելքը։ Կապումը միայնակ չի տեղափոխում այն երթևեկը, որը թունելում երթուղի չունի, և հենց այդ սխալն է «կապեցի, բայց դեռ սխալ կողմով է դուրս գալիս» բողոքների մեծ մասի հետևում։

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

Ավելի բարձր մակարդակի գործիքները նույն գաղափարն են առաջարկում՝ curl --interface 10.8.0.2, PHP-ում՝ CURLOPT_INTERFACE, և source_address արգումենտը Python-ի HTTP հաճախորդներում։ Հասցեն պետք է պատկանի թունելին, և այստեղ տպագրական սխալը ձախողվում է որպես սովորական կապի սխալ, ոչ որպես երթուղավորման բողոք։ Սարքի անվանը կապելը հասցեի փոխարեն Linux-ի արտոնություն է և չի փոխանցվում Windows-ին կամ macOS-ին, դրա համար տեղափոխելի սկրիպտները հասցեն են փոխանցում։

Linux. համապատասխանեցրեք սեփականատիրոջը, ոչ ծրագրի անվանը

Միջուկը կարող է համապատասխանեցնել սոքեթի սեփականատեր օգտատիրոջը, ուստի առանձին հաշիվը դառնում է ընտրիչ։ Թունելը դրեք իր սեփական երթուղային աղյուսակում և այնտեղ ուղարկեք միայն այդ հաշվի երթևեկը՝

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

Սա աշխատում է միայն այն դեպքում, երբ թունելն արդեն լռելյայն երթուղին չէ։ Մեկնարկեք հաճախորդը --route-nopull-ով, կամ զտեք մղված վերահասցեավորումը --pull-filter ignore "redirect-gateway"-ով OpenVPN 2.4 և ավելի նոր տարբերակներում, ապա ինքներդ ավելացրեք աղյուսակի գրառումը։ Հակառակ դեպքում երկու լռելյայններն էլ կան, և հաղթում է ավելի ցածր առաջնահերթություն ունեցողը։ Դրա դիտավորյալ տարբերակը լռելյայն երթուղին թունելի դարպասին ուղղելն է, կամ դա անջատման սկրիպտից անելը. այն երթևեկը հեռու է պահում ինտերնետից, երբ թունելն ընկնում է, բայց դա անջատիչ է, ոչ ընտրիչ, և մնում է այնքան, մինչև մեկը հանի այն։

Ավելի ուժեղ տարբերակը ցանցային անվանատարածքն է։ Ստեղծեք այն, գործարկեք հաճախորդը ներսում և սկսեք հավելվածը ip netns exec-ով։ Անվանատարածքից դուրս ոչինչ չի տեսնում թունելի միջերեսը, ուստի հավելվածը չի կարող պատահաբար վերադառնալ հոսթի երթուղուն։ Գինը իրական է. անվանատարածքին պետք է veth զույգ՝ ֆիզիկական ցանցին հասնելու համար, և իր լուծիչ ֆայլը, քանի որ միացման անվանատարածքը չի կիսում հոսթի լուծման կարգավորումները։

Ձախողման երկու եղանակ բացատրում է արտահոսքերի մեծ մասը։ Անունների լուծումը դեռ կատարվում է հոսթի լուծիչում, ուստի հարցումը դուրս է գալիս թունելից նույնիսկ այն ժամանակ, երբ TCP կապը ներս է մտնում։ Իսկ IPv6-ին պետք է իր սեփական ip -6 rule-ը, քանի որ v4 կանոնը չի ընդգրկում այն։

Windows և macOS. սահմանափակեք հրապարակը կամ հանձնեք փոխանորդ

Windows-ը նույնպես չունի հավելվածով երթուղու ընտրիչ, բայց նրա հրապարակի կանոնները կարելի է սահմանափակել պրոֆիլով, և VPN ադապտերը կարելի է դասակարգել «հանրային», մինչ տնային LAN-ը մնում է «մասնավոր»։ Ստեղծեք ելքային արգելափակման կանոններ ծրագրի համար «մասնավոր» և «տիրույթ» պրոֆիլներում, թողեք «հանրայինը» բաց, և հավելվածը ցանցին կհասնի միայն թունելով։ Նախ սահմանեք կապի ցանցային կատեգորիան, ապա հաստատեք, որ կանոնը համընկել է հրապարակի մոնիտորի վահանակում։ Դա արգելափակում է, ոչ երթուղի. այն փակ վիճակում ձախողվում է, երբ թունելն ընկնում է, և չի կարող կանգնեցնել հավելված, որը անտեսում է հրապարակը։

macOS-ը հետևում է նույն տրամաբանությանը այլ գործիքներով։ SSH-ով հասանելի SOCKS լսորդը ամենաքիչ ներխուժող տարբերակն է, քանի որ ssh -D 1080 user@host-ը ստեղծում է մեկ տեղական պորտ, և միայն դրա օգտագործման համար կարգավորված հավելվածներն են գնում այդ ուղով։ pf կանոնը կարող է արգելափակել ծրագիրն ըստ օգտատիրոջ կամ խմբի, բայց դեռ չի կարող թունելը ընտրել միայն այդ ծրագրի համար։ Tunnelblick-ը բոլորովին չի կարող զտել ըստ տիրույթի, որովհետև երթուղիները աշխատում են հասցեներով. OpenConnect-ի օգտատերերը դիմում են vpn-slice-ին, երբ սերվերը մղում է չափազանց լայն նախածանցների ցանկ։

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

SOCKS ցատկ՝ առանց կապման տարբերակի գործիքների համար

Հավելվածների մեծ մասը կարելի է ուղղել HTTP կամ SOCKS փոխանորդի, նույնիսկ երբ նրանք ոչինչ չգիտեն միջերեսների մասին։ SSH հաճախորդը տրամադրում է մեկը՝ առանց սերվերի կողմում փոփոխության:

ssh -N -D 127.0.0.1:9999 [email protected]

Այդ պորտն օգտագործելու համար կարգավորված ամեն ինչ դուրս է գալիս բաստիոնում, մինչ աշխատասեղանի մնացած մասը պահում է իր սովորական կապը։ Թունելի հասցեին կապված տեղական 3proxy օրինակը նույնն է անում մեկ պորտի համար առանց SSH-ի, և stunnel-ը ծածկում է TLS-ով փաթաթված մեկ պորտ։ Սահմանափակումները գործնական են. փոխանորդը տանում է միայն այն արձանագրությունները, որոնք գիտեն ինչպես օգտագործել այն, UDP-ին պետք է SOCKS5 UDP միավորում, որը շատ հաճախորդների «SOCKS5» կարգավորումը չի միացնում, և DNS-ը պետք է լուծվի փոխանորդի կողմից (socks5h curl-ում), հակառակ դեպքում անունը արտահոսում է տեղական լուծիչ։

Լսորդը պահեք տեղական շրջանում, քանի դեռ այլ մեքենայի պետք չէ։

Ստուգեք ուղին գրավմամբ, ոչ կարգավիճակի հաղորդագրությամբ

Հավելվածի կարգավիճակի պատուհանները նկարագրում են կարգավորումը, ոչ փաթեթը։ Գրավեք երկու միջերեսներում և համեմատեք՝

tcpdump -i any -n port 443
ss -tnp | grep 443

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

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