क्यों स्रोत-पोर्ट नियम आपके एक SSH पथ को तोड़ देता है
«sport 22» का मेल यह नहीं बताता कि उत्तर किस SSH प्रवेश से जुड़ा है। नीति नियम को केवल WAN वाली एक तालिका के बजाय प्रबंधन प्रवाह तक सीमित रखें।
एक ही होस्ट पर दो प्रबंधन प्रवेश, एक सेवा पोर्ट, और एक नीति नियम जो दोनों की मदद करने के लिए था। नियम स्रोत पोर्ट 22 से मेल खाता है, खोज को उस तालिका में भेजता है जो केवल WAN डिफ़ॉल्ट जानती है, और VPN प्रवेश नए लॉगिन का उत्तर देना बंद कर देता है जबकि सीधा प्रवेश काम करता रहता है। चयनकर्ता को ठीक से पढ़ने पर इसमें कुछ भी रहस्यमय नहीं है। स्रोत पोर्ट किसी सेवा की पहचान करता है, उस पथ की नहीं जिससे कोई कनेक्शन आया।
दो प्रवेश, एक सेवा पोर्ट
होस्ट के पास LAN की ओर का पता और एक VPN पता है, और sshd दोनों पर सुनता है। इसलिए सीधा सत्र और सुरंग सत्र सेवा पोर्ट साझा करते हैं और केवल इसमें भिन्न होते हैं कि कौन-सा स्थानीय पता कनेक्शन स्वीकार करता है।
यह अंतर उत्तर का पथ चुनने के लिए पर्याप्त है, और यह ठीक वही अंतर है जिसे पोर्ट-आधारित नियम छोड़ देता है। दोनों सत्र ऐसे उत्तर बनाते हैं जिनका स्रोत पोर्ट 22 है, इसलिए उस पोर्ट से मेल खाने वाला नियम उन्हें अलग नहीं कर सकता। यह दोनों खोज एक ही तालिका में भेजता है, और उनमें से एक को ऐसा उत्तर मिलता है जो फिट नहीं बैठता। उपाय यह है कि उस विशेषता से मेल बिठाया जाए जो वास्तव में अलग है।
हर प्रवेश को उसका अपना पोर्ट देना भी काम करेगा, और इसे आवश्यकता मानना SSH का गुण नहीं बल्कि डिज़ाइन का चुनाव है।
नियम पढ़ें, फिर तालिका
नीति नियम एक क्रमबद्ध चयनकर्ता है, और उपयोगी उत्तर लौटाने वाला पहला नियम खोज समाप्त कर देता है। सूची को क्रम में पढ़ें और ध्यान दें कि कौन-सा नियम जीत सकता है।
फिर उस तालिका को पढ़ें जिसकी ओर वह नियम इशारा करता है, क्योंकि सफलतापूर्वक हल होने वाला नियम उपयोगी रूप से हल होने वाला नियम नहीं है। केवल डिफ़ॉल्ट मार्ग वाली तालिका VPN-स्रोत उत्तर को WAN इंटरफ़ेस से बाहर भेजती है। बाद की तालिका में अधिक विशिष्ट मार्ग कभी नहीं देखा जाता, और इसीलिए दूसरी तालिका जोड़ना इतनी बार कुछ नहीं बदलता। चुनी गई तालिका ही जाँचने वाली चीज़ है।
ip -4 rule show
ip route show table 100
ip route show table mainये दोनों आउटपुट मिलकर परिणाम समझाते हैं; इनमें से कोई अकेला गलत निष्कर्ष की ओर बुलाता है।
नियम को उसी प्रवाह तक सीमित करें जिसका आपका अर्थ है
दोनों प्रवेशों को अलग करने वाली विशेषता स्थानीय स्रोत पता है। उस पते से मेल खाने वाला नियम केवल सुरंग सत्रों को निजी तालिका में भेजता है और सीधे सत्रों को मुख्य तालिका पर रहने देता है।
वह नियम ऐसी तालिका के साथ जोड़ा जाना चाहिए जिसमें निजी मार्ग और उस सबनेट का वापसी मार्ग हो। दोनों को होस्ट की हर सेवा के बजाय प्रबंधन ट्रैफ़िक तक सीमित करें। उस पते से आने वाला सारा ट्रैफ़िक पकड़ने वाला नियम होस्ट द्वारा वहाँ से भेजी गई बाकी हर चीज़ को भी पुनर्निर्देशित करेगा। यहाँ संकीर्ण चतुर से जीतता है, क्योंकि अगले व्यक्ति को इसे पढ़ना है।
sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1अगर दोनों प्रवेश एक ही स्थानीय पते पर अनूदित किए जाएँ, तो वह भेद मिट जाता है और डिज़ाइन को इसके बजाय कनेक्शन-सचेत स्थिति चाहिए।
श्रोता, अनुमति और उत्तर-चयन को अलग रखें
सत्र के काम करने से पहले तीन अलग चीज़ें सत्य होनी चाहिए: पता मौजूद है, सेवा उस पर सुनती है, और उत्तर वापसी का रास्ता पा लेता है। मार्ग परिवर्तन केवल तीसरी को ठीक करता है।
श्रोता कॉन्फ़िगरेशन अपनी अलग फ़ाइल और अपना अलग पुनःलोड रखता है, और कई सुनने के पते सामान्य हैं। प्रमाणीकरण फिर से तीसरा निर्णय है, और रूटिंग अपवाद किसी को पहुँच नहीं देता। दोनों प्रवेशों पर होस्ट-की सत्यापन, खाता प्रमाणीकरण और स्रोत प्रतिबंध रखें, और एक प्रबंधन पथ के काम करने के लिए सुरंग के बाकी नियंत्रणों को कमज़ोर करने की इच्छा का विरोध करें।
ऐसा रिकवरी चैनल रखें जो उस पथ पर निर्भर न हो जिसे आप बदल रहे हैं, क्योंकि यहाँ की गलती सुधार को ही बंद कर देती है।
इसे नए सत्र से सिद्ध करें, पुराने से नहीं
स्थापित टर्मिनल कुछ सिद्ध नहीं करता, क्योंकि उसे परिवर्तन से पहले प्रवेश दिया गया था। हर इच्छित प्रवेश से एक नया सत्र खोलें।
ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30फिर VPN पुनःकनेक्ट दोहराएँ और फिर कोशिश करें, क्योंकि पुनःकनेक्ट से बचने वाला मार्ग उस तालिका में जोड़े गए मार्ग के समान नहीं है जिसे पुनःकनेक्ट साफ़ कर देता है। अस्वीकृत स्रोतों को अनुमत स्रोतों से अलग देखें, ताकि अवरुद्ध प्रयास काम करते सत्र के पीछे न छिपे। परिणाम के पास स्थानीय पता, नियम और तालिका सहेजें। अगर आप इसके बजाय पोर्ट बाँटते हैं, तो इसे SSH की सीमा नहीं बल्कि परिचालन निर्णय के रूप में दर्ज करें।