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 नसलेल्या होस्ट पत्त्यावर काहीही ऐकत नाही। त्यांपैकी प्रत्येक उत्पादनात गुपचूप अपयशी होतो, आणि प्रत्येक वरील एका ओळीची तपासणी आहे।

संबंधित लेख