pfSense लाई VPN सर्भर र क्लाइन्टको रूपमा: दुई बाटो, एउटा राउटर

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

कुनै पनि सेटिङ छुनुअघि दुई भूमिकाको नाम राख्नुहोस्

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

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

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

सर्भरका जवाफहरू WAN बाटोमै राख्नुहोस्

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

बाहिर जाने टनेललाई आफ्नै अन्त्यबिन्दु खान नदिनुहोस्

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

कुन प्रयोगकर्ताले निकास पाउने छन् छान्नुहोस्

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

निकास असफल हुँदा के हुन्छ निर्णय गर्नुहोस्

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

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

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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