VPN पछाडिको SaaS एडमिन क्षेत्र: कुन ठेगानामा भरोसा गर्ने?

सार्वजनिक SaaS पृष्ठहरू सबैका लागि खुला रहन सक्छन्, जबकि तिनीहरूको पछाडिका एडमिन अपरेसनहरू VPN बाहिरका सबैलाई अस्वीकार गर्छन्। यो सम्भव बनाउने संयन्त्र कुनै लुकेको मेनु वा छुट्टै लगइन पृष्ठ होइन; यो अनुरोध पुर्याउने नेटवर्क मार्गको जाँच हो। ठेगानाको प्रमाण गलत भयो भने जाँचले या त साँचो एडमिनहरूलाई बाहिर राख्छ या हेडर टाइप गर्न सक्ने जो कोहीलाई भित्र पसाउँछ। ओरिजिनले वास्तवमा के प्राप्त गर्छ भन्नेबाट सुरु गर्नुहोस्।

टनेलपछि ओरिजिनले वास्तवमा के प्राप्त गर्छ

जब ब्राउजरले इन्टरनेट ट्राफिक पनि बोक्ने VPN मार्फत सार्वजनिक साइटमा पुग्छ, गेटवेले जडान बाहिर जानु अघि अनुवाद गर्छ। SaaS ले गेटवेको सार्वजनिक इग्रेस ठेगाना देख्छ, सामान्यतया एउटा ठेगाना वा सानो दायरा, र ल्यापटपको टनेल ठेगाना कहिल्यै देख्दैन। त्यसैले 10.90.0.42 लाई अनुमत सूचीमा राख्न असफल हुन्छ, र त्यसैले सम्पूर्ण RFC 1918 राख्न अझ ठूलो स्वरमा असफल हुन्छ: दोस्रोले तपाईंसम्म पुग्न सक्ने हरेक निजी नेटवर्कलाई भित्र पसाउँछ। सर्त राख्न योग्य एकमात्र ठेगाना त्यो हो जुन तपाईंको संस्थाले निकासमा वास्तवमा स्वामित्व राख्छ।

curl -s https://ifconfig.me
dig +short admin.example.com

विभाजित टनेलिङले यो धारणा चुपचाप तोड्छ। यदि VPN ले निजी कार्यालय मार्गहरू मात्र बोक्छ भने, सार्वजनिक एडमिन होस्टनामको अनुरोध स्थानीय ISP मार्फत बाहिर जान्छ र ओरिजिनले आवासीय ठेगाना देख्छ। जडान भएको VPN आइकनले यो विशिष्ट गन्तव्यबारे केही पनि प्रमाणित गर्दैन, त्यसैले टनेल होइन, गन्तव्य परीक्षण गर्नुहोस्।

निकास ठेगाना प्रति प्रयोगकर्ता फरक पर्छ भने कुनै पनि नीति लेख्नु अघि रोक्नुहोस् र राउटिङ सुधार्नुहोस्। केही एडमिनसँग मात्र मेल खाने सर्त कुनै सर्त नहुनुभन्दा नराम्रो हो, किनकि यसले घटना नहुँदासम्म समस्या लुकाउँछ।

ठेगाना फेरि लेख्ने प्रोक्सीमा मात्र भरोसा गर्नुहोस्

अधिकांश सार्वजनिक साइटहरू CDN वा रिभर्स प्रोक्सी पछाडि हुन्छन्, त्यसैले ओरिजिनको सकेट ठेगाना आगन्तुकको होइन, त्यो फ्रन्टएन्डको हो। फ्रन्टएन्डले सामान्यतया मूल ठेगाना हेडरमा अगाडि पठाउँछ, र ओरिजिनले त्यो हेडरलाई ज्ञात प्रोक्सीहरूबाट मात्र स्वीकार गरेन भने त्यो हेडर आक्रमणकारीको नियन्त्रणमा हुन्छ। विश्वसनीय स्रोतहरूको सूची स्पष्ट रूपमा कन्फिगर गर्नुहोस् र ओरिजिनलाई अन्य कतैबाट पनि पुग्न नसकिने बनाउनुहोस्। त्यो दोस्रो आधा बिना आक्रमणकारीले प्रोक्सी छोडेर हेडर सिधै पठाउँछ।

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

सर्तलाई हरेक संरक्षित अपरेसनमा जोड्नुहोस्

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

त्यही सीमाले JSON API, निर्यात, हस्ताक्षर गरिएका डाउनलोड URL र WebSocket ह्यान्डशेक पनि समेट्नुपर्छ, किनकि तीमध्ये कुनैलाई पहिले HTML पृष्ठ अनुरोध गर्न आवश्यक पर्दैन। VPN चालु हुँदा बनाइएको डाउनलोड लिंक, डाउनलोड एन्डप्वाइन्टले फेरि जाँच नगरेसम्म पछि पनि मान्य रहन्छ। लामो समयका सत्रलाई पनि पुनर्मूल्यांकन नियम चाहिन्छ, नत्र एउटा प्रमाणित अनुरोध स्थायी छुट बन्छ। पूर्वनिर्धारित अस्वीकार नै कर्मचारी परिवर्तनमा टिक्ने एकमात्र सेटिङ हो।

साझा क्यासहरू जाँचको वरिपरिको अर्को बाटो हुन्। जसमा पहिले नै संरक्षित प्रतिक्रिया छ त्यस्तो क्यासले ओरिजिनलाई सम्पर्क नगरी त्यो दिन सक्छ, त्यसैले एडमिन प्रतिक्रियाहरूलाई निजी चिन्ह लगाउनुहोस् र साझा भण्डारणबाट बाहिर राख्नुहोस्। यदि क्यासले ती दिनैपर्छ भने, पहुँच जाँच दिनु अघि चल्नुपर्छ, जसको सामान्य अर्थ त्यो साझा क्यास हुनै सक्दैन।

तपाईंले भर्खर बन्द गरेका बाइपासहरू परीक्षण गर्नुहोस्

सुखद मार्ग होइन, म्याट्रिक्स अभ्यास गर्नुहोस्: VPN मार्फत एडमिन, त्यो बिना त्यही एडमिन, त्यसबाट गुज्रने गैर-एडमिन, र नक्कली ठेगाना हेडर। सिधै ओरिजिनमा अनुरोध र क्यास गरिएको प्रतिक्रियाको अनुरोध थप्नुहोस्, किनकि ती दुईले फ्रन्टएन्डलाई पूर्ण रूपमा छोड्छन्।

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

हरेक अनुरोधले नीतिले वाचा गरेको स्थिति फर्काउनुपर्छ, र लगले कुन ठेगाना प्रमाण प्रयोग भयो त्यो अभिलेख गर्नुपर्छ। IPv6 लाई छुट्टै समेट्नुहोस्, किनकि दोहोरो स्ट्याक ओरिजिनले तपाईंले परीक्षण गरेकोभन्दा फरक स्रोत परिवार देख्न सक्छ। सामान्य ग्राहक अपरेसनहरू VPN बाहिर चलिरहन दिनुहोस्, नत्र ग्राहकले पहिलो पटक गुनासो गर्दा परिवर्तन फिर्ता लिइन्छ। प्रत्येक पङ्क्तिको अपेक्षित नतिजा चलाउनु अघि लेख्नुहोस्, ताकि आश्चर्यजनक पास देखिने होस्।

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