OpenVPN ग्राहक सर्भरसम्म पुग्छ तर LAN होस्टसम्म पुग्दैन: जाँचसूची

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

पहिलो चरण: ग्राहकको राउटिङ निर्णय हेर्नुहोस्

सर्भर छुनुअघि ग्राहकले प्याकेट टनेलमा पठाउँछ भनी प्रमाणित गर्नुहोस्। पूरा तालिका पढ्नुको सट्टा एउटा निश्चित LAN होस्टका लागि कर्नेलले कुन इन्टरफेस प्रयोग गर्छ भनी सोध्नुहोस्:

ip route get 192.168.50.10

यदि जवाफले तपाईंको भौतिक एडाप्टर र अफिस गेटवेको नाम लिन्छ भने सर्भर पक्षको कुनै पनि परिवर्तनले सहयोग गर्न सक्दैन। OpenVPN ले मार्गहरू सर्भरले धकेलेको बेला मात्र बाँड्छ, त्यसैले सर्भर कन्फिगरेसनमा push "route 192.168.50.0 255.255.255.0" खोज्नुहोस्, र त्यसपछि ग्राहक पुन: जोड्नुहोस्। अधिकांश ग्राहकले धकेलिएका मार्गहरू जोडिने बेलामा लागू गर्छन्, प्रोफाइल पुन: लोड गर्दा होइन।

Windows मा एउटै प्रश्नको अर्को आदेश छ। Find-NetRoute -RemoteIPAddress 192.168.50.10 ले स्ट्याकले छान्ने इन्टरफेस र अर्को होप छाप्छ, र route print -4 ले धकेलिएको प्रिफिक्स नै अवस्थित छ कि छैन देखाउँछ।

दोस्रो चरण: सर्भरले प्याकेट फर्वार्ड गर्छ भनी पुष्टि गर्नुहोस्

यदि ग्राहक मार्ग ठीक छ भने प्याकेट सर्भरसम्म पुग्छ, र सर्भरले त्यसलाई फर्वार्ड गर्न सहमत हुनुपर्छ। कर्नेल स्विच पहिलो ढोका हो, र sysctl net.ipv4.ip_forward ले 1 फर्काउनुपर्छ। echo 1 > /proc/sys/net/ipv4/ip_forward बाट सेट गर्नु अर्को रिबुटसम्म काम गर्छ, र ठ्याक्कै त्यसैले उही गुनासो हप्ताहरूपछि फर्केर आउँछ।

यसलाई रिस्टार्टपछि टिक्ने ठाउँमा लेख्नुहोस्:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

दोस्रो ढोका फिल्टर तालिका हो। Docker स्थापना भएको होस्टमा प्रायः FORWARD नीति DROP हुन्छ, र टनेलले त्यो निर्णय विरासतमा पाउँछ। iptables -L FORWARD -v -n ले नीति र प्याकेट काउन्टर दुवै देखाउँछ; नीति DROP भए फर्वार्डिङलाई टनेलबाट LAN दिशातर्फ एउटा स्पष्ट अनुमति र जवाफका लागि अर्को चाहिन्छ।

तेस्रो चरण: प्याकेटलाई LAN सम्म पछ्याउनुहोस् र जवाफ खोज्नुहोस्

सर्भरका दुवै पक्ष एकैचोटि हेर्नुहोस्। टनेलमा र LAN इन्टरफेसमा क्याप्चर गर्नुहोस्, एउटा ग्राहक र एउटा होस्टमा फिल्टर गरेर ताकि आउटपुट पढ्नयोग्य रहोस्:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 मा र फेरि eth0 मा 10.8.0.x स्रोतसहित देखिने अनुरोधहरू, र त्यसपछि सन्नाटा, भन्नु प्याकेट आयो र जवाफ अन्तै गयो। LAN होस्टले आफ्नो पूर्वनिर्धारित गेटवेलाई जवाफ दिन्छ, त्यो गेटवेसँग VPN पूलका लागि मार्ग छैन, र जवाफ LAN राउटरमा मर्छ। सर्भरबाट LAN होस्टलाई ping गर्नुले यो बाटोबारे केही पनि प्रमाणित गर्दैन, किनकि त्यो ट्राफिक कहिल्यै टनेल पार गर्दैन।

चौथो चरण: अनुवाद र फर्कने मार्गबीच छान्नुहोस्

दुई मर्मतले प्वाल बन्द गर्छ, र यो छनोटका परिणाम ping चल्छ कि भन्नेभन्दा पर जान्छन्। स्रोत अनुवादले सर्भरलाई देखिने प्रेषक बनाउँछ:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

नियमलाई पूल र LAN इन्टरफेसमा सीमित गर्नुहोस्, त्यसपछि स्थायी बनाउनुहोस्, नत्र अर्को फायरवाल रिलोडले तपाईंको मर्मत चुपचाप हटाउनेछ। मूल्य पहिचान हो: LAN लग र पहुँच नियमहरूमा हरेक ग्राहक VPN सर्भरजस्तै देखिन्छ, र per-client policy becomes guesswork।

LAN राउटरमा VPN सर्भरतर्फ सङ्केत गर्ने 10.8.0.0/24 को स्थिर मार्गले ग्राहक ठेगानाहरू देखिने राख्छ र त्यो राउटर तपाईंको भए दीर्घकालीन रूपमा राम्रो जवाफ हो। धेरै साइटहरू केही समय दुवै चलाउँछन्, तत्काल मर्मतका लागि NAT र फायरवाल नीति लेखिएपछि मार्ग। यदि सर्भर पूल होइन, साइट-देखि-साइट साथी हो भने सर्भर पक्षलाई पनि टाढाको सबनेटका लागि iroute चाहिन्छ, नत्र साथीको मार्ग हुन्छ तर ग्राहक ट्राफिक त्यससँग कहिल्यै जोडिँदैन।

पाँचौं चरण: ग्राहकबाट प्रमाणित गर्नुहोस् र के बदलियो लेख्नुहोस्

लूप सर्भरबाट होइन, ग्राहकबाट बन्द गर्नुहोस्। LAN होस्टको वास्तविक सेवामा जोडिनुहोस्, त्यसपछि iptables -t nat -L POSTROUTING -v -n बाट अनुवाद काउन्टर सरेको पुष्टि गर्नुहोस्, किनकि शून्य प्याकेटको नियम त्यो नियम हो जो कहिल्यै मिलेन। फर्कने दिशा ट्र्याक भइरहेको प्रमाण चाहिँदा conntrack -L -s 10.8.0.5 ले प्रवाह र त्यसको अवस्था देखाउँछ।

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