Docker मध्ये OpenVPN: किमान क्लायंटला आवश्यक रनटाइम करार

VPN क्लायंट कंटेनरमध्ये ठेवा आणि आत बोगदा असलेली एक नेमस्पेस मिळते, सर्व रहदारी VPN मधून राउट करणारा होस्ट नाही। हे वेगवेगळे प्रकल्प आहेत, आणि त्यांना एक मानणे हाच कंटेनर अपघाताने विशेषाधिकारित होण्याचा मार्ग आहे। हे मार्गदर्शक फक्त पहिल्याला आवृत्त करते: एक पुनरावलोकन केलेली इमेज, एक संरक्षित प्रोफाइल आणि स्वतःच्या नेटवर्क नेमस्पेसपुरता मर्यादित क्लायंट प्रक्रिया।

कोणीतरी आधीच मंजूर केलेल्या कलाकृतीपासून सुरुवात करा। खालील पायऱ्या अशा इमेजची अपेक्षा करतात ज्यात openvpn कार्यान्वित फाइल आणि प्रमाणपत्र व किल्ली सामग्री माउंटच्या आत आधीच सोडवलेले पूर्ण क्लायंट प्रोफाइल आहे। ते सॉफ्टवेअर बनवत नाहीत, क्रेडेन्शियल जारी करत नाहीत आणि root नसलेल्या रनटाइम आणि नेटिव्ह Windows कंटेनर व्यापत नाहीत, त्यातील प्रत्येक उत्तर बदलते।

कंटेनरला काय मिळते आणि काय नाही

प्रोफाइल आणि ते ज्याचा संदर्भ देते ते सर्व मर्यादित परवानग्यांच्या स्थानिक डिरेक्टरीत ठेवा, फक्त-वाचन म्हणून माउंट केलेले। प्रोफाइलमधील सापेक्ष मार्ग त्या माउंटच्या आत सोडवले पाहिजेत; प्रमाणपत्र प्रोफाइलपेक्षा एक डिरेक्टरी वर असते आणि कंटेनर ते कधीच पाहत नाही तेव्हा लोक ही तपशील चुकवतात।

services:
  vpn:
    image: ${VPN_CLIENT_IMAGE:?set the reviewed image reference}
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - ./vpn:/vpn:ro
    working_dir: /vpn
    entrypoint: ["openvpn"]
    command: ["--config", "/vpn/client.ovpn"]

त्या फाइलमध्ये तीन गोष्टी देतात आणि दुसरे काही मागत नाही। तुमचे डिप्लॉयमेंट धोरण असे सांगत असेल तर इमेज संदर्भ डाइजेस्टने पिन केला पाहिजे, आणि प्रोफाइल पुनरावलोकन केलेलेच असावे, होस्टवर कोणी जागेवरच संपादित केलेली प्रत नाही।

येथे फक्त-वाचन म्हणजे कंटेनर तुमच्या होस्ट फाइल्स बदलू शकत नाही; याचा अर्थ कंटेनर तुम्ही माउंट केलेली खाजगी किल्ली वाचू शकत नाही असा नाही। माउंटचा संपूर्ण हेतू हाच आहे, आणि म्हणूनच फाइल परवानग्या, मालकी आणि रहस्य होस्टवर कसे आले हे अजूनही महत्त्वाचे आहे। कमांड लाइनवर कधीही पासवर्ड देऊ नका आणि तो इमेज लेयरमध्ये भाजू नका, कारण दोन्ही नंतर साफ करता येणार नाहीत अशा ठिकाणी टिकतात।

क्षमता, entrypoint आणि त्यांच्यातील सापळा

दोन सेटिंग्ज आवश्यक आहेत आणि त्या असंबद्ध कामे करतात। NET_ADMIN कंटेनरच्या नेमस्पेसमध्ये इंटरफेस आणि मार्ग हाताळण्यास परवानगी देते। /dev/net/tun डिव्हाइस नोंद प्रक्रियेला बोगदा डिव्हाइस अजिबात उघडण्यास परवानगी देते। एक दुसऱ्याशिवाय देणे स्पष्ट अपयश निर्माण करते, जे सोयीचे आहे: नसलेले TUN डिव्हाइस उघडताना अपयशी ठरते, तर नसलेली क्षमता क्लायंट इंटरफेस कॉन्फिगर करण्याचा प्रयत्न करतो तेव्हा अपयशी ठरते।

