नयाँ राउटर, उही VPN सर्भर: यसको सार्वजनिक प्रवेश सार्नुहोस्

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

परिवर्तनलाई एक होइन, दुई हस्तान्तरण मान्नुहोस् र काम गर्दा प्रशासन इन्टरफेसमा पुग्ने स्थानीय बाटो राख्नुहोस्।

प्लग निकाल्नु अघि हस्तान्तरण लेख्नुहोस्

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

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

त्यो अभिलेख सुरक्षित ठाउँमा राख्नुहोस्। राउटर ब्याकअपमा WAN लिङ्कका प्रमाणहरू हुन सक्छन्। निर्यात फाइललाई सेटिङको नोट होइन, पासवर्डजस्तै व्यवहार गर्नुहोस्।

पहिले ठेगाना सार्नुहोस्, त्यसपछि फर्वार्ड

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

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

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

सार्वजनिक नाम कसले अद्यावधिक गर्ने निर्णय गर्नुहोस्

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

जब तैनाथी दुवै ठेगाना परिवार प्रकाशित गर्छ, A र AAAA दुवै रेकर्ड पढ्नुहोस्। प्रत्येकले साँच्चै सुनिरहेको र आफ्नै फायरवाल मार्गबाट अनुमति पाएको सेवातिर देखाउनुपर्छ, र चल्ने IPv4 म्यापिङले IPv6 पक्षबारे केही भन्दैन। ग्राहक प्रोफाइलका पहिचान जाँच पनि राख्नुहोस्: बदलिएको सार्वजनिक ठेगाना नमिल्ने प्रमाणपत्र वा सहकर्मी कुञ्जी स्वीकार गर्ने कारण होइन।

बाहिरबाट परिवर्तन प्रमाणित गर्नुहोस्

LAN भित्रबाट होइन, अधिकृत बाह्य जडान र नयाँ सत्रबाट परीक्षण गर्नुहोस्। सार्वजनिक ठेगानाविरुद्धको आन्तरिक परीक्षण हेयरपिन व्यवहारमा निर्भर हुन्छ र वास्तविक ग्राहकले जाने बाटोभन्दा फरक बाटो जान्छ।

ग्राहकले पछ्याउने क्रम पछ्याउनुहोस्: नाम समाधान गर्नुहोस्, टनेलमा वार्ता गर्नुहोस्, पहिचान प्रमाणित गर्नुहोस्, त्यसपछि निजी स्रोतमा एउटा कार्य गर्नुहोस्। त्यही अन्तिम चरण मानिसले छाड्छन्, र फर्किने बाटो प्रमाणित गर्ने त्यही मात्र हो। लगइन सफल भई निजी कार्य असफल भए, नयाँ LAN प्रिफिक्स, ग्राहकले छानेका मार्ग र स्रोतको जवाफ मार्गलाई तपाईंको हस्तान्तरण नोटसँग तुलना गर्नुहोस्।

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

नयाँ म्यापिङ तपाईंको पुनःप्राप्ति नोटसँग राख्नुहोस्

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

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