साइट-टू-साइट 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 काहीही बदलत नाही, कारण विनंती कधीच बोगद्यात गेली नाही।
हे दुरुस्त झाले असे म्हणण्यापूर्वी चार गोष्टी क्रमाने खात्री करा: उत्तर पाठवणाऱ्या होस्टवरील राउट, ते पुढे पाठवणाऱ्या प्रत्येक हॉपवरील राउट, दोन्ही प्रीफिक्स झाकणारे सिलेक्टर, आणि उत्तर तुम्ही अपेक्षित स्रोतासह बोगद्यात शिरते हे दाखवणारे कॅप्चर। मग दुसऱ्या साइटवरून चाचणी पुन्हा करा। एक दिशा पार होणे म्हणजे अर्धवट उघडे रचना, आणि दुसरी दिशा सहसा तुम्ही नुकतेच दुरुस्त केलेल्यापेक्षा वेगळ्या कारणाने अपयशी ठरते।