VPN खुला छ, VM पहुँचयोग्य छैन? मार्ग सायद कहिल्यै समस्या थिएन

VPN जोड्नुहोस्, र एक मिनेट अघि जवाफ दिइरहेको विकास VM चुपचाप हुन्छ। स्पष्ट कथा आफै लेखिन्छ: टनेलले मार्ग लियो, होस्ट अब अतिथिको ट्राफिक कर्पोरेट नेटवर्कमा पठाउँछ, र समाधान स्थिर मार्ग थप्नु वा एडाप्टरलाई पुल मोडमा बदल्नु हो। त्यो कथा कहिलेकाहीँ सत्य हुन्छ। तर यो सामान्य कारण होइन, र यसका आधारमा पहिले कार्य गर्दा सामान्यतया अरू केही बिग्रन्छ।

host-only नेटवर्किङ होस्टको स्वामित्वमा रहेको र यसका अतिथिहरूसँग साझा गरिएको सफ्टवेयर नेटवर्क हो, कुनै पनि भौतिक जडानबाट अलग। VPN क्लाइन्टको आफ्नै इन्टरफेसमा केहीले पनि त्यो नेटवर्क बदल्दैन, त्यसैले यसलाई छुनु अघि चार तहमध्ये कुनले साँच्चै असफल भयो पत्ता लगाउनुहोस्।

मार्ग सामान्यतया अझै स्थानीय हुन्छ

राउटिङ तालिकाको पहिलो पृष्ठको सट्टा कर्नेललाई सोध्नुहोस्। लिनक्समा ip route get 192.168.56.10 ले प्रयोग हुने ठ्याक्कै मार्ग, इन्टरफेस र स्रोत ठेगाना जनाउँछ, जुन डिफल्ट मार्ग पढेर अनुमान गर्नुभन्दा फरक उत्तर हो। यदि आउटपुटले host-only इन्टरफेसको नाम लिन्छ भने टनेल त्यो बाटोमा बिल्कुल संलग्न छैन।

दुई कुराले साँच्चै यसलाई तोड्न सक्छन्, र दुवै VPN नभई ठेगानाका समस्या हुन्। host-only प्रिफिक्ससँग ओभरल्याप हुने टाढाको सबनेटले बढी विशिष्ट मार्गलाई जिताउँछ, र कम मेट्रिकसहित फराकिलो मार्ग स्थापना गर्ने VPN क्लाइन्टले प्रिफिक्स तान्न सक्छ। दुवै एउटै आदेशमा देखिन्छन्: आउटपुटमा नाम दिइएको इन्टरफेस टनेल हुनेछ, र सुधार त्यो ठेगाना योजनाको मालिकको हो।

मार्ग छनोट र प्याकेट स्वीकृति दुई फरक निर्णय हुन्

यो त्यो भाग हो जुन मानसिक मोडेलले सामान्यतया छुटाउँछ। पूर्ण स्थानीय मार्ग भए पनि VPN क्लाइन्टले प्याकेट अस्वीकार गर्न सक्छ। धेरै क्लाइन्टले स्थानीय नेटवर्क पहुँच नीति लागू गर्छन् जसले टनेल बाहिर कुन गन्तव्य अनुमत छन् भनेर निर्धारण गर्छ, र जोडिएको सबनेटले त्यो सूची स्वतः अद्यावधिक गर्दैन।

त्यसैले असफलता अनुप्रयोगको तर्फबाट राउटिङ समस्याजस्तै देखिन्छ, र क्लाइन्टको तर्फबाट पूर्ण रूपमा फरक। यदि ip route get ले सही इन्टरफेसको नाम लिन्छ र जडान अझै समय सकिन्छ भने, मार्ग सम्पादन गर्न रोक्नुहोस् र यसको सट्टा क्लाइन्टको कागजात गरिएको स्थानीय पहुँच व्यवहार पढ्नुहोस्। केही क्लाइन्टले स्थानीय सबनेटका लागि अनुमति सूची दिन्छन्, केहीले टनेल नभएको सबै रोक्छन्, र केहीले किल स्विच सक्रिय हुँदा मात्र रोक्छन्।

