क्लाउड सीमेवर 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 बोलत असेल आणि ओळख अजिबात पत्ता नसावी असे वाटत असेल तर रिलेकडे वळा।