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

व्यवस्थापन खण्डबाट सुरु गर्नुहोस्

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

त्यसपछि दुई मार्ग। VPN ग्राहकलाई व्यवस्थापन सञ्जालतर्फ मार्ग चाहिन्छ, जसको अर्थ सामान्यतया ग्राहकको AllowedIPs वा धकेलिएका मार्गहरूमा त्यो सबनेट समावेश हुन्छ। हाइपरभाइजर, वा यसको पूर्वनिर्धारित गेटवेलाई, ग्राहक ठेगाना पूलतर्फ फर्कने मार्ग चाहिन्छ, जबसम्म डिजाइनले प्रवेशमा स्रोतलाई जानाजानी अनुवाद गर्दैन। यी दुई अलग तथ्य हुन् र जुनसुकै एउटा नभए त्यही समय समाप्ति हुन्छ। तिनीहरूलाई अलग जाँच्नुहोस्: ग्राहकमा ip route get 192.168.10.20, र हाइपरभाइजर होस्टमा प्याकेट आयो कि भनेर देखाउने क्याप्चर।

वास्तविक टाढाको प्रशासकलाई अनुमति दिनुहोस्

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

हाइपरभाइजरको आफ्नै प्रमाणीकरण र प्रमाणपत्र जाँच सक्रिय राख्नुहोस्। निजी मार्ग अप्रत्याशित पहिचान चेतावनीबाट क्लिक गर्ने कारण होइन।

चेतावनीलाई बाधा नभई निष्कर्षका रूपमा लिनु उपयुक्त हुन्छ। यदि प्रमाणपत्र तपाईंले प्रयोग गरेको नामसँग मेल खाँदैन भने या त नाम गलत छ या सेवा तपाईंले सोचेको होइन, र दुवै उत्तर व्यवस्थापन इन्टरफेसमा अन्यत्रभन्दा बढी महत्त्वपूर्ण छन्। प्रमाणपत्र जारी भएको नामबाट पृष्ठमा पुग्नुहोस्, र DNS लाई त्यो नाम टनेल ठेगानातर्फ देखाउन दिनुहोस्। LAN र टनेलबीच असंगत रूपमा समाधान हुने निजी नाम VPN खराबीजस्तो देखिने प्रमाणपत्र उजुरीको सामान्य कारण हो।

दोस्रो दर्जाका जडानहरू जाँच्नुहोस्

केही सुविधाहरूले वेब पृष्ठले प्रयोग नगर्ने जडान प्रयोग गर्छन्। कन्सोल सत्र, ISO अपलोड, VNC वा SPICE प्रोक्सी र माइग्रेसन च्यानलले प्रत्येक फरक पोर्ट वा फरक होस्ट ठेगाना प्रयोग गर्न सक्छन्। पृष्ठ लोड भएर एउटा सुविधा असफल हुँदा होस्टमा हरेक पोर्ट खोल्नुको सट्टा त्यो उत्पादनको आवश्यकता पढ्नुहोस्।

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

सञ्जाल छुनु अघि फर्कने बाटो राख्नुहोस्

तपाईंको आफ्नै VPN बोक्ने भर्चुअल सञ्जाल परिवर्तन गर्नु अघि स्थानीय वा स्वतन्त्र फर्कने बाटो छ भनी पुष्टि गर्नुहोस्।

यो होम ल्याबमा सबैभन्दा महत्त्वपूर्ण छ, किनकि VPN अन्त्य बिन्दु प्रायः तपाईंले पुग्न खोजेको हाइपरभाइजरमै भर्चुअल मेसिन हुन्छ। भर्चुअल स्विच, ब्रिज वा फायरवाल नियम टाढाबाट परिवर्तन गर्दा तपाईंले प्रयोग गरिरहेको मार्ग हट्न सक्छ, र सत्र त्यो हुँदै गरेको देख्ने जति टिक्न सक्छ।

LAN बाट नभई ल्याब बाहिरबाट परीक्षण गर्नुहोस्, र अनुमतिजस्तै अस्वीकृति पनि प्रमाणित गर्नुहोस्। टनेलबाट पहुँचयोग्य नहुनुपर्ने सञ्जाल तपाईंको परिवर्तनपछि पनि पहुँचयोग्य नहुनुपर्ने हो, र यो व्यवस्थापन पृष्ठ लोड हुनुभन्दा अलग दाबी हो। दुवै नतिजा लेख्नुहोस्, किनकि दोस्रो नै छाडिने र ल्याब बढ्दा महत्त्वपूर्ण हुने हो।

राख्नुपर्ने अभिलेख छोटो छ: व्यवस्थापन ठेगाना र सेवा, प्रत्येक पक्षलाई चाहिने मार्ग, पुग्न अनुमति पाएका पहिचान, र पुनर्प्राप्ति मार्ग। अर्को व्यक्तिले काम गर्ने अवस्था पुनः निकाल्नु नपरी पुनरुत्पादन गर्न यत्ति नै पर्याप्त छ।

यी सबैपछि पनि पृष्ठको समय सकिन्छ भने अर्को नियम परिवर्तन गर्नु अघि हाइपरभाइजरमा क्याप्चर गरी प्याकेट खोज्नुहोस्। कहिल्यै नआउने प्याकेट रुटिङ वा फायरवालको प्रश्न हो; आएर अस्वीकार गरिने प्याकेट सेवा वा नीतिको प्रश्न हो; ग्राहक पर्खिरहेका बेला आएर जवाफ पाउने प्याकेट फर्कने मार्गको प्रश्न हो। strongSwan को अग्रसारण कागजात ले Linux गेटवेले टनेल ट्राफिक आन्तरिक होस्टतर्फ कसरी अग्रसारण गर्छ भन्ने व्याख्या गर्छ। तीन क्याप्चरले अर्को एउटा अनुमानलाई जित्छ।

सम्बन्धित लेखहरू