तपाईंको LAN किन VPN क्लाइन्टको सेवासम्म पुग्न सक्दैन

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

बिग्रेको टनेल होइन

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

पोर्ट 80 वा 443 मा रहेको प्रोक्सी फरक देखिने फरक उपकरण हो। यसले अनुरोध सार्छ, प्याकेट होइन, त्यसैले कच्चा डाटाबेस जडानका लागि यो गलत तह हो, र यसतर्फ हात बढाउनु नै कसैले केही नाप्नुअघि यो समस्या तीन उपकरण गहिरो पुग्ने बाटो हो।

रुटको आकार: LAN लाई पोखरी कहाँ छ भनेर बताउनुहोस्

LAN गेटवेमा स्थिर रुट सबैभन्दा सफा जवाफ हो जब LAN र टनेल पोखरी एकअर्कामा पर्दैनन्। पोखरीलाई टनेल अन्त्य गर्ने मेसिनतिर फर्काउनुहोस्:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

सर्भरको पछाडि होइन, एउटा क्लाइन्टको पछाडि रहेको सबनेटका लागि सर्भरलाई प्रणाली रुट र त्यो क्लाइन्टको फाइलमा iroute प्रविष्टि (client-config-dir अन्तर्गत) दुवै चाहिन्छ। iroute बिना, OpenVPN लाई प्रिफिक्स अवस्थित छ भन्ने थाहा छ र कुन क्लाइन्टले यसको स्वामित्व लिएको छ भन्ने थाहा छैन: प्याकेट आउँछन् र डेमनसँग तिनीहरूलाई मिलाउन केही हुँदैन।

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

NAT को आकार: भित्र DNAT, र सबैले छोड्ने SNAT लाइन

जब तपाईं LAN गेटवे छुन सक्नुहुन्न, वा ठ्याक्कै एउटा पोर्ट प्रकाशित गर्न चाहनुहुन्छ, VPN होस्टमा अनुवाद LAN मा कुनै रुट बिना काम गर्छ। पोर्ट प्रकाशित गर्नुहोस्, फर्वार्ड गर्नुहोस्, र टनेलतिर जाने बाटोमा स्रोतको अनुवाद गर्नुहोस्:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

उपभोक्ता फर्मवेयरले आफ्नै चेन नाम प्रयोग गर्छ र तपाईंका लागि त्यो अनुवाद उत्पन्न गर्दैन। Tomato मा, इनबाउन्ड नियम WANPREROUTING मा पर्छ र त्यसपछि wanin जस्तो फिल्टर चेनमा, र पूर्ण देखिने नियम सेटलाई अझै हातले लेखिएको POSTROUTING लाइन चाहिन्छ। त्यो फर्मवेयर बग होइन; त्यो केवल इनबाउन्ड ट्राफिकका लागि लेखिएको नियम सेट हो।

सही देखिने नियमले पनि प्याकेट किन खसाल्छ

यी असफलताहरूमध्ये धेरैजसो तपाईं हेरिरहनुभएको नियममा हुँदैन। यो क्रममा चार कुरा जाँच्नुहोस्, र नमिल्ने पहिलोमा रोकिनुहोस्:

• चेनको क्रम। iptables -I माथि राख्छ र -A अन्त्यमा थप्छ, त्यसैले अघिल्लो अनुमति दिने वा रोक्ने नियमले पहिले निर्णय गर्छ।
• गलत चेन। राउटर आफैंतिर लक्षित ट्राफिक INPUT पार गर्छ, र फर्वार्ड गरिएको ट्राफिकले त्यसलाई कहिल्यै छुँदैन। एउटा सेवा प्रकाशित गर्न दुवैमा नियम चाहिन सक्छ।
• दिशा फ्ल्याग। -i tun0 क्लाइन्टबाट आउने ट्राफिकसँग मिल्छ र -o tun0 तिनीहरूतिर जाने ट्राफिकसँग। गलत फ्ल्यागसहितको REJECT ले तपाईंले नचाहेको कुरा रोक्छ।
• स्रोत सीमा। एउटा क्लाइन्ट ठेगाना स्वीकार गर्ने फर्वार्डिङ त्यो क्लाइन्टबाट काम गर्छ र हरेक अन्य स्रोतलाई एक शब्द पनि नभनी खसाल्छ।

शून्य प्याकेट काउन्टर भएको नियम बाटोमा नै हुँदैन, र काउन्टर पढ्नु गलत-चेनको समस्यालाई गलत-नियमको समस्याबाट अलग्याउने सबैभन्दा छिटो उपाय हो।

LAN मा केही पनि बदल्न नसकिने बेला स्थानीय फर्वार्डिङ

SSH स्थानीय फर्वार्डिङले पूरै प्रश्न छल्छ। यसलाई LAN मा रुट, क्लाइन्टको फायरवालको सहयोग, र कतै प्रकाशित पोर्ट चाहिँदैन:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

अर्को नियम थप्नुअघि दुवै दिशा जाँच्नुहोस्

अनुवादले चिन्ह छोड्छ, र ती पढ्नु अनुमान गर्नुभन्दा राम्रो हो। VPN होस्टमा, conntrack -L ले अनुवाद भयो कि भएन देखाउँछ, iptables -t nat -L -n -v ले काउन्टर सरे कि सरेन देखाउँछ, र tcpdump -ni any port 3000 ले कुन स्रोत ठेगाना साँच्चै आयो देखाउँछ। क्लाइन्टमा, ss -ltn ले सुन्ने टनेलले पुग्न सक्ने ठेगानामा छ भनी पुष्टि गर्छ।

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