Ինչպես ուղղորդել հոսթի տրաֆիկը Docker VPN կոնտեյների միջով
VPN կոնտեյները ցանցային անունների տարածություն է, ոչ պրոքսի։ Ընտրեք համատեղ netns, իրական SOCKS լսող կամ երթուղավորված դարպաս, ապա ստուգեք ելքի ուղին։
Ձեր թունելային կոնտեյները աշխատում է, docker compose exec vpn curl -s https://ifconfig.me-ը պատասխանում է մատակարարի հասցեով, և այնուամենայնիվ ձեր աշխատասեղանի բրաուզերը դեռ դուրս է գալիս ձեր ISP-ով։ Այդ բացը սպասելի է։ VPN հաճախորդ գործարկող կոնտեյները պահում է ցանցային անունների տարածություն, երթուղիներ և թունելային ինտերֆեյս, և ոչինչ, որ խոսում է HTTP կամ SOCKS, ուստի պորտ հրապարակելը դրա վրա չի կարող ստեղծել լսող, որը երբեք չի եղել։
Թե որտեղ է աշխատում հաճախորդը, դա որոշում է ձևավորումը։ Եղբայր կոնտեյները կարող է տեղափոխվել թունելի անունների տարածություն, աշխատասեղանի հավելվածը չի կարող, իսկ երթուղիչին պետք են երթուղիներ, ոչ թե պրոքսի դաշտ։ Սխալ քարտեզագրեք, և ախտանիշը նույնն է՝ կապը մերժված է, կամ տրաֆիկը հանգիստ գնում է հին ուղիով։
Համապատասխանեցրեք դասավորությունը հաճախորդի աշխատանքի վայրին
Մեկ հարց տվեք Compose-ը խմբագրելուց առաջ՝ կարելի՞ է հաճախորդը գործարկել VPN կոնտեյների ցանցային անունների տարածության ներսում։ Ամեն ինչ, որ արդեն աշխատում է որպես Linux կոնտեյներ, կարող է։ Ձեր աշխատասեղանի բրաուզերը, IDE-ն կամ CLI-ն չի կարող, քանի որ նրա պրոքսի կարգավորումը սպասում է արձանագրային ծառայության, ոչ թե անունների տարածության։
| Client | Arrangement | What must already exist |
|---|---|---|
| Another Compose service | Shares the vpn namespace via network_mode: service:vpn | A working tunnel and correct start order |
| Host browser, IDE or CLI | Proxy listener inside the namespace, published to host loopback | A configured SOCKS or HTTP proxy and its access rules |
| Router, VM or phone | The container as a layer-3 gateway | Forwarding, NAT and a return route |
Այս երեքը չեն խառնվում։ Կոնտեյների կամուրջի հասցեին ուղղված HTTP պրոքսի դաշտը ոչնչի չի հասնում, եթե այնտեղ պրոքսի չի լսում, իսկ պրոքսի լսողը չի երթուղավորում երթուղիչի տրաֆիկը։ Նախ որոշեք, ապա հետևեք համապատասխան բաժնին։
Կիսվեք թունելի անունների տարածությամբ եղբայր կոնտեյների հետ
Սա ամենաէժան տարբերակն է, քանի որ պրոքսի արձանագրություն ներգրավված չէ։ Հավելվածը միանում է vpn ծառայության անունների տարածությանը և ժառանգում է նրա ինտերֆեյսները, երթուղիները և պորտային տարածությունը՝
services:
vpn:
image: your-vpn-client
cap_add:
- NET_ADMIN
healthcheck:
test: ["CMD-SHELL", "ip link show tun0 >/dev/null"]
interval: 10s
retries: 5
app:
image: your-app
network_mode: service:vpn
depends_on:
vpn:
condition: service_healthyԵրեք սահմանափակում բխում է նրանից, որ անունների տարածությունը պատկանում է մեկ այլ ծառայության։ Հավելվածը չի ստանում իր networks բանալին, քանի որ չունի անունների տարածություն, որին կցվի։ Պորտերի հրապարակումը vpn-ինն է, քանի որ այնտեղ է ապրում անունների տարածությունը։ Եվ vpn-ի վերստեղծումը ոչնչացնում է այն անունների տարածությունը, որին միացել էր հավելվածը, ուստի docker compose up -d --force-recreate vpn-ը ձեզ թողնում է վերստեղծել նաև app-ը, սովորական վերագործարկումը միշտ չէ, որ բավարար է։ Compose ծառայությունների տեղեկատուն անդրադառնում է այս դասավորությանը և պորտերի հրապարակման սահմանափակմանը։
Չենթադրեք, որ լուծիչը միասին է գալիս։ /etc/resolv.conf-ը յուրաքանչյուր կոնտեյների ֆայլ է, ոչ թե ցանցային անունների տարածության մաս, ուստի հավելվածը դեռ կարող է հարցնել հոսթի լուծիչին, մինչ դրա փաթեթները դուրս են գալիս թունելով։ Կարդացեք այն կոնտեյների ներսից և սահմանեք dns:-ը հավելվածի վրա, երբ մասնավոր անունները պետք է լուծվեն թունելով։
docker compose exec app ip route
docker compose exec app cat /etc/resolv.conf
docker compose exec app curl -s https://ifconfig.meԵթե երթուղիների ցանկը պարունակում է թունելային ինտերֆեյսը, և հասցեն մատակարարի հասցեն է, հավելվածը թունելի ներսում է։ Եթե ինտերֆեյսը բացակայում է, app-ը մեկնարկել է այն ժամանակ, երբ vpn-ը դեռ թունել չուներ, ուստի վերստեղծեք app-ը, հենց որ vpn-ը հաղորդի առողջության մասին։
Տեղադրեք իրական պրոքսի լսող անունների տարածության մեջ հոսթի հաճախորդների համար
Աշխատասեղանի բրաուզերը չի կարող միանալ անունների տարածությանը, ուստի թունելը պետք է բացվի որպես ծառայություն։ Գործարկեք իրական SOCKS կամ HTTP պրոքսի vpn անունների տարածության ներսում և հրապարակեք միայն նրա պորտը՝
services:
vpn:
ports:
- "127.0.0.1:1080:1080"
proxy:
image: your-proxy
network_mode: service:vpn
command: ["--socks", "0.0.0.0:1080"]Հոսթի կողմի հասցեն այդ քարտեզագրման կարևոր կեսն է։ Ձախ կողմի 127.0.0.1:1080-ը լսողին պահում է ձեր LAN-ից դուրս, մերկ "1080:1080"-ը բաց պրոքսի է հրապարակում յուրաքանչյուր սարքի, որը կարող է հասնել ձեր մեքենային։
Կոնտեյների կողմն ունի իր ծուղակը։ Հրապարակված պորտերը հասցվում են կոնտեյների կամուրջի հասցեին, ոչ թե նրա loopback-ին, ուստի անունների տարածության ներսում --socks 127.0.0.1:1080-ով գործարկված պրոքսին ընդունում է եղբայրների կապերը և մերժում է այն ամենը, ինչ գալիս է հրապարակված պորտով։ Կապեք այն 0.0.0.0-ին և մեկուսացման համար ապավինեք հոսթի կողմի loopback կապին։ Նույն կանոնը վերաբերում է պրոքսի կարգավորումների ֆայլի լսելու հասցեին։
Ապա որոշեք, թե որտեղ են լուծվում անունները։ curl-ում --socks5-ը լուծում է հոսթի անունը տեղում, իսկ --socks5-hostname-ը ուղարկում է անունը պրոքսիին, բրաուզերները ցույց են տալիս նույն անջատիչը այլ պիտակի տակ։ Տեղական լուծումը արտահոսում է հարցումը նույնիսկ այն ժամանակ, երբ էջը բեռնվում է թունելով։
Կոնտեյները դիտարկեք որպես դարպաս միայն վերադարձի երթուղիով
Երթուղիչները, VM-ները և հեռախոսները չեն օգտագործի HTTP պրոքսի դաշտ, և որոշ հավելվածներ ընդհանրապես անտեսում են պրոքսի փոփոխականները։ Նրանց տրաֆիկը երթուղավորելը նշանակում է 3-րդ շերտ՝ կոնտեյները փոխանցում է փաթեթները և թարգմանում հասցեները թունելային ինտերֆեյսում։
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEԵրկու բան հեշտ է բաց թողնել։ Հաճախորդին պետք է երթուղի, որն իր լռելյայն դարպասը ուղղում է այս հոսթին, և պատասխանները պետք է գտնեն վերադարձի ճանապարհը՝ կա՛մ վերին երթուղիչի ստատիկ երթուղով, կա՛մ հաճախորդներին նայող ինտերֆեյսի NAT-ով։ Առանց դրանցից մեկի՝ թունելը հարցումը տանում է դուրս, և պատասխանը անհետանում է։
Այն ունի նաև ամենալայն ազդեցությունը։ Ամբողջ LAN-ի համար դարպաս հանդիսացող հոսթը յուրաքանչյուր սխալ կարգավորված հաճախորդի ուղարկում է ձեր VPN հաշվով, և թունելի անկումը կա՛մ մթնեցնում է LAN-ը, կա՛մ վերադառնում է ISP-ին՝ կախված kill switch-ից։
Ստուգեք ելքի ուղին, ապա հերթականությամբ հետ գլորեք
Ստուգեք այս հերթականությամբ և կանգ առեք առաջին ձախողման ժամանակ՝ ելքի հասցեն անունների տարածության ներսում, ելքի հասցեն հոսթից պրոքսիով, ապա անունների լուծում մասնավոր հոսթի համար։
docker compose exec vpn curl -s https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 http://internal.example/healthԱռաջին երկու հասցեները պետք է համապատասխանեն մատակարարին, իսկ երրորդը պետք է լուծվի պրոքսիով՝ անվան սխալով ձախողվելու փոխարեն։ Առաջին տողի համընկնումը և երկրորդի ձախողումը նշանակում են, որ լսողը կամ հրապարակված պորտը սխալ է, ոչ թե թունելը։
Հետ գլորելը տեղադրման հակառակն է։ Հեռացրեք պրոքսի միջավայրի փոփոխականները shell-ի պրոֆիլից և ցանկացած systemd միավորից, ապա իջեցրեք ստեկը, որպեսզի համատեղ անունների տարածությունը անհետանա իր տիրոջ հետ։ Ջնջեք հրապարակված պորտը նախքան պրոքսի ծառայությունը ջնջելը, այլապես հոսթը կպահի loopback լսող, որը ոչ ոք չի կարդում։
Նախքան առաջ շարժվելը հաստատեք չորս բան՝ ձեզ համար կարևոր հաճախորդը իսկապես հասնում է թունել, պորտերը հրապարակում է միայն անունների տարածության տերը, մասնավոր անունները լուծվում են այնտեղ, որտեղ դուք էիք նախատեսել, և ոչինչ չի լսում հոսթի այնպիսի հասցեում, որը loopback չէ։ Դրանցից յուրաքանչյուրը արտադրության մեջ ձախողվում է լուռ, և յուրաքանչյուրը վերևի մեկ տողանոց ստուգում է։