स्रोत-पोर्ट नियम तुमचा एक SSH मार्ग का तोडतो

एकाच होस्टवर दोन व्यवस्थापन प्रवेश, एक सेवा पोर्ट आणि दोन्हींना मदत करायचा असलेला धोरण नियम। नियम स्रोत पोर्ट 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 ची मर्यादा न मानता कार्यचालन निर्णय म्हणून नोंदवा।