पूरा टनेल मार्गले किन यसलाई बोक्ने सर्भरलाई काट्छ

पूरा टनेल सक्रिय गर्नुहोस् र अब हरेक गन्तव्य VPN इन्टरफेसको हुन्छ, यसलाई अन्त्य गर्ने मेसिन पनि। टनेल बोक्ने बाहिरी प्याकेटहरू त्यही मेसिनमा सम्बोधित हुन्छन्, त्यसैले मार्गले अन्ततः आफू निर्भर रहेको यातायात नै खपत गर्छ। एउटा थप विशिष्ट मार्गले यसलाई समाधान गर्छ, र कारण बुझ्न लायक छ। त्यो कारण नभए अर्को पुनर्निर्माणले फेरि त्यही त्रुटि ल्याउँछ।

आफ्नै यातायात खाने मार्ग

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

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

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

डिफल्टअघि अपवाद स्थापना गर्नुहोस्

सर्भरका लागि एक ठेगानाको मार्ग बनाउनुहोस्, भौतिक गेटवेलाई अर्को हप बनाएर, डिफल्ट मार्ग सर्नुअघि। क्रम महत्त्वपूर्ण छ: पछि स्थापना गर्नु भनेको टाइप गर्दा भाँचिएको टनेलसँग बाँच्नु।

अधिकांश ग्राहकले यो नसोधीकनै गर्छन्। OpenVPN टाढाको ठेगाना खोज्छ र डिफल्ट गेटवे पुनर्लेखन गर्नुअघि यसलाई पिन गर्छ, र यसको route-delay विकल्प त्यस्ता प्लेटफर्मका लागि छ जहाँ यो क्रम दौडिन्छ। wg-quick पूरै फरक बाटो लिन्छ, प्याकेटहरू चिन्हित गरेर नीति नियमसँग परामर्श गरेर अपवाद थप्नुको सट्टा। फरक कार्यविधि, एउटै आवश्यकता: बाहिरी प्याकेटले आफैँले बनाएको टनेलबाट भाग्नुपर्छ।

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

खोजीको आउटपुट नै स्वीकृति परीक्षण हो। यसले भौतिक यन्त्र र भौतिक अर्को हपको नाम लिनुपर्छ। त्यो जवाफमा टनेल यन्त्र देखिनु भनेको अपवाद छुटेको छ, वा यसलाई पछि पार्ने कुनै कुरापछि राखिएको छ।

सर्भरमा ऐनाको प्रतिबिम्ब

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

टनेलले निरन्तर चोर्ने अपवादहरू

केही कामलाई टनेलसँग डिफल्ट मार्ग हुँदा पनि खुला इन्टरनेट चाहिन्छ, र हरेकलाई आफ्नै अपवाद चाहिन्छ। गतिशील DNS अपडेटर सामान्यतया पहिले बिग्रन्छ।

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

कसैले नलेखेको अपवाद त्यो अपवाद हो जसलाई अर्को पुनर्निर्माणले चुपचाप खसालिदिन्छ।

पुनः जडानपछि प्रमाणित गर्नुहोस्, अघि होइन

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

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

त्यसपछि जडान पुनः सुरु गर्नुहोस्, किनकि पुनः जडानमा आफ्नो तालिका पुनर्निर्माण गर्ने ग्राहकले तपाईंले हातले टाइप गरेको मार्ग फालिदिन्छ। kill switch चालु छ भने अन्तिम बिन्दुलाई अनुमति छ कि जाँच्नुहोस्, नत्र नेटवर्क परिवर्तनपछि टनेल फर्कन सक्दैन र लक्षण अवरोधजस्तो देखिन्छ। अपवाद shell इतिहासमा होइन, प्रोफाइल वा unit फाइलमा राख्नुहोस्, ताकि पुनः जडानले यसलाई मेटाउनुको सट्टा फेरि बनाओस्।