OpenVPN-ը SOCKS5-ի վրայով․ տարբերակի, տրանսպորտի և DNS-ի համապատասխանեցում

Այս աշխատանքային կայանից դուրս եկող ուղիներից մեկը SOCKS պրոքսին է, և դրա հետևում OpenVPN-ը հաղորդում է միացման ժամկետի սպառման մասին՝ առանց որևէ օգտակար մանրամասնի։ Նույն մեքենայի զննարկիչն աշխատում է այդ պրոքսիով, հավատարմագրերը ճիշտ են, և պորտը պատասխանում է։ Երեք բան հաճախ են տարբերվում այնքան, որ նախ պետք է ստուգել՝ SOCKS-ի այն տարբերակը, որով խոսում է պրոքսին, կլիենտի ընտրած տրանսպորտը, և այն տեղը, որտեղ կատարվում է անվան լուծումը։ Հաստատեք դրանցից յուրաքանչյուրը, նախքան որոշելը, որ հրակայուն պատն է մեղավոր։

Համապատասխանեցրեք SOCKS տարբերակը հրակայուն պատից առաջ

Համայնքային OpenVPN-ը socks-proxy-ի համար խոսում է SOCKS5-ով։ Ուղղեք այն պրոքսիի, որն առաջարկում է միայն SOCKS4, և TCP միացումը կբացվի, ապա կկանգնի, որովհետև կլիենտը սպասում է ողջույնի պատասխանին, որը մյուս կողմը երբեք չի վերլուծում։ Դրսից այդ կանգնելը ճիշտ այնպես է երևում, ինչպես զտված պորտ, և դրա համար է, որ տարբերակի հարցը գալիս է ցանկացած հրակայուն պատի կանոնից առաջ։ SOCKS-ին ծանոթ մեկ բեռնումը լուծում է այն մեկ հրահանգով։

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Ավարտված հարցումը միաժամանակ ապացուցում է երկու բան՝ պրոքսին ընդունել է SOCKS հարցումը, և այն լուծել է անունը։ URL սխեմա պետք չէ, քանի որ curl-ը մերկ հոսթն ընդունում է որպես HTTP, և դա բավարար է այս փորձության համար։

Այդ բեռնումը նաև բացառում է այն խափանումը, որը թաքցնում է կլիենտի մատյանը։ Պրոքսին կարող է թույլատրել զննարկիչին և միևնույնն է մերժել VPN նպատակակետը, և այդ դեպքում մերժումը կատարվում է CONNECT-ում, ցանկացած VPN նույնականացումից առաջ։ OpenVPN-ը հաղորդում է միայն ժամկետի սպառում, ուստի պրոքսիի սեփական պատասխանն է այն ապացույցը, որ ձեզ պետք է։

Տրանսպորտը պետք է TCP լինի երկու կողմերում էլ

SOCKS5-ը այստեղ TCP հոսք է կրում, ուստի թունելն ինքն է պահանջում proto tcp-client։ Պրոֆիլը, որը դեռ UDP-ի վրա է, այս ուղիով չի աշխատի, որովհետև կլիենտը չի օգտագործում արձանագրության UDP ասոցիացիայի ռեժիմը։ Պրոֆիլը շրջելը իրական փոփոխություն է, ոչ թե ձևականություն․ հեռավոր կողմը պետք է նույն պորտում TCP լսի։ Այնուհետև ծանրաբեռնվածությունը դառնում է TCP՝ TCP-ի ներսում, որտեղ կորած սեգմենտը երկու անգամ կրկին ուղարկվում է և թափը վատանում է, ինչը ինտերակտիվ սեանսները զգում են շատ ավելի, քան մեծ փոխանցումները։

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Այս հրահանգը վերցնում է պրոքսիի հոսթը, ընտրովի պորտ և ընտրովի հավատարմագրերի ֆայլ։ Դրեք դրանք հենց պրոֆիլում, որպեսզի այլ տեղ դրված պատճենը նույն կերպ վարվի։

Ամբողջ շղթան պարփակեք մեկ կոնտեյներում

Շղթան հոսթի վրա անելը նշանակում է զավթել նրա լռելյայն ուղին և լուծիչը թողնել այնպիսի վիճակում, որ հետո ոչ ոք չկարողանա բացատրել։ Փոխարենը անվանատարածքը կամ կոնտեյները սահմանափակում է այն, ուստի հոսթը պահում է իր ուղին, մինչ SOCKS թռիչքը և թունելը ապրում են միասին։ Ներսում ոչինչ չի բարձրանում առանց թունելի սարքի, այդ սարքը կարգավորելու իրավունքի և հասանելի պրոքսիի։ Compose ծառայությունը դա ստանում է cap_add: NET_ADMIN-ով և bind-ով ամրացված /dev/net/tun-ով։

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

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

Անվան լուծումը հենց այն տեղն է, որտեղ մեկուսացումը ձախողվում է

Թունելը, որը կրում է փաթեթներ և միևնույնն է հարցնում հոսթի լուծիչին, ոչինչ չի մեկուսացրել։ Երկու բան մեկուսացումը դարձնում է իրական՝ անվանատարածքն ունի իր լուծիչը, և նրա հարցումներն անցնում են պրոքսիով կամ թունելով, երբեք ֆիզիկական ինտերֆեյսով։ Փորձության համար օգտագործեք երկու անուն՝ մեկը, որը գոյություն ունի միայն թունելի հետևում, և մեկ հանրային, որը պետք է նույն ուղին անցնի։

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

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

Ապացուցեք յուրաքանչյուր թռիչք հերթականությամբ

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

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

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

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