Քաղաքականության երթուղավորումն ընդդեմ SOCKS-ի. ո՞ր շերտն է իսկապես փոխանցում երթևեկությունը

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

Երթուղավորումը, DNAT-ը և SOCKS-ը տարբեր բաներ են փոխում

Քաղաքականության երթուղին վերագրում է 3-րդ շերտի որոշումը։ Երկու տող բավական է մեկ հաճախորդի երթևեկն ընտրված հաջորդ թռիչք ուղարկելու համար:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Դրանից հետո միջուկը փաթեթը հանձնում է 10.50.0.2-ին, և սկզբնական նպատակակետը դեռ մնում է IP վերնագրում։ Եթե 10.50.0.2-ը երթուղիչ է, այն փոխանցում է փաթեթը։ Եթե դա հանգույց է 1080-ի վրա SOCKS դեմոնով, փաթեթը հասցեագրված չէ որևէ բանի, որը կարող է ընդունել այն, և DNAT-ը 1080 պորտին նույնպես չի օգնում, որովհետև փոխարկված փաթեթը դեռ կրում է հավելվածի սկզբնական բեռը՝ SOCKS ողջույնի փոխարեն։

SOCKS5 սկսվում է տարբերակի բայթով, մեթոդների ցանկով, նույնականացման փոխանակմամբ և հարցումով, որը նշում է նպատակակետը։ Դա հավելվածի տվյալ է։ Ոչ մի երթուղային գրառում և ոչ մի netfilter թիրախ այն չի ստեղծում, և ահա համեմատությունը մեկ տողով. երթուղավորումն ընտրում է ուղի, SOCKS-ը խնդրում է սերվերին երկրորդ կապ ստեղծել։

Առաջին դեպքը. հավելվածն ինքը կարող է խոսել SOCKS

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

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

Երկրորդ դեպքը. ադապտեր, որը IP հոսքերը վերածում է պրոքսի նստաշրջանների

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

Կարդացեք դրա փաստաթղթերը, նախքան ամբողջ ենթացանցը դրան վստահելը։ Շատ ադապտերներ TCP-ն լավ են տանում և UDP-ին վերաբերվում են միայն SOCKS5-ի UDP ասոցիացիայի միջոցով, և նրանցից ոչ մեկը ICMP-ն պրոքսի երթևեկի չի վերածում, այնպես որ հաջող ping-ը ոչինչ չի ասում պրոքսի ուղու մասին։ DNS-ը մյուս թակարդն է. եթե ադապտերը անունները լուծում է տեղում, միայն ներքին գրառումները լուծվում են սխալ պատասխանի կամ ընդհանրապես ոչնչի։

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

Երրորդ դեպքը. հանգույցն իրականում երթուղավորված դարպաս է

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

Երեք դեպքերը արագ բաժանվում են։ Ստուգեք, թե իրականում ինչն է լսում, ապա նայեք հանգույցին հասնող առաջին բայթերին:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Իսկական SOCKS հաճախորդի առաջին բեռնվածքի բայթը 0x05 է՝ ողջույնի տարբերակը։ Եթե գրառումը դրա փոխարեն ցույց է տալիս հավելվածի սկզբնական տվյալներ, ոչ մի SOCKS դեմոն չի պատասխանի, որովհետև բանակցությունը երբեք չի սկսվել։ Եթե 1080-ի վրա ոչինչ չի լսում, հանգույցը դարպաս է, և հարցը դառնում է՝ փոխանցու՞մ է այն և կա՞ վերադարձի ուղի։

Ընտրեք շերտը չորս հարցով

Արդյո՞ք ծրագիրն ունի պրոքսի կարգավորում։ Օգտագործե՛ք այն և կանգ առեք այնտեղ։ Արդյո՞ք երթևեկը պարունակում է UDP կամ ICMP, որոնք պետք է գոյատևեն։ ICMP կրում է միայն երթուղավորված կամ NAT դարպասը, իսկ UDP-ին անհրաժեշտ է SOCKS5 ասոցիացիա, որին աջակցում են երկու կողմերը։ Արդյո՞ք պետք է ծածկվի մեքենայի յուրաքանչյուր պրոցես, ներառյալ նրանք, որոնք չեք կարող կարգավորել։ Այդ դեպքում ձեզ պետք է ադապտեր, որը տիրապետում է ինտերֆեյսին և վերջացնում հոսքերը։ Կարո՞ղ եք նաև ստանձնել դրա երթուղավորումը, DNS-ը և օղակների կանխման բացառությունները։ Եթե ոչ, սովորական դարպասն ավելի քիչ կարժենա շահագործել։

Մեկ տարբերակարկում արժե ուղիղ պահել։ VPN հաճախորդի սեփական socks-proxy ընտրանքը նկարագրում է, թե ինչպես է արտաքին թունելի կապը հասնում իր սերվերին, և ոչինչ չի ասում ներքին հաճախորդի հոսքերի փոխարկման մասին։ Այս երկուսը անընդհատ շփոթում են նույն տոմսում։ Որոշեք, թե ինչ հարաբերություն է ձեզ պետք, նախքան երթուղուն դիպչելը։