दोन VPN पूलांसाठी स्रोत राउटिंग: तुमचा नियम काय चुकवतो
from स्वरूपाचा नियम SNAT पुन्हा लिहिण्यापूर्वी क्लायंट पत्त्याशी जुळतो, आणि गेटवेवरून केलेली चाचणी दोन्हींपैकी कशाशीही जुळत नाही. प्रत्येक पूलसाठी लुकअप चालवा आणि त्याऐवजी प्राधान्ये वाचा.
दोन क्लायंट पूल, एक गेटवे आणि योजना सोपी वाटते: एक नियम पहिल्या पूलला वेगवान अपलिंकवरून बाहेर पाठवतो, दुसरा दुसऱ्या पूलला भागीदार बोगद्यातून पाठवतो। मग नियम जागच्या जागी असतात आणि दुसरा पूल तरीही डीफॉल्ट मार्गानेच बाहेर पडतो। नियम तुटलेला नाही। लुकअपच्या क्षणी लेखकाने जे अपेक्षित धरले होते ते पॅकेटचे स्रोत नसते, कारण भाषांतर आणि लुकअप एकाच पॅकेटच्या प्रवासाच्या वेगवेगळ्या टप्प्यांवर घडतात, आणि क्रम बहुतेक लोक काढतात त्या मानसिक आकृतीच्या उलट असतो।
स्रोत पुन्हा लिहिला जाण्यापूर्वी लुकअप घडतो
VPN क्लायंटकडून पुढे पाठवल्या जाणाऱ्या पॅकेटसाठी कर्नेल एक ठरलेला क्रम चालवते। ते बोगदा इंटरफेसवर येते, conntrack आणि DNAT असलेल्या prerouting मधून जाते, नंतर मार्गनिर्णय घेतला जातो, नंतर पुढे पाठवणे, नंतर SNAT शेवटी लागू होणारे postrouting। from स्वरूपाचा नियम त्या मार्गनिर्णयादरम्यान पाहिला जातो, म्हणजे तो क्लायंटचा मूळ पत्ता पाहतो, भाषांतरित पत्ता नाही।
त्यामुळे masquerade नियम जोडल्याने बाहेर जाणाऱ्या प्रवाहावर कोणती धोरणे लागू होतात ते बदलत नाही। बदलते ते म्हणजे दूरचे टोक काय पाहते, आणि त्यामुळे कोणता परतीचा मार्ग अस्तित्वात आहे। हे दोन वेगवेगळे परिणाम आहेत, आणि बदल पुनरावलोकने त्यांना सतत मिसळतात। ते वेगळे केले तर रचना सहसा एका मिनिटात स्पष्ट होते।
उत्तरेच्या दिशेनेच भाषांतरित पत्ता नियमांमध्ये दिसतो। गेटवेवर परत येणारे पॅकेट भाषांतरित पत्त्याला उद्देशून असते, आणि गंतव्य किंवा ज्या इंटरफेसवरून ते आले त्यावर आधारित धोरण नियम असतील, तर तेच मूल्य तुम्ही जुळवाल। एकच जोडणी, प्रत्येक दिशेने सत्याचा वेगळा स्रोत।
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
त्यामुळे वेगळ्या स्रोतांच्या दोन पूलांना खरोखर वेगळी तक्ते लागतात, आणि रचना योग्य आहे। वरील तक्ता जे नाकारते ते म्हणजे दूरच्या साइटला काय मिळाले हे पाहून नियम ओळखण्याचा सोपा मार्ग।
गेटवेवरून केलेली चाचणी पूलची चाचणी नाही
गेटवे स्वतः निर्माण करणारा रहदारी कधीही prerouting मधून जात नाही, कारण तो कोणत्याही इंटरफेसवर आलेला नाही। तो आउटपुट मार्गात राउट होतो, स्रोत म्हणून गेटवेचा स्वतःचा पत्ता, आणि क्लायंट श्रेणीवर आधारित from नियम जुळणार नाही। या क्षेत्रातील प्रत्येक तिकीट जे म्हणते बॉक्सवरून चालते पण क्लायंटवरून नाही, ते त्याच तथ्याचे पुनरुच्चारण आहे।
क्लायंटचा अंदाज करण्याऐवजी त्याचे अनुकरण करा। राउटिंग लुकअपला थेट विचारता येते, स्रोत आणि इनग्रेस इंटरफेस दिल्यास:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201ते प्रत्येक पूलसाठी एकदा चालवा। दोन्ही आदेश एकच इंटरफेस परत देत असतील, तर नियम पूल वेगळे करत नाहीत, आणि कारण एकतर गहाळ नियम किंवा दोन्हींना जुळणारा जास्त प्राधान्याचा नियम। जर ते वेगळे इंटरफेस परत देतात पण क्लायंट अजूनही अपयशी ठरतो, तर दोष लुकअपनंतरचा आहे आणि तुम्ही नियम पाहणे थांबवू शकता।
प्राधान्य, फाइलमधील स्थान नाही
नियम प्राधान्याच्या चढत्या क्रमाने मूल्यांकन केले जातात, आणि संख्याच महत्त्वाची, तुम्ही टाइप केलेला क्रम नाही। local तक्ता प्राधान्य 0 वर, main तक्ता 32766 वर आणि डीफॉल्ट नियम 32767 वर आहे, म्हणून डीफॉल्ट प्राधान्याने जोडलेला नियम यादीच्या शेवटाजवळ पडतो आणि जवळपास सर्वांकडून हरतो।
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201स्पष्ट प्राधान्य इच्छित क्रम फाइलमध्ये आणि पुनरावलोकनात दृश्यमान करते। ते नंतरच्या जोडणीला विद्यमान नियमाच्या पुढे शांतपणे उडी मारण्यापासूनही रोखते, जे असंबंधित बदलानंतर चालणारे धोरण थांबण्याचे सर्वात सामान्य कारण आहे।
अपूर्ण तक्त्याकडे निर्देश करणारा जुळणारा नियम हा दुसरा सापळा आहे। तक्ता 201 मध्ये डीफॉल्ट मार्ग असेल पण गंतव्याचा मार्ग नसेल, तर पॅकेट टाकून दिले जाते किंवा चुकीच्या ठिकाणी पाठवले जाते, आणि नियम वेगळा पाहिल्यास पूर्णपणे बरोबर वाटतो। नियम नाही, तक्ता वाचा। नियम म्हणजे निर्देशक, आणि रिकामा तक्ता म्हणजे काहीच नसलेला निर्देशक।
परतीचा मार्ग तरीही असायलाच हवा
स्रोत धोरण निर्गम निवडते। ते परतीचा मार्ग तयार करत नाही। दुसरा पूल भागीदार बोगद्यातून बाहेर पडत असेल, तर भागीदाराला 172.31.8.0/24 पर्यंत कसे पोहोचायचे हे माहीत असले पाहिजे, एकतर गेटवेकडे परतीच्या मार्गाने किंवा आधीच माहीत असलेले भाषांतरित पत्ते स्वीकारून।
त्यांत निवड करणे हा दृश्य परिणाम असलेला रचना निर्णय आहे। क्लायंट श्रेणी परत राउट केल्यास भागीदाराकडे प्रत्येक क्लायंटची ओळख टिकते आणि त्याला तुमचा प्रिफिक्स स्वीकारावा लागतो। भाषांतर पूल एका पत्त्यामागे लपवते आणि भागीदाराने फक्त तोच पत्ता स्वीकारावा लागतो, या किंमतीवर की तुमचे आणि त्यांचे लॉग कोण जोडला गेला यावर आता सहमत होणार नाहीत।
तुम्ही काहीही निवडा, ते पूलच्या व्याख्येजवळ लिहा। फक्त कोणाच्या स्मरणात असलेला परतीचा मार्ग हा नेमका तोच प्रकार आहे जो भागीदार फायरवॉल बदलत नाही तोपर्यंत टिकतो, आणि नंतर पुन्हा बांधायला एक दिवस लागतो।
धोरणात गेटवेचा स्वतःचा बोगदा पकडू नका
क्लायंटसाठी लिहिलेले नियम गेटवे निर्माण करणाऱ्या रहदारीवरही लागू होतात, तुम्ही ती वगळल्याशिवाय। मार्क किंवा आउटपुट इंटरफेसवर आधारित विस्तृत नियम गेटवेचे भागीदाराशी असलेले स्वतःचे जोडणी पकडू शकतो, आणि मग धोरण वाहणारा बोगदाच धोरणाने राउट होतो। यामुळे लूप किंवा खंड पडतो जो पुरवठादाराच्या बिघाडासारखा दिसतो।
प्रत्येक नियम रचना परवानगी देईल तितका अरुंद ठेवा: स्रोत प्रिफिक्स, इनग्रेस इंटरफेस आणि जिथे आधार असेल तिथे फक्त क्लायंट पॅकेट वाहून नेणारा मार्क। नंतर प्रत्येक नियम बदलानंतर गेटवेची स्वतःची जोडणी तपासा, कारण बिघाड स्व-संदर्भी आहे आणि क्लायंट चाचणीत दिसत नाही।
ip-rule मॅन्युअल पृष्ठ निवडक आणि प्राधान्याचा अर्थ दस्तऐवजीकरण करते। ते प्रत्येक पूलच्या लुकअप चाचणीसोबत जोडा आणि रचना तपासण्यायोग्य होते, जो एक वर्ष टिकणारे धोरण राउटिंग आणि सर्वांना स्पर्श करायला भीती वाटणारे यांतील फरक आहे।