OpenVPN को पूर्ण टनेलले तपाईंको SSH सत्र काट्छ: फर्किने बाटो सुधार्नुहोस्

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

VPN लग पढ्नु अघि रुटिङ तालिका पढ्नुहोस्। लगले टनेल माथि आयो भन्नेछ, र त्यो सही छ। प्रश्न यो हो कि हरेक जवाफ कुन इन्टरफेसमा दिइन्छ, र त्यो टनेलले भर्खरै पुनलेख गरेको तालिकामा हरेक प्याकेटको खोजी हो।

जवाफ किन गलत ढोकाबाट बाहिर जान्छ

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

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

एउटा प्रिफिक्स गल्ती चाँडै बहिष्कृत गर्न लायक छ। लम्बाइ नभएको ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 ले एकल ठेगाना 0.0.0.0 सँग मिल्छ, इन्टरनेटसँग होइन; त्यो 0.0.0.0/0 हुनुपर्छ। र यदि पूर्वनिर्धारित लिनुले टनेलको आफ्नै यातायात तोड्छ भने, अन्त्य बिन्दुलाई भौतिक इन्टरफेसबाट होस्ट रुटका रूपमा थप्नुहोस्, प्रदायकको वास्तविक ठेगाना प्रयोग गरेर।

तत्काल सुधारका लागि तपाईंको SSH क्लाइन्ट ठेगाना पिन गर्नुहोस्

सबैभन्दा छिटो सुधार टनेल हुनु अघि सर्भरले प्रयोग गरेको गेटवेमार्फत तपाईंको क्लाइन्ट ठेगानाका लागि होस्ट रुट हो। तपाईंको तर्फबाट सर्भरले देख्ने ठेगाना खोज्नुहोस्, अनि पुरानो गेटवे जान्न सर्भरको तालिका पढ्नुहोस्:

curl -s https://ifconfig.co
ip route

सर्भरमा, क्लाइन्ट सुरु हुनु अघि अपवाद थप्नुहोस्। यहाँका ठेगानाहरू प्लेसहोल्डर हुन्; आकार महत्त्वपूर्ण छ:

sudo ip route add 80.128.240.55 via 192.168.178.1

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

क्लाइन्टलाई पूर्वनिर्धारित रुट लिनबाट रोक्नुहोस्

अझ सफा विकल्प भनेको टनेलले पूर्वनिर्धारित रुट बिल्कुलै प्रतिस्थापन नगर्न दिनु हो। route-nopull, --client वा --pull सँग प्रयोग गर्दा, रुट, block-outside-dns र DNS सर्भरजस्ता DHCP शैलीका विकल्पबाहेक धकेलिएका विकल्प स्वीकार्छ, त्यसैले तपाईं आवश्यक प्रिफिक्स मात्र थप्नुहुन्छ। अझ साँघुरो साधन पुल फिल्टर हो, जसले एउटा समस्याग्रस्त निर्देश हटाउँछ र बाँकी राख्छ:

route-nopull
pull-filter ignore "redirect-gateway"

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

फर्किने बाटो स्रोत वा जडान अनुसार बाँड्नुहोस्

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

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

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

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

परीक्षण गर्दा जडान चिन्ह, फायरवाल चिन्ह र तालिका नम्बर अलग राख्नुहोस्। दुई भूमिकाका लागि एउटै नम्बर पुनः प्रयोग गर्दा सही देखिने तर गलत प्याकेटसँग मिल्ने नियम बन्छ। तालिकाको पूर्वनिर्धारित प्रविष्टिलाई सामान्य इथरनेट लिङ्कमा LAN गेटवेसँगै via पनि चाहिन्छ; नाङ्गो dev eth0 इन्टरफेस पोइन्ट-टु-पोइन्ट हुँदा वा अर्को हप अर्कै तरिकाले टुङ्गिने बेलामा मात्र काम गर्छ। रिपोर्ट गरिएको Jessie होस्ट नाङ्गो रूपले काम गरेको लिङ्कमा परेको थियो, जो नक्कल गर्न लायक कुनै वितरण नियम होइन।

बाहिर ताला लगाइनु बिना जाँच्नुहोस्

डिस्कनेक्ट गरेर परीक्षण नगर्नुहोस्। पहिलो सत्र खुला राख्नुहोस्, टनेल माथि ल्याउनुहोस्, र कर्नेललाई सोध्नुहोस् तपाईंको आफ्नै ठेगानाले कुन बाटो लिन्छ:

ip route get 80.128.240.55

जवाफले टनेल होइन, भौतिक इन्टरफेस र पुरानो गेटवे उल्लेख गर्नुपर्छ। अनि दोस्रो SSH जडान खोल्नुहोस्; त्यही वास्तविक परीक्षण हो, किनकि पुरानो सत्र नयाँ जडानले पुनः उत्पादन गर्न नसक्ने अवस्थामा टिकिरहन सक्छ। दोस्रो अड्किँदा पहिलोले अझै जवाफ दिइरहेको छ भने, नियम कहिल्यै महत्त्वपूर्ण ट्राफिकसँग मिलेन, र चिन्ह वा स्रोत ठेगाना हेर्नुपर्ने ठाउँ हो।

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