Docker VPN કન્ટેનર દ્વારા હોસ્ટ ટ્રાફિક કેવી રીતે રૂટ કરવો

VPN કન્ટેનર નેટવર્ક નેમસ્પેસ છે, પ્રોક્સી નહીં। શેર કરેલ netns, વાસ્તવિક SOCKS શ્રોતા કે રૂટ કરેલ ગેટવે પસંદ કરો, પછી એક્ઝિટ પાથ ચકાસો।

તમારું ટનલ કન્ટેનર કામ કરે છે, docker compose exec vpn curl -s https://ifconfig.me પ્રદાતાના સરનામા સાથે જવાબ આપે છે, અને તોપણ તમારા ડેસ્કટોપનું બ્રાઉઝર હજી તમારા ISP દ્વારા બહાર જાય છે। એ અંતર અપેક્ષિત છે। VPN ક્લાયન્ટ ચલાવતું કન્ટેનર નેટવર્ક નેમસ્પેસ, રૂટ અને ટનલ ઇન્ટરફેસ રાખે છે, અને HTTP કે SOCKS બોલતું કંઈ નહીં; તેના પર પોર્ટ પ્રકાશિત કરવાથી એવો શ્રોતા બની શકતો નથી જે કદી હતો જ નહીં।

ક્લાયન્ટ ક્યાં ચાલે છે તે ડિઝાઇન નક્કી કરે છે। પડોશી કન્ટેનર ટનલના નેમસ્પેસમાં જઈ શકે છે, ડેસ્કટોપ એપ્લિકેશન જઈ શકતી નથી, અને રાઉટરને પ્રોક્સી ફીલ્ડ નહીં પણ રૂટ જોઈએ। મેપિંગ ખોટું કરો તો લક્ષણ એ જ રહે છે: કનેક્શન નકારાયું, અથવા ટ્રાફિક ચૂપચાપ જૂના માર્ગે જાય છે।

ગોઠવણને ક્લાયન્ટ ક્યાં ચાલે છે તેની સાથે મેળવો

Compose સંપાદિત કરતાં પહેલાં એક પ્રશ્ન પૂછો: શું ક્લાયન્ટને VPN કન્ટેનરના નેટવર્ક નેમસ્પેસની અંદર શરૂ કરી શકાય? પહેલેથી Linux કન્ટેનર તરીકે ચાલતું કોઈપણ કંઈ કરી શકે। તમારા ડેસ્ક પરનું બ્રાઉઝર, IDE કે CLI કરી શકતું નથી, કારણ કે તેનું પ્રોક્સી સેટિંગ પ્રોટોકોલ સેવા ધારે છે, નેમસ્પેસ નહીં।

ClientArrangementWhat must already exist
Another Compose serviceShares the vpn namespace via network_mode: service:vpnA working tunnel and correct start order
Host browser, IDE or CLIProxy listener inside the namespace, published to host loopbackA configured SOCKS or HTTP proxy and its access rules
Router, VM or phoneThe container as a layer-3 gatewayForwarding, 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

જો રૂટ યાદીમાં ટનલ ઇન્ટરફેસ હોય અને સરનામું પ્રદાતાનું હોય, તો એપ્લિકેશન ટનલની અંદર છે। જો ઇન્ટરફેસ ન હોય, તો vpn પાસે ટનલ આવ્યા પહેલાં app શરૂ થયું છે, તેથી vpn સ્વસ્થ હોવાનું જણાવે પછી app ફરી બનાવો।

હોસ્ટ ક્લાયન્ટ માટે નેમસ્પેસમાં વાસ્તવિક પ્રોક્સી શ્રોતા મૂકો

ડેસ્કટોપ બ્રાઉઝર નેમસ્પેસમાં જોડાઈ શકતું નથી, તેથી ટનલને સેવા તરીકે ખુલ્લી કરવી પડે। vpn નેમસ્પેસની અંદર ખરેખરું SOCKS કે HTTP પ્રોક્સી ચલાવો અને ફક્ત તેનો પોર્ટ પ્રકાશિત કરો:

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 ખાતામાંથી મોકલે છે, અને ટનલ પડે તો kill switch પ્રમાણે કાં LAN અંધારું થાય છે કાં ISP પર પાછું જાય છે।

એક્ઝિટ પાથ ચકાસો, પછી ક્રમમાં પાછું ફેરવો

આ ક્રમમાં તપાસો અને પ્રથમ નિષ્ફળતાએ થોભો: નેમસ્પેસની અંદરનું એક્ઝિટ સરનામું, હોસ્ટથી પ્રોક્સી દ્વારા એક્ઝિટ સરનામું, પછી ખાનગી હોસ્ટ માટે નામ ઉકેલ।

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

પ્રથમ બે સરનામાં પ્રદાતા સાથે મેળ ખાવા જોઈએ, અને ત્રીજું નામ-ભૂલથી નિષ્ફળ થવાને બદલે પ્રોક્સી દ્વારા ઉકેલાવું જોઈએ। પ્રથમ લીટી મેળ ખાય અને બીજી નિષ્ફળ જાય તેનો અર્થ શ્રોતા કે પ્રકાશિત પોર્ટ ખોટું છે, ટનલ નહીં।

પાછું ફેરવવું એ ગોઠવણનું ઊલટું છે। શેલ પ્રોફાઇલ અને કોઈપણ systemd યુનિટમાંથી પ્રોક્સી એન્વાયર્નમેન્ટ વેરિયેબલ દૂર કરો, પછી સ્ટેક નીચે ઉતારો જેથી શેર કરેલ નેમસ્પેસ તેના માલિક સાથે અદૃશ્ય થાય। પ્રોક્સી સેવા કાઢતાં પહેલાં પ્રકાશિત પોર્ટ કાઢો, નહીં તો હોસ્ટ પર એવો loopback શ્રોતા રહી જાય છે જે કોઈ વાંચતું નથી।

આગળ વધતાં પહેલાં ચાર વસ્તુ ખાતરી કરો: તમને જે ક્લાયન્ટની ચિંતા છે તે ખરેખર ટનલ સુધી પહોંચે છે, ફક્ત નેમસ્પેસનો માલિક પોર્ટ પ્રકાશિત કરે છે, ખાનગી નામ તમે ઇચ્છ્યું તે જગ્યાએ ઉકેલાય છે, અને loopback ન હોય તેવા હોસ્ટ સરનામે કંઈ સાંભળતું નથી। એમાંથી દરેક ઉત્પાદનમાં ચૂપચાપ નિષ્ફળ જાય છે, અને દરેક ઉપરની એક-લીટીની તપાસ છે।

સંબંધિત લેખો