स्रोत-पोर्ट नियमले तपाईंको एउटा 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 को सीमा नभई सञ्चालन निर्णयका रूपमा अभिलेख गर्नुहोस्।