SSH बास्टियन वा सिधा VPN पहुँच: कुन नीति लागू हुन्छ?

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

सफा नतिजा लक्ष्य ठेगानातर्फ अस्वीकृत वा समय सकिएको सिधा जडानजस्तो देखिन्छ, त्यसपछि जम्प होस्टमा सफल साइन-इन र लक्ष्यको पक्षमा समर्थित स्रोतको नाम लिने प्रमाणीकरण प्रविष्टि। यसबाहेक अरू केही भए सीमा अझै छिद्रयुक्त छ, कागजातले जे भने पनि। मिति, बदलिएको नियम र दुवै नतिजा लेख्नुहोस्, त्यसपछि पुनःप्राप्ति मार्गलाई एक मालिक र एक समाप्ति मिति दिनुहोस् ताकि आपत्कालीन पहुँच चुपचाप दैनिक मार्ग नबनोस्।