रिमोट प्रयोगकर्ताहरू VPN हब हुँदै दोस्रो साइटमा पुग्न सक्दैनन्

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

जान तीन लुकअप चाहिन्छ, एउटा टनेल होइन

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

त्यसैले प्रत्येक टनेल अलग जाँच्नु धेरै थोरै प्रमाणित गर्छ। हबको LAN ठेगानामा पिङ गर्नु पहिलो निर्णय जाँच्छ, र मुख्यालयबाट हबमा पिङ गर्नु तेस्रो जाँच्छ। असफल हुने प्याकेटको स्रोत प्रयोगकर्ता पूल र गन्तव्य दोस्रो साइट हुन्छ, त्यसैले पहिले ती प्रिफिक्स लेख्नुहोस्। यहाँ पूल 10.80.0.0/24 हो, हबको LAN 10.10.0.0/24 हो र मुख्यालय 10.20.0.0/24 हो।

टाढाको प्रिफिक्स रिमोट क्लाइन्टमा धकेल्नुहोस्

एउटा OpenVPN रिमोट-एक्सेस सर्भरमा क्लाइन्टले जोडिने बेलामा रुटहरू सिक्छ। push नभए, स्प्लिट-टनेल क्लाइन्टले 10.20.0.50 आफ्नै गेटवेमा पठाउँछ र प्याकेट कहिल्यै टनेलमा पस्दैन।

push "route 10.20.0.0 255.255.255.0"

धकेलिएको रुट क्लाइन्ट जोडिँदा लागू हुन्छ, त्यसैले अनलाइन रहने प्रयोगकर्ताले फेरि जोडिनुअघि केही देख्दैन। क्लाइन्टमा जाँच्नुहोस्: Linux मा ip route get 10.20.0.50, Windows मा route print। आउटपुटले टनेल इन्टरफेसको नाम बताउनुपर्छ।

push ले हबलाई सहयोग गर्दैन। यो क्लाइन्टलाई दिइएको सन्देश हो, सर्भरमा रुट होइन र अगाडि पठाउने अनुमति पनि होइन, त्यसैले उत्तम push लाइन भएको हबले पनि एक हपपछि प्रवाह छोड्छ। मानिसहरूले push असफल भयो भनेर निष्कर्ष निकाल्ने सामान्य कारण यही हो।

हबलाई वास्तविक इग्रेस रुट दिनुहोस्

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

जहाँ साइट-टू-साइट खुट्टा आफै OpenVPN हो, त्यहाँ रुट त्यही कन्फिगरेसनमा पियरको टनेल ठेगानालाई गेटवे बनाएर रहन सक्छ: route 10.20.0.0 255.255.255.0 172.30.0.2। गेटवे ऐच्छिक होइन। त्यो छोड्यो भने अर्को हप कार्यान्वयनको डिफल्टमा पर्छ, जो एकल-रिमोट क्लाइन्ट र बहु-पियर हबबीच फरक हुन्छ।

नीति-आधारित IPsec फरक छ: हबको कर्नेलले प्याकेट आफ्नो सामान्य LAN गेटवेमा पठाउँछ र नीतिले बाहिर जाँदा त्यो समात्छ, त्यसैले टनेल रुटले या केही गर्दैन या नीति छल्ने गरी ट्राफिक लैजान्छ। माथिको कमाण्डमा स्रोत हेर्नुहोस्, किनकि पूलको ठेगानाको सट्टा 10.10.0.1 भन्नुको अर्थ कर्नेलले टाढाको पट्टिले अस्वीकार गर्ने ठेगाना छान्यो। iroute पनि उत्तर होइन; यसले सर्भरलाई कुन क्लाइन्टले आफ्नै टनेलपछाडिको सबनेटको मालिक छ भन्छ, तेस्रो साइटका लागि ट्राफिक कहाँ पठाउने भन्ने होइन।

टाढाको पट्टि प्रयोगकर्ता पूलसम्म विस्तार गर्नुहोस्

मुख्यालयले पहिले नै हबको LAN, 10.10.0.0/24 समेट्छ। प्रयोगकर्ता पूल दोस्रो प्रिफिक्स हो र त्यो सिलेक्टरहरूमा पनि हुनुपर्छ, नत्र 10.80.0.25 मा पठाइएको जवाफ कुनै नीतिले समेट्दैन। प्रत्येक पियरले आफ्नो पट्टिबाट प्रिफिक्स सेटहरूको त्यही जोडी नाम दिन्छ:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