त्यो भिन्नता महत्त्वपूर्ण छ किनकि सुधारहरू एकापसमा बदल्न मिल्दैनन्। मार्ग थप्दा फिल्टर सन्तुष्ट हुँदैन, र एउटा अतिथिसम्म पुग्न फिल्टर बन्द गर्नु लक्षणले संकेत गरेभन्दा धेरै ठूलो निर्णय हो।

अतिथिसँग नाइँ भन्ने तीन तरिका छन्

इन्टरनेट ब्राउज गर्न सक्ने अतिथिले तपाईंले चाहेको सेवाबारे केही पनि प्रमाणित गरेको छैन। सुन्नेले अतिथिभित्र 127.0.0.1 मा बाँधिएको हुन सक्छ, र त्यस्तो अवस्थामा मार्ग जतिसुकै राम्रो भए पनि होस्टबाट कुनै अनुरोध पुग्न सक्दैन। अतिथिमा ss -ltn प्रयोग गरी जाँच्नुहोस् र पोर्ट मात्र नभई स्थानीय ठेगाना स्तम्भ हेर्नुहोस्।

अर्को अतिथिको आफ्नै फायरवाल हो। कडा डिफल्ट भएको विकास इमेजले होस्टका प्याकेट स्वीकार गरेर सेवाको सीमामा खसाल्न सक्छ, जसले राउटिङ कालो प्वालजस्तै देखिने समय समाप्ति उत्पन्न गर्छ। अन्तमा सेवाको आफ्नै कन्फिगरेसन छ: निश्चित होस्टनामसँग बाँधिएको वेब अनुप्रयोग, वा क्लाइन्ट ठेगानाको अनुमति सूची, प्रत्येक प्याकेट पुगे पनि host-only सबनेटबाट आएको अनुरोध अस्वीकार गर्नेछ।

VM को नेटवर्क मोड बदल्ने विचार गर्नु अघि यी तीन पूरा गर्नुहोस्। प्रत्येक अतिथिको जडान पुनः डिजाइन गर्नुभन्दा सानो परिवर्तन हो, र प्रत्येकको स्पष्ट परीक्षण छ।

पुल वास्तवमा के हो, र यसको मूल्य कति

एडाप्टरलाई पुल मोडमा बदल्नु host-only मार्गको मर्मत होइन। यो अतिथिलाई अर्को नेटवर्कमा, सामान्यतया भौतिक LAN मा राख्ने निर्णय हो, जहाँ ऊ त्यहाँ बस्ने अरू सबैका लागि देखिने हुन्छ। त्यो ठ्याक्कै तपाईंले चाहेको हुन सक्छ। तर मूल कन्फिगरेसनले गरिरहेको कुरा त्यो होइन।

अतिथि साँच्चै त्यो LAN मा समान सदस्य हुनु आवश्यक भए र जोखिम स्वीकृत भएमा यो प्रयोग गर्नुहोस्। एउटा मात्र सेवाले जवाफ दिन छोड्यो भनेर यो प्रयोग नगर्नुहोस्, किनकि परिवर्तनले अतिथिलाई यसको विरुद्ध विकास सुरक्षित बनाएको अलगावबाट बाहिर निकाल्न सक्छ।

कुनै पनि स्वीकृत सुधारपछि निश्चित क्रममा परीक्षण गर्नुहोस्: होस्टबाट अतिथिमा नयाँ अनुरोध, टनेलमार्फत आवश्यक कर्पोरेट स्रोत, र टनेल बन्द हुँदा अभिप्रेत अस्वीकृत व्यवहार। यदि अन्तिम अब लागू हुँदैन भने सुधार समस्याभन्दा पर गएको छ।

VirtualBox को host-only नेटवर्किङ खण्ड ले होस्टको तर्फको सफ्टवेयर इन्टरफेस र पुल जडानबाट यो कसरी फरक छ भन्ने वर्णन गर्छ, र दुई मोडलाई बदल्न मिल्ने ठान्नु अघि पढ्न लायक सन्दर्भ यही हो।