यापैकी कोणतेही privileged: true ला न्याय्य ठरवत नाही। विशेषाधिकारित कंटेनरला सर्व क्षमता आणि डिव्हाइस प्रवेश मिळतो, आणि हे या कामाच्या भाराला आवश्यक असलेल्यापेक्षा खूप मोठे अनुदान आहे। रनटाइम विशेषाधिकार आणि क्षमतांचा संदर्भ हे अनुदान किती दूर पोहोचते हे स्पष्ट करतो। chart किंवा ब्लॉग पोस्टने ते मागितल्यास, प्रथम तपासा की गरज खरोखर नसलेला डिव्हाइस मार्ग होती की नसलेली क्षमता।

entrypoint ओव्हरराइड करणे हा चावणारा भाग आहे। openvpn थेट कॉल करणे सामान्य इमेजसाठी बरोबर आहे आणि डेमन चालवण्यापूर्वी फायरवॉल नियम, रिझॉल्व्हर फाइल्स किंवा क्रेडेन्शियल तयार करणाऱ्या कोणत्याही उत्पादन इमेजसाठी चूक आहे। ती स्क्रिप्ट ओव्हरराइड केल्यास तयारी वगळली जाते आणि अर्ध्या-कॉन्फिगर केलेल्या नेमस्पेसमध्ये उभ्या राहिलेल्या बोगद्याचे डीबग करावे लागते।

क्लायंट फोरग्राउंडमध्ये चालवा आणि तो कंटेनरची मुख्य प्रक्रिया असू द्या। डेमोनाइज होणारी प्रक्रिया लगेच बाहेर पडते, कंटेनर लूपमध्ये पुन्हा सुरू होतो, आणि आवश्यक लॉग सारखेच दिसणाऱ्या पुनःसुरुवातींमध्ये विखुरलेले असतात।

नेमस्पेसच्या आतून पडताळा, होस्टवरून नाही

स्टॅक वर आणा, लॉगमध्ये क्लायंट जोडलेल्या स्थितीत पोहोचल्याची पुष्टी करा, आणि नंतर बोगदा खरोखर धारण करणाऱ्या नेमस्पेसची तपासणी करा।

docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route

पत्ता यादीत पूलमधील पत्त्यासह बोगदा इंटरफेस दिसावा, आणि मार्ग तक्त्यात त्याकडे निर्देश करणारे पुश केलेले गंतव्य दिसावेत। इंटरफेस नसल्यास, क्लायंट तो तयार करण्याच्या टप्प्यापर्यंत कधीच पोहोचला नाही। तो असला तरी कोणताही मार्ग त्याचा वापर करत नसेल, तर शोधण्याचे ठिकाण push किंवा मार्ग पर्याय आहेत।

नंतर तुमच्यासाठी महत्त्वाचे गंतव्य बोगदा वापरायच्या नेमस्पेसमधून, फक्त ping नाही तर अनुप्रयोगाने तपासा। नाव निराकरण हे वेगळे अपयश आहे जे स्पष्टपणे तपासण्यासारखे आहे: पुश केलेला DNS पत्ता कंटेनरचा रिझॉल्व्हर स्वतः अद्ययावत करत नाही, आणि push दुर्लक्षिणारा स्वतंत्र क्लायंट इमेजने कॉन्फिगर केलेल्यामार्फत नावे सोडवेल।

डिस्कनेक्ट केलेली स्थिती कराराचा भाग आहे

पुन्हा जोडण्याच्या वर्तनासाठी स्वतःची तपासणी आवश्यक आहे, कारण पुनःसुरुवात धोरण प्रक्रिया पुन्हा सुरू होते हे सिद्ध करते आणि त्या दरम्यान रहदारी काय करते याबद्दल काहीच सांगत नाही। बोगदा थांबवा, इच्छित गंतव्य वापरून पाहा आणि कनेक्शन नाकारले जाते, अडकते की कंटेनरच्या नेहमीच्या मार्गाने शांतपणे यशस्वी होते हे पाहा। शेवटचा निकाल महत्त्वाचा आहे, आणि तो निरोगी लॉगमध्ये अदृश्य आहे।

कामाच्या भाराने कधीही नेहमीचा मार्ग वापरू नये असे असेल, तर फायरवॉल नियम आणि नेमस्पेसच्या आत तयारीच्या संकेतासह ते स्पष्टपणे रचा। Kill switch हे तुम्ही लिहिता आणि तपासता असे धोरण आहे, कंटेनरमध्ये क्लायंट चालवून मिळणारा गुणधर्म नाही।

शेवटी, मर्यादा लक्षात ठेवा: हे मार्ग कंटेनरच्या नेमस्पेसमध्ये राहतात आणि होस्टच्या राउटिंग तक्त्याची जागा घेत नाहीत। Docker चे फॉरवर्डिंग, अनुवाद आणि फायरवॉल नियम बाह्य मार्गाचा भाग राहतात, आणि प्रकाशित पोर्ट VPN इंटरफेस नाही।