VPN उपकरणका सेटिङ: सुरु हुँदाको वातावरण कि हुकभित्रको निर्यात?
हुकले आफ्नै चाइल्ड प्रक्रियाहरू सुरु गर्छ, तपाईंले पहिले खोलिसकेको शेल होइन। सुरु हुँदाको वातावरणले निजी अन्तिम बिन्दुलाई यसलाई चाहिने त्यही एउटा आदेशमा मात्र राख्छ।
API अन्तिम बिन्दु निर्यात गर्ने VPN हुकले आफूले सुरु गर्ने प्रक्रियाहरूको वातावरण बदल्छ, टनेल उठ्दा पहिले नै खुला रहेको टर्मिनलको होइन। यही एउटा भिन्नताले «उपकरणले अझै सार्वजनिक अन्तिम बिन्दु बोलाइरहेको छ» भन्ने अधिकांश रिपोर्टहरू व्याख्या गर्छ। सेटिङ राख्न दुई व्यावहारिक ठाउँ छन्, र छनोट यसलाई कसले प्रयोग गर्छ र कति बार बदलिन्छ भन्नेमा निर्भर गर्छ। अर्को स्टार्टअप स्क्रिप्ट थप्नुअघि दुवैको तुलना गर्नुहोस्।
सेटिङ बस्न सक्ने दुई ठाउँ
पहिलो विकल्प आदेशकै अगाडिको प्रिफिक्स हो: मान त्यही एउटा कलका लागि मात्र हुन्छ र त्यसैसँग हराउँछ। दोस्रो विकल्प जडान हुकभित्रको निर्यात हो, जुन त्यस बिन्दुपछि हुकले सुरु गर्ने प्रत्येक प्रक्रियासम्म पुग्छ। ती पुगाइ र आयुमा फरक छन्, वाक्यरचनामा होइन, र त्यही भिन्नताले अधिकांश असफलता निर्धारण गर्छ।
| Property | Prefix on the command | Export from the hook |
|---|---|---|
| Who receives it | That invocation only | Children the hook starts |
| Lifetime | Until the process exits | Until the hook's own session ends |
| Leakage | Scoped to one command | Applies to later commands in that session |
| Repeat cost | Every invocation | Once per connection |
| Works for an open editor | No, unless the editor is started with it | No |
तालिकाले हुकलाई सस्तो देखाउँछ र वास्तविक बिल लुकाउँछ: यसले कामसँग कुनै सम्बन्ध नभएका आदेशहरूका लागि पनि निजी अन्तिम बिन्दु छान्छ। हरेक पङ्क्तिलाई प्राथमिकता होइन, सीमा मानेर पढ्नुहोस्। अन्तिम बिन्दु कामअनुसार बदलिन्छ भने, एक किस्ट्रोक खर्चिए पनि प्रिफिक्स शुद्धतामा जित्छ।
हुकले पहिले नै खुला शेलसम्म किन पुग्न सक्दैन
प्रक्रियाको इमेज बन्दा वातावरण चरहरू प्रक्रियालाई दिइन्छ। जडानअघि सुरु भएको शेलले पाएको प्रतिलिपि राख्छ, र हुकभित्र चलाइएको निर्यात मेसिनका हरेक प्रक्रियामा हुने प्रसारण होइन। यसलाई हुकका आफ्नै चाइल्डले मात्र उत्तराधिकारमा पाउँछन्। शेलका आफ्नै चाइल्डले ती सुरु हुने क्षणमा शेलसँग जे छ त्यो लिन्छन्, त्यसैले एउटै आदेश एउटा टर्मिनलमा चल्न सक्छ र अर्कोमा असफल हुन्छ।
यही कुरा ग्राफिकल एडिटरमा पनि लागू हुन्छ। यसको एक्सटेन्सन होस्ट, अन्तर्निर्मित टर्मिनल र पृष्ठभूमिको भाषा सर्भर सुरु हुँदा फाटेर आफ्नै प्रतिलिपि राख्छन्। फोल्डर फेरि खोल्दा ती चाइल्ड पुनः सुरु हुन्छन् भन्ने छैन, त्यसैले तपाईंले थपेको सेटिङ अझै पनि कहिल्यै पुग्दैन।
सबैभन्दा सस्तो परीक्षण चलिरहेको शेलबाट होइन, असफल हुने ठाउँबाट चर प्रिन्ट गर्नु हो। असफल हुने प्रक्रिया टनेलभन्दा अघि सुरु भएको थियो भने, निर्यातसँग कुनै अवसर थिएन।
प्रत्येक आदेशको स्वरूप, लेखिएको
प्रिफिक्सले छनोटलाई यसलाई प्रयोग गर्ने आदेशभित्रै देखिने राख्छ, जुन कामहरूबीच अन्तिम बिन्दु बदलिँदा सहयोगी हुन्छ:
env INTERNAL_API='https://internal-api.example.net:8443' my-work-toolआदेश केवल उदाहरण हो: my-work-tool प्लेसहोल्डर हो र INTERNAL_API VPN मानक होइन, त्यसैले तपाईंले साँच्चै चलाउने कार्यक्रमको कागजात गरिएको सेटिङ र आफ्नो स्वीकृत होस्ट राख्नुहोस्। एउटै लाइनमा टोकन वा पासवर्ड नराख्नुहोस्, किनकि त्यो शेलको इतिहासमा जान्छ।
जब धेरै आदेश एउटै कामका हुन्छन्, छोटो समीक्षा गरिएको आवरण स्क्रिप्टले चरहरू सेट गर्छ र त्यसपछि तिनीहरू सुरु गर्छ। यसले एउटै परिभाषा राख्छ, मानलाई टर्मिनलका हरेक भावी आदेशका लागि विश्वव्यापी बनाउँदैन।
पुन: लोड गर्नुहोस्, पुन: सुरु गर्नुहोस् वा त्यसै रहन दिनुहोस्
पहिले नै चलिरहेको उपकरणका लागि, भएमा यसकै पुन: लोड वा कार्यक्षेत्र प्रोफाइललाई प्राथमिकता दिनुहोस्। नभए काम सुरक्षित गरेर सेटिङ पढ्ने घटक पुन: सुरु गर्नुहोस्, जो प्रायः भाषा सर्भर हुन्छ, एडिटरको विन्डो होइन। विन्डो पुन: सुरु गरेर चाइल्ड प्रक्रिया त्यसैपछि आए भन्ने मान्नु नै पुन: लोड काम नगरेको जस्तो देखिनुको कारण हो।
डिस्कनेक्सन छुट्टै निर्णय हो। रोक्नु, बन्द गर्नु वा पुन: जोडिनु अनुप्रयोगको कुरा हो, र अन्तिम बिन्दुको चरले त्यसलाई नियन्त्रण गर्दैन। चरलाई ठेगाना छान्ने कन्फिगरेसन मान्नुहोस्, पछि कुन नेटवर्क ट्राफिक प्रयोग गर्न सकिन्छ भन्ने नियम होइन, र दुवै कुरा छुट्टै रहन्छन्।