एउटा उपकरणको local_ts अर्कोको remote_ts हो। हबको ब्लक मुख्यालयमा प्रतिलिपि गर्नुहोस् र जोडी उल्टिन्छ, त्यसैले चाइल्ड SA कहिल्यै माथि आउँदैन।

पुरानो ipsec.conf सिन्ट्याक्सले अल्पविरामले छुट्याइएको leftsubnet प्रयोग गर्छ। चालु सुरक्षा संस्थाले वार्ता गरेका सिलेक्टरहरू राख्छ, त्यसैले सम्पादनपछि टनेल पुनः स्थापना गर्नुहोस्। 10:00 मा बदलिएको सिलेक्टर 09:40 मा माथि आएको SA विरुद्ध परीक्षण गर्दा पनि असफल हुन्छ, जबकि कन्फिग फाइल सधैं सही देखिन्छ।

त्यसपछि अन्तिम हप जाँच्नुहोस्। टाढाको इन्डपोइन्टमा ip route get 10.80.0.25 टनेलतिर देखाउनुपर्छ। सेवाले LAN राउटरलाई आफ्नो डिफल्ट गेटवे बनाएको छ भने त्यो राउटरलाई पनि रिटर्न रुट चाहिन्छ, नत्र जवाफ त्यहीँ मर्छ। त्यो खण्डमा tcpdump -ni eth1 host 10.80.0.25 चलाउनुले जवाफ इन्डपोइन्टबाट बाहिर निस्क्यो कि भन्ने देखाउँछ।

हबमा प्रवाहलाई अनुमति दिनुहोस्

फर्वार्डिङ सक्षम र बाटो अनुमत हुनुपर्छ। इन्टरफेसहरूबीच सबै स्वीकार्नुको सट्टा नियमहरू दुई प्रिफिक्समा सीमित गर्नुहोस्।

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

रिभर्स-पाथ फिल्टरिङ त्यसको छेउको शान्त असफलता हो: दुई खुट्टा फरक इन्टरफेसमा भए rp_filter=1 ले जवाफ फ्याँक्न सक्छ, जबकि स्वीकृति नियमको काउन्टर कहिल्यै हल्लिँदैन। प्रयासअघि र पछि iptables -vnL FORWARD तुलना गर्नुहोस्। कहिल्यै नबढ्ने नियममा पुगिँदैन, त्यसैले त्यो पुनः लेख्नुको सट्टा एक तह तल हेर्नुहोस्।

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

क्लाइन्टबाट जाँच्नुहोस्, त्यसपछि उल्टो क्रममा रोलब्याक गर्नुहोस्

ICMP मात्र होइन, TCP पोर्ट परीक्षण गर्नुहोस्, किनकि सेवा अवरुद्ध रहँदा पिङ जान सक्छ। क्लाइन्टबाट nc -vz 10.20.0.50 445 र traceroute -n 10.20.0.50 ले दोस्रो हप हबको टनेल ठेगाना हो कि होइन देखाउँछन्। हबमा, tcpdump -ni tun0 host 10.20.0.50 र साइट-टू-साइट इन्टरफेसमा त्यही फिल्टर: दुवैमा अनुरोध तर कुनैमा जवाफ छैन भने समस्या टाढाको पट्टितिर सर्छ।

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

रोलब्याक सूची राख्नुहोस्, किनकि चार वस्तु बदलिए र तीन बिर्सन सजिलो छ: धकेलिएको रुट, हबको रुट, सिलेक्टरहरू र फायरवाल नियमहरू। तिनीहरूलाई उल्टो क्रममा फिर्ता लिनुहोस्, SA पुनः स्थापना गर्नुहोस्, र एक प्रयोगकर्तालाई फेरि जोडिन दिनुहोस्। आंशिक रोलब्याकले अब नमिल्ने टनेलतिर देखाउने रुट छोड्छ, र त्यो मूल मौनताभन्दा पढ्न गाह्रो हुन्छ। OpenVPN 2.6 म्यानुअल तपाईंको संस्करणका लागि push, route र iroute अभिलेख गर्छ।