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 इन्टरफेस होइन।