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

प्याकेट डिक्रिप्शनपछि कोर्नुहोस्, अगाडि होइन

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

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

  1. टाढाको ग्राहक: सुरुङ सिर्जना गर्ने प्रयोगकर्ताको उपकरण।
  2. किनारा नीति: बाहिरी यातायातलाई सार्वजनिक सुन्नेमा स्वीकार गर्ने नियमसमूह।
  3. अन्त्य गर्ने उपकरण: प्याकेट डिक्याप्सुलेट गरी साधारण IP लाई सुम्पने VPN अन्त्य बिन्दु।
  4. भित्री फिल्टर: ग्राहकदेखि सेवासम्मको ट्राफिक सीमित गर्ने फर्वार्डिङ वा सुरक्षा-समूह नियमसमूह।
  5. अनुप्रयोग होस्ट: डिक्रिप्ट गरिएको अनुरोध प्राप्त गर्ने सेवा।

दुई नीति, दुई मालिक

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

प्रमाणपत्र र बहु-कारक प्रमाणीकरण जस्ता प्रवेश नियन्त्रणहरू पहिचानको जवाफ दिन्छन्, अरू कुराको होइन। तिनले स्थान निर्धारण गर्दैनन्, र प्रयोगकर्ता भित्र पसेपछि स्रोतअनुसार अनुमति दिँदैनन्।

स्थानले अनुरोध कुन सीमा पार गर्छ भन्ने निर्धारण गर्छ

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

PlacementWhat terminates thereWhat sees plaintextWhich control can still denyFailure domain
Termination in a dedicated segmentA dedicated VPN endpointThe endpoint and anything on its segmentThe filter between that segment and the applicationThe segment path can bypass the filter if no rule sits on it
Termination on the edge firewallThe firewall's public listenerThe firewall, after decapsulationThe firewall's inner rule setAdmission and inspection fail together
Termination on the protected LANThe appliance's LAN legEvery host on the protected LANOnly a host control or a downstream gatewayThe appliance and the protected hosts fail together

तेस्रो स्थान नै कार्यान्वयन चुपचाप हटाउने स्थान हो, किनकि संरक्षित खण्डमा रहेको खुट्टाले उपकरणलाई रेखाचित्रले नदेखाउन सक्ने सिधा बाटो दिन्छ। चित्र होइन, इन्टरफेस र मार्ग जाँच्नुहोस्: ip route get 10.20.5.10 ले प्याकेट कुन इन्टरफेसबाट निस्कने बताउँछ, र उत्तर प्रायः डिजाइनले मानेको हुँदैन। पोस्चरबीचको ट्राफिक नियन्त्रण गर्ने फायरवालको परम्परागत भूमिका, तलको कागजातमा वर्णन गरिएअनुसार,NIST SP 800-41 यहाँ उपयोगी परीक्षण हो, किनकि संरक्षित सञ्जालतर्फ असीमित खुट्टा भएको उपकरणले धेरै नियन्त्रण गर्दैन। मार्ग खोजी प्रस्तुतीकरणको रेखाचित्रभन्दा बढी इमानदार रेखाचित्र हो।

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

अनुवादले तलका नियमले के देख्न सक्छन् भन्ने बदल्छ

स्रोत अनुवाद सुविधाजनक छ र यसले जानकारी नष्ट गर्छ। masquerade पछि प्रत्येक ग्राहक उपकरणजस्तै देखिन्छ, त्यसैले प्रयोगकर्ता छुट्याउन लेखिएको तलको नियमले अब त्यो गर्न सक्दैन। यो केवल लगिङ समस्या होइन, यो नीति समस्या हो: ग्राहक ठेगानामा कुञ्जी गरिएको नियम चुपचाप गेटवेमा कुञ्जी गरिएको नियम बन्छ। प्रयोगकर्ताअनुसार नीति महत्त्वपूर्ण भए स्रोत जोगाउनुहोस् वा अनुवादअघि नीति लागू गर्नुहोस्।

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

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

एउटा अनुमत र एउटा अस्वीकृत कार्य स्वीकार गर्नुहोस्

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

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

अन्त्य बिन्दु, डिक्रिप्ट गरिएको बाटो र त्यसलाई सीमित गर्ने नियन्त्रण कागजात गर्नुहोस्। ती तीन पङ्क्ति कार्यान्वयनलाई जे नाम दिए पनि अर्थपूर्ण रहन्छन्।

सम्बन्धित लेखहरू