पूरा टनेलले तपाईंको SSH सत्र मार्यो: फर्कने मार्ग पिन गर्नुहोस्

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

redirect-gateway ले वास्तवमा के स्थापना गर्छ

आफ्नो def1 रूपमा redirect-gateway पूर्वनिर्धारित मार्ग पुनः नलेखी 0.0.0.0/1 र 128.0.0.0/1 थप्छ। यी दुई आधा भागहरूले सम्पूर्ण ठेगाना क्षेत्र ढाक्छन् र दुवै 0.0.0.0/0 भन्दा लामो प्रिफिक्स रहन्छन्, त्यसैले अझ विशिष्ट मिलान नभएको कुनै पनि गन्तव्य अहिले टनेलमा जान्छ। यही सम्झनुपर्ने संयन्त्र हो, किनकि तलका हरेक सुधार अझ विशिष्ट मिलान स्थापना गरेर काम गर्छ।

तपाईंको प्रशासनिक ठेगाना ती गन्तव्यमध्ये एक हो।

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

ip route show table main | head -n 20
ip route get 198.51.100.23

तपाईंको स्रोत ठेगाना र टनेलअघिको बाटो पत्ता लगाउनुहोस्

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

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

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

आधा-पूर्वनिर्धारितलाई जित्ने होस्ट मार्ग पिन गर्नुहोस्

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

तालिका हेर्नुको सट्टा लुकअपले जाँच्नुहोस्: जवाफले eth0 र गेटवेको नाम लिनुपर्छ, कहिल्यै tun0 होइन।

OpenVPN ले पहिले नै VPN सर्भरको आफ्नै ठेगानातर्फ होस्ट मार्ग त्यही कारणले थप्छ, त्यसैले ढाँचा परिचित छ र प्रशासनिक ठेगाना केवल अर्को अपवाद हो। यसलाई सुधार्न route-nopull तर्फ नलाग्नुहोस्, किनकि यसले टनेललाई चाहिने धकेलिएका मार्गहरू फाल्छ, जसमा टाढाको सञ्जाल र DNS विकल्पहरू पनि पर्छन्।

यसलाई पुनः जडानमा टिकाउनुहोस्

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

एउटा route-up स्क्रिप्ट र नेटवर्क म्यानेजरको pre-up हुक दुवै काम गर्छन्, र भरपर्दो जाँच भनेको पुनः जडानपछि त्यही लुकअप हो।

Windows मा समतुल्य -p ले थपिएको स्थायी मार्ग हो, जुन रिबुटमा टिक्छ तर सञ्जाल बदलिएपछि पनि सही गेटवेतर्फ देखाउनुपर्छ। प्लेटफर्म जे भए पनि, मार्गको छेउमा कारण लेख्नुहोस्: अर्को प्रशासकले यो व्यवस्थापन सत्रको सुरक्षाका लागि हो भन्ने जान्नुपर्छ, सञ्जाल डिजाइनले मागेकोले होइन।

जब पिन गरिएको मार्ग पनि पर्याप्त हुँदैन

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

नीति-आधारित राउटिङ भएका होस्टलाई मार्गसँगै नियम पनि चाहिन्छ, किनकि नियम-आधारले भित्रको मार्ग विचार गर्नुअघि तालिका छान्छ। main तालिकाको मार्ग अर्को तालिकातर्फ देखाउने नियमसँग मिल्ने प्रवाहका लागि अदृश्य हुन्छ। main मा केही थप्नुअघि नियमहरू पढ्नुहोस्। यदि कुनै नियमले पहिले नै व्यवस्थापन ट्राफिक ढाक्छ भने, अपवाद त्यो नियमको तालिकामा पर्छ।

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