साइट-देखि-साइट VPN को जवाफ सुरुङबाट जाँदैन
सुरुङ छोड्ने जवाफ दूरको छेउको राउटिङ निर्णय हो। होस्ट तालिका, सिलेक्टर र rp_filter जाँच्नुहोस्, त्यसपछि राउट वा NAT छान्नुहोस्।
एक बिहान मैले त्यस्तो सुरुङमा बिताएँ जो सफा रूपमा उठ्यो र ट्राफिक ठ्याक्कै एउटै दिशामा सार्यो: शाखा प्रधान कार्यालयको फाइल सर्भरसम्म पुग्थी, र प्रधान कार्यालयबाट शाखामा खोलिने हरेक जडान पहिलो SYN मै मर्थ्यो। SA हरू सक्रिय थिए, सुरुङका काउन्टर बढ्दै थिए, र ह्यान्डशेक कहिल्यै समस्या थिएन। जवाफ सुरुङले नढाक्ने ठाउँमा राउट भइरहेको थियो, र त्यो छनोट दूरको छेउको हो। साइट-देखि-साइट VPN ले होस्टले गेटवेलाई सुम्पने प्याकेट मात्र बोक्छ, र हरेक होस्टले त्यो छनोट अलग-अलग, हरेक दिशामा, आफ्नै राउटिङ तालिकाबाट गर्छ।
दुवै दिशा अलग-अलग राउट हुन्छन्
IP ले कुराकानीको दिशाको कुनै सम्झना राख्दैन। प्याकेट पठाउने हरेक होस्टले आफ्नै सबैभन्दा लामो प्रिफिक्स खोज चलाउँछ, एउटा अर्को हप छान्छ र निर्णय बिर्सन्छ। अनुरोध र जवाफ एउटै जडानमा संयोगवश पर्ने दुई असम्बन्धित प्याकेट हुन्, र सुरुङ एउटा हप हो जुन तीमध्ये कुनैले प्रयोग गर्न सक्छ वा सक्दैन। IKE आदानप्रदानमा केहीले पनि दूरको सर्भरलाई तपाईंको सबनेटसम्म कसरी पुग्ने सिकाउँदैन; वार्ता कुन प्रिफिक्स इन्क्रिप्ट गर्न सकिन्छ भन्नेमा मात्र सहमत हुन्छ।
त्यो सहमति दोस्रो ढोका हो। strongSwan मा ट्राफिक सिलेक्टर leftsubnet र rightsubnet हुन्, र जुन प्याकेटको स्रोत वा गन्तव्य तय भएको जोडीबाहिर पर्छ त्यो इन्क्रिप्ट हुँदैन, राउटिङ तालिकाले जे भने पनि। सुरुङमा राउट हुने तर सिलेक्टरमा नभएको प्रिफिक्स शान्त एकतर्फी विफलता हो: राउट ठीक देखिन्छ, प्याकेट तैपनि खुला रूपमा बाहिर जान्छ वा फालिन्छ, र charon लग मात्र गुनासो गर्छ।
दूरको होस्टलाई तपाईंको सुरुङबारे केही थाहा छैन
दूरको LAN भित्र जवाफ तपाईंको क्लाइन्टलाई पठाइएको साधारण प्याकेट हो। गन्तव्य होस्टले कुनै IPsec हेडर देख्दैन र VPN गेटवेलाई प्राथमिकता दिने कारण छैन; त्यो तपाईंको प्रिफिक्स खोज्छ, आफ्नो पूर्वनिर्धारित राउटभन्दा विशिष्ट केही भेट्दैन र त्यही पछ्याउँछ। पूर्वनिर्धारितले कुनै मुख्य फायरवालतर्फ देखाउँछ भने, फायरवालसँग सुरुङभित्र फर्कने राउट छ वा छैन। नभए तपाईंले शान्त थिग्राइ, ICMP unreachable, वा इन्टरनेटतर्फ फर्केको इन्टरफेसबाट बाहिर गएर मर्ने जवाफ पाउनुहुन्छ।
राउट भए पनि दोस्रो इन्टरफेसले यो तोड्न पर्याप्त हुन्छ। अर्को VLAN मा व्यवस्थापन लिंक भएको NAS, ब्याकअप uplink भएको सर्भर, एउटा स्रोत-दायरा दोस्रो तालिकामा पठाउने नीति नियम: यीमध्ये कुनैले पनि जवाफ समात्न सक्छ। Linux मा, ip rule show र ip route show table all ले पूर्वनिर्धारित सूचीले लुकाउने नियम र तालिका देखाउँछन्।
जवाफ पठाउने मेसिनमै निर्णय पढ्नुहोस्
केही बदल्नुअघि कर्नेललाई सोध्नुहोस्, र त्यसलाई स्रोत ठेगाना दिनुहोस्, किनकि स्रोतमा निर्भर नियमले जवाफ बदल्छन्।
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"आउटपुटले बाहिर जाने इन्टरफेस र अर्को हप बताउँछ। इन्टरफेस VPN गेटवेतर्फ फर्केको नभए, तपाईंले दोष भेट्नुभयो, र बाँकी काम राउट कहाँ हुनुपर्ने छान्नु हो। गेटवेबाट गरिएको ping यहाँ थोरै प्रमाणित गर्छ: यसले दूरको होस्टले राख्न सक्ने ठेगानाले जवाफ दिन्छ, तपाईंको ल्यापटपको ठेगानाले होइन।
Windows मा समान Find-NetRoute -RemoteIPAddress 10.10.5.10 निर्णयका लागि र Get-NetRoute तालिकाका लागि हुन्। पूर्वनिर्धारितभन्दा बढी मेट्रिक बोक्ने New-NetRoute ले थपिएको राउट शान्त रूपमा हार्छ, त्यसैले मेट्रिक स्तम्भ पढ्नुहोस्, प्रविष्टि होइन। त्यसपछि प्याकेटले पुष्टि गर्नुहोस्: दूरको LAN इन्टरफेसमा tcpdump -ni any "host 10.10.5.10 and tcp port 445" ले अनुरोध देखाउँछ, र सुरुङतर्फ त्यही फिल्टरले जवाफ फर्कियो कि भनेर देखाउँछ। अनुरोध देखिन्छ तर जवाफ छैन भने जवाफ अन्तै राउट भयो वा फालियो; गलत इन्टरफेसमा आएको जवाफले राउट छुनुअघि नै दोषी दिन्छ।
जब सर्भरको गेटवे VPN को अन्त्य बिन्दु हुँदैन
धेरै साइटले सर्भर र केन्द्रीकरण उपकरणबीच फायरवाल राख्छन्। त्यो फायरवालले जवाफ अगाडि पठाउँछ, त्यसैले यसलाई तपाईंको क्लाइन्ट प्रिफिक्सका लागि VPN गेटवेतर्फ देखाउने राउट र दुवै दिशामा अगाडि पठाउने नीति चाहिन्छ। अवस्था राख्ने उपकरणले अझ बिगार्छ: अनुरोध त्यसले अनुमति दिएको LAN होस्टबाट फायरवाल पार गर्यो, जवाफ अब अर्को दिशाबाट आउँछ, र जडान-ट्र्याकिङ प्रविष्टि अब मिल्दैन, त्यसैले प्याकेट अस्वीकार हुनुको सट्टा अवैध भनी फालिन्छ। ट्राफिक हराइरहेको बेला नीति लग खाली देखिनुको कारण यही हो।
गेटवेको आफ्नै दोस्रो फिल्टर छ। Linux को उल्टो-मार्ग फिल्टरिङले ती प्याकेट फाल्छ जसको स्रोत ती आएको इन्टरफेसबाट पुग्न सकिँदैन, र यो वैध असममित फर्कने मार्गको ठ्याक्कै आकार हो। strongSwan को अगाडि पठाउने मार्गदर्शिका ले ठ्याक्कै त्यही कारणले net.ipv4.ip_forward र खुकुलो net.ipv4.conf.all.rp_filter माग्छ। कुनै पनि गेटवेमा कडा मान 1 ले सही राउट शान्त रूपमा तोड्छ, र कहाँ हेर्ने थाहा भए nstat -az ले थिग्राइ देखाउँछ।
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
राउट गर्नुहोस् वा अनुवाद गर्नुहोस्, त्यसपछि दुवै दिशामा जाँच्नुहोस्
दुई मर्मत समान छैनन्। राउट थप्दा क्लाइन्टको ठेगाना अक्षुण्ण रहन्छ, त्यसैले स्रोतमा आधारित नियम, अडिट लग र कल गर्नेलाई रेकर्ड गर्ने एपहरू काम गरिरहन्छन्; मूल्य यो हो कि निर्णय गर्ने हरेक हपलाई राउट चाहिन्छ, अर्थात् गल्ती गर्ने थप ठाउँ। दूरको गेटवेमा मास्करेड फर्कने मार्गलाई एउटा हपमा खुम्च्याउँछ, किनकि जवाफ अब गेटवे आफैंलाई पठाइन्छ, र कुन क्लाइन्टले के गर्यो लुकाउँछ।
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEयसलाई जानाजान छान्नुहोस्: क्लाइन्टहरू गेटवेको ठेगानाको रूपमा देखिन थालेपछि, स्रोतमा आधारित ACL ले तिनीहरूलाई छुट्याउन छोड्छन्, र जवाफ सुरुङमा फर्केर लेखिनका लागि conntrack ले म्यापिङ राख्नुपर्छ। सिलेक्टरले अझै क्लाइन्ट प्रिफिक्स बाहिर राख्छ भने, NAT ले केही बदल्दैन, किनकि अनुरोध कहिल्यै सुरुङमा छिरेन।
यसलाई सच्याइयो भन्नुअघि चार कुरा क्रमैसँग पुष्टि गर्नुहोस्: जवाफ पठाउने होस्टको राउट, त्यसलाई अगाडि पठाउने हरेक हपको राउट, दुवै प्रिफिक्स ढाक्ने सिलेक्टर, र जवाफ तपाईंले अपेक्षा गरेको स्रोतसहित सुरुङमा छिरेको देखाउने क्याप्चर। त्यसपछि अर्को साइटबाट परीक्षण दोहोर्याउनुहोस्। एउटा दिशा पास हुनु आधा खुला डिजाइन हो, र दोस्रो दिशा सामान्यतया तपाईंले भर्खरै सच्याएको भन्दा फरक कारणले असफल हुन्छ।