क्लाउड सीमामा VPN क्लाइन्टका IP सुरक्षित राख्नुहोस् वा SNAT गर्नुहोस्
स्रोत सुरक्षित राख्दा हरेक लगमा क्लाइन्टको पहिचान रहन्छ, SNAT ले राउटिङ तालिका सानो राख्छ। तीन सर्तले अनुप्रयोगलाई कुन चाहिन्छ भन्ने बताउँछन्।
VPN क्लाइन्टको ठेगाना अनुप्रयोगसम्मै राख्दा हरेक लग लाइन र अनुमति सूचीको हरेक प्रविष्टिले एउटै अर्थ राख्छ। क्लाउड किनारमा यसलाई पुनःलेख्दा राउटिङ तालिका सरल हुन्छ र लग कम उपयोगी हुन्छ। दुवैमध्ये कुनै पनि विकल्प आफैंमा गलत छैन, र यसलाई टुंगो लगाउने तर्क विरलै प्रदर्शनसँग सम्बन्धित हुन्छ। तीन सर्तले टुंगो लगाउँछन्: कुन मान्छे जोडियो भन्ने अनुप्रयोगले जान्नै पर्छ कि, तपाईंले पठाउन खोजेको स्रोत क्लाउड फ्याब्रिकले स्वीकार्छ कि, र पछि फर्किने मार्गको जिम्मेवारी कसले लिन्छ।
तीन सर्तले टुंगो लगाउँछन्
नेटवर्क रेखाचित्रबाट होइन, अनुप्रयोगको आवश्यकताबाट सुरु गर्नुहोस्। यदि अनुमति वा लेखापरीक्षण व्यक्तिगत क्लाइन्ट ठेगानामा निर्भर छ भने त्यसलाई सुरक्षित राख्नु कार्यात्मक आवश्यकता हो र अनुवाद गर्नु अवनति हो। यदि अनुप्रयोगले ट्राफिक दूरस्थ पहुँच मार्गबाट आयो भन्ने मात्र जान्नुपर्छ भने अनुवादित ठेगाना पर्याप्त हुन्छ र चलाउन धेरै सस्तो हुन्छ।
दोस्रो सर्त यान्त्रिक छ। भर्चुअल नेटवर्कले पठाउने इन्टरफेसलाई दिइएको नभएको ठेगाना दाबी गर्ने प्याकेटलाई स्वतः विश्वास गर्दैन। अधिकांश क्लाउड फ्याब्रिकले यसलाई विभिन्न तरिका र नाममा लागू गर्छन्, र यसलाई बेवास्ता गर्ने डिजाइन रेखाचित्रमा सही देखिन्छ र उत्पादनमा चुपचाप खस्छ।
तेस्रो संगठनात्मक छ। स्रोत सुरक्षित राख्नु भन्नाले अनुप्रयोग सबनेटको राउटिङ तालिकाले क्लाइन्ट प्रिफिक्सका लागि गेटवेतिर फर्केर देखाउनुपर्छ, र पछि सबनेट थप्ने हरेक टोलीले त्यो मार्ग सुसंगत राख्नुपर्छ। यो एकपटकको सानो लागत हो र दर्जनौं खातामा दोहोरिने लागत हो। यो व्यवहारको वाचा गर्नुअघि कसले तिर्ने टुंगो लगाउनुहोस्।
मार्ग भनेको नक्कली बनाउने अनुमति होइन
फर्किने मार्ग थप्दा तपाईंको सबनेटलाई जवाफ कहाँ जानुपर्छ भन्ने थाहा हुन्छ। त्यसले फ्याब्रिकलाई ती प्याकेट अगाडि पठाउने इन्स्टेन्सलाई विदेशी स्रोतसहित पठाउने अधिकार छ भनी बताउँदैन। AWS मा सम्बन्धित नियन्त्रण स्रोत र गन्तव्य जाँच हो, र यो हरेक इन्स्टेन्सका लागि देखिन्छ:
aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
--query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
--no-source-dest-checkयो केवल त्यो इन्स्टेन्सका लागि बन्द गर्नुहोस् जसको अभिलेखित काम अगाडि पठाउनु हो, र अरू कुनैका लागि होइन। जाँच खुला राख्ने हरेक अनुप्रयोग VM भनेको उधारो लिएको स्रोतसहित ट्राफिक पठाउन प्रयोग गर्न सकिने एक मेसिन कम हो। यदि तपाईंको प्लेटफर्म AWS होइन भने व्यवहार सर्छ भनी मान्नुको सट्टा समान एन्टी-स्पुफिङ वा अनुमत ठेगाना सेटिङ खोज्नुहोस्।
द्रुत प्याकेट क्याप्चरले कन्सोल पढ्नुभन्दा छिटो प्रश्न टुंग्याउँछ। यदि जवाफ बाहिर गयो र क्लाइन्टले कहिल्यै देखेन भने अनुप्रयोग असफल हुँदैन, फ्याब्रिकले नक्कली स्रोत फाल्दै छ।
अनुवादले के किन्छ र के खर्च गराउँछ
गेटवेमा स्रोत पुनःलेख्दा फर्किने मार्गको समस्या हट्छ। अनुप्रयोगले आफूलाई पुग्ने तरिका पहिल्यै थाहा भएको एउटा ठेगाना देख्छ, र क्लाइन्ट प्रिफिक्स कहिल्यै क्लाउड राउट तालिकामा आउनुपर्दैन। Linux मा नियम एक लाइन हो, र तपाईंले लेख्न सक्ने सबैभन्दा साँघुरो संस्करण लेख्नु उपयुक्त हुन्छ:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10अनुप्रयोगले अब के अभिलेख गर्छ हेर्नुहोस्: हरेक प्रयोगकर्ताका लागि 10.40.3.10, हरेक जडानमा, सधैंका लागि। त्यो मानमा बनेको कुनै पनि ठेगाना अनुमति सूचीले अब सम्पूर्ण दूरस्थ पहुँच जनसंख्यालाई पहुँच दिन्छ, र कुनै पनि घटना समीक्षाले यो को थियो भन्ने जवाफ दिन गेटवेमा फर्किनुपर्छ।
समाधान अनुवाद त्याग्नु होइन, ठेगाना नै पहिचान हो भनेर नाटक गर्न छोड्नु हो। क्लाइन्टको पहिचान प्रमाणित क्षेत्रमा बोक्नुहोस्, गेटवेमा अनुवादित टुपलसँगै त्यो लग गर्नुहोस्, र अनुप्रयोगलाई त्यसमा जोडिन दिनुहोस्। जोडिने कुञ्जी बिना अनुवादले सञ्जाल समस्यालाई स्थायी फरेन्सिक समस्यामा बदल्छ।
रिले फरक इन्टरफेस हो
अनुप्रयोगअगाडिको रिभर्स प्रोक्सीले राउट गरिएको मार्गको प्रश्न पूर्ण रूपमा छल्छ। प्रोक्सीले आफ्नै ब्याकएन्ड जडान खोल्छ, त्यसैले क्लाइन्ट प्रिफिक्स भर्चुअल नेटवर्कभित्र कहिल्यै राउट गर्न योग्य हुनुपर्दैन, र अनुप्रयोगले प्रोक्सीले सेट गर्ने हेडरमा पहिचान पाउन सक्छ।
त्यो हेडर तब मात्र विश्वसनीय हुन्छ जब ब्याकएन्डले यसलाई प्रोक्सीबाट स्वीकार्छ र अरू कुनैबाट स्वीकार गर्दैन। nginx का शब्दमा यसको अर्थ आउने जे पनि विश्वास गर्नुको सट्टा विश्वसनीय साझेदारको नाम स्पष्ट रूपमा दिनु हो:
set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;ब्याकएन्डसम्म सिधै पुग्न सक्ने कुनै पनि क्लाइन्टले त्यही हेडर नक्कली बनाउन सक्छ, त्यसैले ब्याकएन्ड प्रोक्सीबाहेक अरू कुनै तरिकाले पुग्न नसकिने हुनुपर्छ। यो फायरवालको तथ्य हो, कन्फिगरेसनको राय होइन, र स्निपेट प्रतिलिपि गर्दा मानिसहरूले यही मान्यता छोड्छन्।
रिलेले तपाईंले के किन्दै हुनुहुन्छ त्यो पनि बदल्छ। तपाईंले अनुप्रयोग-स्तरको पहिचान र त्यसलाई लग गर्ने प्राकृतिक ठाउँ पाउनुहुन्छ; तपाईंले सामान्यता त्याग्नुहुन्छ, किनकि हरेक नयाँ प्रोटोकललाई आफ्नै प्रोक्सी समर्थन चाहिन्छ। HTTP सेवाहरूका लागि त्यो साटासाट सामान्यतया राम्रो हुन्छ, र HTTP नभएका कुनै पनि कुराका लागि सामान्यतया त्यो उपलब्ध नै हुँदैन।
हरेक सीमाले के देख्छ लेख्नुहोस्
तपाईंले जे रोज्नुभए पनि, डिजाइन समीक्षा हरेक हपमा स्रोत ठेगाना र प्रमाणित गर्न सकिने पहिचान नाम दिने एउटा तालिकामा टुंगिनुपर्छ। त्यो बिना पहिलो घटनाले तीन टोली उत्पन्न गर्छ जसले प्रत्येकले फरक क्लाइन्टको वर्णन गर्छ।
| Boundary | Source the next hop sees | What is actually proven |
|---|---|---|
| Client to gateway | 172.20.8.14 | A certificate or credential was presented |
| Gateway to app subnet, preserved | 172.20.8.14 | The same session, if the return route exists |
| Gateway to app subnet, translated | 10.40.3.10 | Only that traffic came through the gateway |
| Proxy to backend | 10.40.3.10 plus a header | The proxy asserted an identity it authenticated |
त्यसपछि रोज्नुहोस्। अनुप्रयोगको अनुमति साँच्चै क्लाइन्ट ठेगानामा निर्भर छ र तपाईं मार्गको जिम्मेवारी लिन सक्नुहुन्छ भने स्रोत सुरक्षित राख्नुहोस्। त्यस्तो छैन र तपाईं पहिचान ब्यान्डबाहिर बोक्न सक्नुहुन्छ भने अनुवाद गर्नुहोस्, र प्लेटफर्म-विशिष्ट अगाडि पठाउने सेटिङका लागि AWS अगाडि पठाउने इन्स्टेन्स निर्देशिका प्रयोग गर्नुहोस्। सेवा HTTP बोल्छ र पहिचान बिल्कुलै ठेगाना नरहोस् भन्ने चाहनुहुन्छ भने रिलेतिर जानुहोस्।