VPN वापरकर्ते जंप होस्ट न पार करता सर्व्हरपर्यंत पोहोचू शकतात का, हा नेटवर्किंगच्या पोशाखातील धोरणाचा प्रश्न आहे. बास्टियन आवश्यक नियंत्रण करत असेल, तर VPN ला जोडणे तिच्याकडे नेले पाहिजे, तिच्याभोवती फिरून नाही. जंप होस्टने पूर्वी अगम्य असलेल्या खंडाला फक्त जोडले असेल, तर अरुंद थेट मार्ग हा प्रामाणिक पर्याय ठरू शकतो. खालील तपासण्या क्रमाने करा आणि पहिल्या अयशस्वी तपासणीवर थांबा, कारण तेच उत्तर उर्वरित ठरवते.

बास्टियन प्रत्यक्षात काय नियंत्रित करते ते तपासा

डिझाइन दस्तऐवजातील आकृतीने नाही, तर वर्तमानाबद्दलच्या पुराव्याने सुरुवात करा. लक्ष्याची SSH संरचना आणि पॅकेट फिल्टर पहा: जर आवक पोर्ट 22 केवळ बास्टियनच्या पत्त्यावरून स्वीकारला जात असेल, तर जंप होस्ट हे लादलेले नियंत्रण आहे. जर तोच पोर्ट संपूर्ण VPN पूलमधून जोडण्या स्वीकारत असेल, तर बास्टियन फक्त सोय होती आणि अंमलबजावणी पूर्णपणे दुसरीकडे राहते. तिकीट इतिहास सहसा दोघांपैकी आधी कोण होते हे पुष्टी करतो.

बास्टियन देत असलेल्या नियंत्रणाचे नाव घेणाऱ्या एका वाक्यात निष्कर्ष मांडा: गंतव्य मर्यादा, दुसरी प्रमाणीकरण पायरी, सत्र रेकॉर्डिंग, किंवा घटनेच्या वेळी कार्यात्मक दृश्यता. तेच वाक्य बदली धोरणाने जपायचे आहे.

लक्ष्य मार्ग वेगळे ओळखू शकते का ते तपासा

स्रोत-पत्त्याचे नियम तोपर्यंतच काम करतात, जोपर्यंत दोन्ही मार्ग वेगवेगळ्या स्रोत पत्त्यांसह येतात. सर्व्हर उपजाळापर्यंतचा रहदारी मास्क करणारे VPN गेटवे तो फरक पुसून टाकते, आणि मग पोर्ट 22 वरील प्रत्येक जोडणी गेटवेकडून आल्यासारखी दिसते. तपासणी लक्ष्यावरच स्थानिक आहे आणि क्षणभर घेते: प्रस्थापित SSH सत्रे यादी करा आणि प्रत्येकाचा समवर्ती पत्ता वाचा.

जेव्हा दोन्ही मार्ग एका पत्त्यात विलीन होतात, तेव्हा फरक आधी करावा लागतो: VPN ला कोणत्या गंतव्यांकडे पाठवण्याची परवानगी आहे आणि गेटवेच्या स्वतःच्या फिल्टरद्वारे. अशा स्थितीत लक्ष्यावर नियम जोडल्याने जे येते ते न बदलता सीमेचा भ्रम निर्माण होतो.

प्रत्येक नोंद प्रत्यक्षात काय ठेवते ते तपासा

तीन वेगवेगळे लॉग तीन वेगवेगळ्या घटनांचे वर्णन करतात, आणि एकही दुसऱ्याची जागा घेत नाही. VPN ची जोडणी नोंद दाखवते की एक ओळख नेटवर्कच्या व्याप्तीत आली. बास्टियनची अग्रेषण नोंद दाखवते की TCP वाहिनी तिला सोडून गंतव्य आणि पोर्टकडे जाते. लक्ष्याचा प्रमाणीकरण लॉग दाखवतो की खात्याने SSH द्वारे साइन इन केले. त्या एकत्र वाचल्यानेच कालरेषा तयार होते; एकटी वाचल्याने अंदाज तयार होतो.

यापैकी कोणतीही नोंद क्लायंट आणि लक्ष्य यांच्यातील एन्क्रिप्टेड सत्राच्या आत काय घडले हे धरत नाही. आदेश-स्तरीय पुनरावलोकन आवश्यक असल्यास, स्वतःच्या माहिती-हाताळणी नियमांसह जाणीवपूर्वक तैनात केलेली नोंदणी यंत्रणा लागते. जंप-होस्ट लॉगकडून त्याची अपेक्षा करणे हा तोच मार्ग आहे ज्यामुळे ऑडिटची तफावत महत्त्वाची होईपर्यंत लपून राहते.

धोरण प्रत्यक्षात कुठे लागू होते ते तपासा

ProxyJump सारखी क्लायंट सेटिंग विनंती आहे, निर्बंध नाही. गंतव्य पोहोचण्यायोग्य असल्यास OpenSSH आनंदाने थेट जोडणी उघडेल, म्हणून लॅपटॉपवरील संरचना फाइली हेतू वर्णन करतात तर फायरवॉल निकाल ठरवतात. अंमलबजावणी VPN गेटवेच्या परवानगी असलेल्या गंतव्यांमध्ये आणि लक्ष्याच्या स्वतःच्या प्रवेश नियमांमध्ये असते, आणि वापरकर्ता दोन्हीपैकी काहीही संपादित करू शकत नाही. त्याच वेळी पर्यायी मार्गांचे ऑडिट करा: दुसरा इंटरफेस, सार्वजनिक श्रोता, मेश थर किंवा जुना साइट-ते-साइट बोगदा — यापैकी प्रत्येक आत्ता बंद केलेला शॉर्टकट पुनर्संचयित करू शकतो.

तरीही ProxyJump संरचीत करा, कारण ते मंजूर मार्ग सोपा करते आणि नित्यक्रमाचे काम अपवाद निर्माण करू देत नाही. विश्वास ठेवण्यापूर्वी क्लायंट प्रत्यक्षात काय सोडवतो याची पुष्टी करा.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

जाणीवपूर्वक थेट प्रयत्नाने पडताळा

जे धोरण कधीच तपासले नाही ते आशा आहे. VPN ला जोडलेल्या क्लायंटवरून आता नाकारला पाहिजे असलेला मार्ग प्रयत्न करा, नंतर मंजूर मार्ग प्रयत्न करा, आणि दोन्ही निकाल ठेवा. नाकारलेला प्रयत्न हाच बदल प्रभावी झाल्याचा पुरावा आहे.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

स्वच्छ निकाल लक्ष्य पत्त्याकडील नाकारलेल्या किंवा वेळोवेळी संपलेल्या थेट जोडणीसारखा दिसतो, त्यानंतर जंप होस्टवर यशस्वी साइन-इन आणि लक्ष्याच्या बाजूला समर्थित स्रोताचे नाव घेणारी प्रमाणीकरण नोंद. याशिवाय काहीही असेल तर सीमा अजूनही छिद्रयुक्त आहे, दस्तऐवज काहीही सांगो. तारीख, बदललेला नियम आणि दोन्ही निकाल नोंदवा, नंतर पुनर्प्राप्ती मार्गाला एक मालक आणि एक समाप्ती तारीख द्या जेणेकरून आपत्कालीन प्रवेश शांतपणे रोजचा मार्ग होणार नाही.

संबंधित लेख