un: इंग्रेस और एग्रेस अलगाव

un

अतिथि

1 / ?

दो ट्रैफिक दिशाएं, एक बॉक्स

स्वागत है

अधिकांश आर्किटेक्चरल डायग्राम्स में ट्रैफिक एक ही दिशा में दिखाया जाता है: क्लाइंट ऊपर, सर्वर नीचे, और तीर नीचे की ओर इशारा कर रहा है। वास्तविकता में, ट्रैफिक दोनों दिशाओं में बहता है।

इंग्रेस: बाहरी क्लाइंट आपके सर्विसेस तक इस पथ के माध्यम से पहुंचते हैं। आपके नेटवर्क के किनारे पर एक रिवर्स प्रॉक्सी TLS को समाप्त करता है, अनुरोधों को राउट करता है, और एक्सेस नीति को लागू करता है।

एग्रेस: आपके सर्विसेस बाहरी सर्विसेस तक इस पथ के माध्यम से पहुंचते हैं। भुगतान प्रोसेसर के API को कॉल करना, एक वेबहुक टार्गेट प्राप्त करना, या किसी पार्टनर को अनुरोध भेजना। अक्सर यह एक फॉरवर्ड प्रॉक्सी या NAT गेटवे के माध्यम से होता है जिसमें एक एलाउलिस्ट (allowlist) होता है।

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

इस पाठ के अंत तक आप समझ पाएंगे:

- इनग्रेस और एग्रेस मूल रूप से अलग-अलग ट्रैफिक पैटर्न, अलग-अलग स्केलिंग अक्ष और अलग-अलग विफलता मोड का प्रतिनिधित्व क्यों करते हैं

- हैरिपिन NAT और यह कि एक प्रॉक्सी जो स्वयं से कनेक्ट करने की कोशिश करता है, विफल क्यों होता है

- आर्किटेक्चरल फोर्क: एक बॉक्स दो बन जाता है, और फिर प्रत्येक एक किस चीज़ का अनन्य स्वामी बन जाता है

- सुरक्षा पृथक्करण लाभ: प्रत्येक पक्ष अपने वास्तविक अनुमत पीर्स तक सीमित हो सकता है

- यह पहचानने का तरीका कि कब आपका सिंगल-बॉक्स डिज़ाइन उस सीमा पार कर चुका है जहाँ विभाजन आवश्यक हो जाता है

दिशाओं को अलग-अलग टूल्स की आवश्यकता क्यों है

एक नेटवर्क सीमा पर दो अलग-अलग वर्कलोड

इंग्रेस ट्रैफिक की विशेषताएँ:

- बाहरी पक्षों (सामान्य इंटरनेट) द्वारा प्रारंभ किया जाता है

- मात्रा आपके उपयोगकर्ता आधार के साथ बढ़ती है

- TLS समाप्ति, अनुरोध राउटिंग, स्रोत के अनुसार दर सीमांकन

- गहराई तक रक्षा की चिंताएँ: DDoS, दुरुपयोग, स्क्रैपिंग

- सार्वजनिक IP को किसी भी व्यक्ति से कनेक्शन स्वीकार करने की आवश्यकता होती है

एग्रेस ट्रैफिक की विशेषताएँ:

- आपके अपने सेवाओं द्वारा प्रारंभ किया गया (एक ज्ञात, छोटा सेट क्लाइंट्स)

- मात्रा आपके सेवा-से-सेवा (service-to-service) और बाहरी-API कॉल पैटर्न के साथ स्केल होती है

- रिमोट एंडपॉइंट्स पर स्रोत-IP की अनुमति सूची (आपके पास एक निश्चित आउटबाउंड IP है जिस पर पार्टनर्स भरोसा करते हैं)

- रक्षा-में-गहराई (defense-in-depth) की चिंताएं: डेटा का चोरी से निकाला जाना, संक्रमित आंतरिक सेवाओं द्वारा बाहर कॉल करना

- आपके अपने सेवाओं के अलावा किसी भी अन्य व्यक्ति से कनेक्शन अस्वीकार करना चाहिए

मुख्य असममितता (asymmetry): इंग्रेस (ingress) दुनिया से ट्रैफिक स्वीकार करता है; एग्रेस (egress) ट्रैफिक केवल आपके अपने सेवाओं से स्वीकार करता है। इन्हें एक ही मशीन पर रखने का मतलब है कि उस मशीन को एक ही समय पर दुनिया से पहुँच योग्य होना चाहिए (इंग्रेस के लिए) और केवल आपके सेवाओं से पहुँच योग्य होना चाहिए (एग्रेस के लिए)। फायरवॉल नियम जो एक को संतुष्ट करते हैं, वे दूसरे के विरुद्ध काम करते हैं।

विकास पथ: एक छोटा प्रोजेक्ट दोनों को एक IP और एक टूल के पीछे छुपा सकता है, क्योंकि मात्रा छोटी है और पार्टनर-IP-अनुमति सूची लंबी नहीं है। जैसे-जैसे प्रोजेट बढ़ता है, इन दोनों भूमिकाओं के बीच घर्षण बढ़ता है, और एक दिन एक विशिष्ट विफलता मोड (हेयरपिन NAT) विभाजन को ज़रूरी बना देता है।

Ingress vs egress: different sources, different destinations, different requirements

एक छोटी स्टार्टअप कंपनी सभी सेवाओं (इंग्रेस रिवर्स प्रॉक्सी, एग्रेस फॉरवर्ड प्रॉक्सी / NAT, और आंतरिक सेवाएं) एक ही VM पर एक सार्वजनिक IP के साथ चलाती है। चूंकि वे अभी शुरुआती चरण में हैं, इसलिए ऐसा लगता है कि यह ठीक है। बताइए कि जैसे-जैसे वे बढ़ेंगी, इस डिज़ाइन को दो विशिष्ट विफलता मोड (failure modes) या संचालन संबंधी समस्याओं (operational pains) का सामना करना पड़ेगा, और प्रत्येक के लिए इसका मूल कारण समझाएं।

वह बग जो विभाजन (split) को ज़रूरी बनाता है

एक सैनिटाइज़्ड आउटेज कहानी

उत्पादन फ्लीट्स में होने वाली एक वास्तविक आर्किटेक्चरल फॉर्क की कल्पना करें। नीचे दिए गए नाम बदल दिए गए हैं; आकार वही है जो टीमों को वास्तविक परिदृश्यों में सामने आता है।

एक संगठन 203.0.113.5 पर एकल प्रॉक्सी सर्वर चलाता है। यह इनग्रेस (यूज़र्स के लिए पोर्ट 443) और एग्रेस (आउटबाउंड कॉल करने वाले आंतरिक सेवाओं के लिए पोर्ट 1080 SOCKS5) को संभालता है। आंतरिक सेवाएँ प्राइवेट सबनेट्स में स्थित हैं और उसी SOCKS5 प्रॉक्सी 203.0.113.5:1080 के माध्यम से सभी आउटबाउंड ट्रैफिक को राउट करती हैं।

उसी 203.0.113.5 के पीछे होस्ट की गई सेवाओं में से एक api.example.com है। पब्लिक DNS api.example.com को 203.0.113.5 के रूप में रिज़ॉल्व करता है।

अब एक अलग आंतरिक सेवा को api.example.com को कॉल करने की आवश्यकता है। इसका आउटबाउंड पथ:

1. आंतरिक सेवा api.example.com → 203.0.113.5 को रिज़ॉल्व करती है

2. आंतरिक सेवा अनुरोध को 203.0.113.5:1080 पर स्थित SOCKS5 एग्रेस प्रॉक्सी के माध्यम से भेजती है

3. प्रॉक्सी खुद से 203.0.113.5:443 तक कनेक्शन खोलने का प्रयास करता है

4. Connection refused. पैकेट को उसी NAT से बाहर निकलना और फिर वापस उसी NAT में प्रवेश करना पड़ता है, जिसे अधिकांश नेटवर्क स्टैक्स अस्वीकार कर देते हैं। प्रॉक्सी अपने ही पब्लिक IP के माध्यम से खुद से कनेक्ट नहीं कर सकता।

यह हैयरपिन NAT है: एक ऐसा पैकेट जो NAT से बाहर निकलता है और अपने गंतव्य तक पहुँचने के लिए उसी NAT में फिर से प्रवेश करने की आवश्यकता होती है। राउटिंग स्तर में विशेष हैयरपिन सपोर्ट के बिना, पैकेट ड्रॉप हो जाता है।

यह देर से क्यों सामने आता है

प्रोजेक्ट की शुरुआत में, हर आंतरिक सेवा या तो अन्य आंतरिक सेवाओं से प्राइवेट होस्टनेम (internal-api.local) के माध्यम से बात करती थी, या अपने संगठन के पब्लिक सर्विसेस में वापस कॉल नहीं करती थी। हैयरपिन पथ का अस्तित्व ही नहीं था।

फिर एक नया फीचर चाहिए कि सेवा A को api.example.com (एक पब्लिक होस्टनेम) को कॉल करना पड़े। हैयरपिन पथ सक्रिय हो गया। कनेक्शन अस्वीकृत। आउटेज।

समाधान ने लक्षण को ठीक किया (रिज़ॉल्वर को api.example.com का पब्लिक IP के बजाय प्राइवेट IP देने के लिए मजबूर किया)। मूल कारण: एक ही बॉक्स बहुत सारे काम कर रहा था।

Hairpin NAT: packet exits & cannot re-enter the same NAT

आर्किटेक्चरल फोर्क

एक बॉक्स दो बन जाता है

सफ़ाई से ठीक करने का तरीका: प्रॉक्सी को दो अलग-अलग मशीनों में अलग करें।

इंग्रेस सर्वर (सार्वजनिक IP 203.0.113.5):

- पोर्ट 80, 443 पर Caddy / रिवर्स प्रॉक्सी

- सार्वजनिक DNS रिकॉर्ड यहीं इंगित करते हैं

- api.example.com, app.example.com आदि होस्ट करता है

एग्रेस सर्वर (अलग सार्वजनिक IP 203.0.113.99):

- पोर्ट 1080 पर SOCKS5 / फॉरवर्ड प्रॉक्सी

- फायरवॉल आंतरिक सबनेट IP तक आने वाली कनेक्शन को सीमित करता है

- आंतरिक सेवाएं सभी आउटबाउंड ट्रैफ़िक को इस पता के माध्यम से राउट करती हैं

इससे क्या लाभ होता है:

1. हेयरपिन का समाधान। एक आंतरिक सेवा api.example.com को कॉल करने पर आउटबाउंड ट्रैफ़िक 203.0.113.99 (इग्रेस) के माध्यम से राउट होता है, जो फिर 203.0.113.5 (इंग्रेस, एक अलग IP) से सामान्य रूप से कनेक्ट होता है। चूंकि दोनों IP अलग-अलग मशीनों पर स्थित हैं, इसलिए NAT लूप गायब हो जाता है।

2. सुरक्षा अलगाव। इग्रेस सर्वर का फायरवॉल एक छोटे से आंतरिक IP समूह तक सीमित कर दिया जा सकता है। इंग्रेस सर्वर का फायरवॉल दुनिया के लिए खुला रहता है। दो अलग-अलग रूल सेट, जिनमें से प्रत्येक एक भूमिका को स्पष्ट रूप से व्यक्त करता है।

3. स्वतंत्र स्केलिंग। इंग्रेस बैंडविड्थ उपयोगकर्ताओं के साथ बढ़ती है; इग्रेस बैंडविड्थ आंतरिक सेवाओं की गतिविधि के साथ बढ़ती है। एक को अपग्रेड करें बिना दूसरे को छुए।

4. विफलता अलगाव। गलत कॉन्फ़िगर किया गया इग्रेस अब सार्वजनिक साइट को तोड़ता नहीं है। सार्वजनिक साइट के खिलाफ DDoS अब इग्रेस बैंडविड्थ को भूखा नहीं छोड़ता।

5. स्पष्ट मानसिक मॉडल। प्रत्येक मशीन का एक ही काम है। इंजीनियर इग्रेस के बारे में सोचने के बिना इंग्रेस की चिंताओं के बारे में सोचते हैं, और इसके विपरीत।

स्प्लिट के बाद, एक आंतरिक सेवा को अभी भी `api.example.com` को कॉल करने की आवश्यकता है। आंतरिक सेवा से API बैकएंड तक नए पैकेट पथ के माध्यम से चलें। शामिल करें: आंतरिक सेवा सबसे पहले किस IP से कनेक्ट होती है, वह मशीन अनुरोध के साथ क्या करती है, इसे अगला किस IP पर भेजा जाता है, और प्रतिक्रिया कहाँ जाती है।

दो अक्ष, दो साइज़िंग निर्णय

स्वतंत्र स्केलिंग

विभाजन से पहले, किसी भी दिशा में वृद्धि ने उसी मशीन पर दबाव डाला। विभाजन के बाद, प्रत्येक दिशा का अपना-अपना प्रोविज़निंग (provisioning) है।

इंग्रेस साइज़िंग: उपयोगकर्ताओं के साथ बढ़ती है। क्षमता के निर्णय सार्वजनिक-मुखी तह (public-facing tier) में रहते हैं (अधिक रिवर्स प्रॉक्सी रिप्लिका, बड़ी VMs, सामने CDN)। शिखर पर उपयोगकर्ता ट्रैफिक के विरुद्ध बैंडविड्थ बजट की गणना की जाती है।

एग्रेस साइज़िंग: आंतरिक सेवा-से-बाहरी API कॉल वॉल्यूम के साथ बढ़ती है। अक्सर इसका प्रभुत्व वेबहुक डिलीवरी, पेमेंट प्रोसेसर कॉल, या तीसरे पक्ष की डेटा फेच (third-party data fetches) होता है। आंतरिक कॉल पैटर्न के विरुद्ध बैंडविड्थ बजट की गणना की जाती है।

फेलियर आइसोलेशन: सार्वजनिक इंग्रेस के विरुद्ध DDoS अब एग्रेस बैंडविड्थ को खाता नहीं है (उन पेमेंट प्रोसेसर कॉल आगे भी चलते रहते हैं)। एग्रेस प्रॉक्सी क्रैश अब सार्वजनिक साइट को गिराता नहीं है (उपयोगकर्ता साइट तक पहुंचते रहते हैं; केवल आंतरिक आउटबाउंड कॉल विफल होते हैं)।

अलग SLOs: इंग्रेस उपलब्धता उपयोगकर्ताओं के लिए महत्वपूर्ण है (दृश्य साइट आउटेज); एग्रेस उपलब्धता ऑपरेटर्स के लिए महत्वपूर्ण है (बैकग्राउंड विफलताएं जो पकड़ने में अधिक समय ले सकती हैं)। प्रत्येक पक्ष अपने स्वयं के SLO को संभाल सकता है।

कई एग्रेस सर्वर

एक बार एग्रेस भूमिका अपनी अलग मशीन बनने के बाद, अगला स्पष्ट कदम HA के लिए लोड बैलेंसर के पीछे कई एग्रेस मशीनों को चलाना है। प्रत्येक नई आंतरिक सेवा एकल IP के बजाय एग्रेस होस्टनेम (जो लोड-बैलेंस्ड पूल के लिए रिज़ॉल्व होती है) की ओर इशारा करती है।

वितरित प्रणालियों (distributed systems) के बाकी हिस्सों के समान पाठ: एक बार जब कोई टियर (tier) स्टेटलेस (stateless) हो जाता है और उसका अपना भूमिका होती है, तो वह सस्ती कीमत पर गुणा (multiply) हो सकता है।

एक नया पार्टनर इंटीग्रेशन

आपकी संस्था डिज़ाइन के अनुसार इंग्रेस/एग्रेस (ingress/egress) स्प्लिट चलाती है। एग्रेस सर्वर का एक निश्दत सार्वजनिक IP (203.0.113.99) है, जिसे आपने तीन मौजूदा पार्टनर API (भुगतान प्रोसेसर, SMS गेटवे, ईमेल प्रोवाइडर) के साथ एलाउलिस्ट (allowlisted) किया है।

एक प्रोडक्ट टीम चौथे इंटीग्रेशन को जोड़ना चाहती है: एक वेबहुक डिलीवरी सिस्टम, जो दुनिया भर के ग्राहक एंडपॉइंट्स (endpoints) में कॉलबैक करता है। वॉल्यूम पूर्वानुमान: प्रति मिनट 10,000 कॉल, और 30,000 तक बर्स्ट (bursts)।

निर्णय लें: क्या यह नया इंटीग्रेशन मौजूदा एग्रेस सर्वर पर होना चाहिए, या इसके लिए एक अलग एग्रेस पथ की आवश्यकता है? बैंडविड्थ, फेलियर आइसोलेशन (failure isolation), और इस बात पर विचार करें कि मौजूदा पार्टनर एलाउलिस्ट (allowlists) को किसी भी स्थिति में अपडेट करने की आवश्यकता है या नहीं।

एक बढ़ते हुए सर्विस के लिए नेटवर्क बाउंड्री डिज़ाइन करें

संश्लेषण

आपने सीखा है कि इनग्रेस और एग्रेस के लिए अलग-अलग टूल्स की क्यों आवश्यकता होती है, वास्तविक फ्लीट्स में स्प्लिट को जबरदस्ती करने वाला हैयरपिन NAT फेलियर, और एक बार स्प्लिट लागू होने के बाद स्वतंत्र स्केलिंग, सुरक्षा अलगाव, और फेलियर अलगाव कैसे प्राप्त होते हैं।

चारों का प्रयोग करें।

एक मध्यम आकार की SaaS कंपनी अपने उपयोगकर्ताओं के लिए तीन प्रोडक्ट सबडोमेन (app, api, admin) चलाती है, साथ ही चार आउटबाउंड इंटीग्रेशन (Stripe, Twilio, SendGrid, और एक कस्टमर-वेबहुक सिस्टम)। आज सब कुछ एक सार्वजनिक IP पर एक ही प्रॉक्सी मशीन के पीछे है। उन्हें यह रिपोर्ट मिली है कि जब आंतरिक सर्विसेस api.example.com को कॉल करने की कोशिश करती हैं, तो अंतराल-बदलते (intermittent) हैयरपिन फेलियर हो रहे हैं। वे एक स्थायी समाधान डिज़ाइन करना चाहते हैं।

इस कंपनी के लिए एक ingress / egress आर्किटेक्चर प्रस्तावित करें। निम्नलिखित पहलुओं को संबोधित करें: कितने मशीनें होंगी, कौन-से IPs कौन-सी भूमिकाओं (roles) को संभालेंगे, प्रत्येक subdomain का DNS कहाँ संकेत (point) करता है, कौन-से outbound integrations एक ही egress path साझा करते हैं (& कौन-से अलग किए जाने चाहिए), और एक विशिष्ट monitoring concern जो पुराने डिज़ाइन में संभव नहीं था, वह नए डिज़ाइन में कैसे सक्षम होता है।

यह कोर्स आगे कहाँ जाता है

आपने अब distributed systems में separation-of-concerns के सबसे साफ़ रिफैक्टर्स में से एक को देखा है: एक बॉक्स दो बन जाता है, प्रत्येक की एक स्पष्ट भूमिका होती है, & प्रणाली के साथ-साथ scaling, security, & failure-isolation के लाभ भी प्राप्त करती है।

अगला पाठ (cs_distsys_failure_modes_and_blast_radius) विफलता-अलगाव (failure-isolation) के तर्क को आगे बढ़ाता है। आप एक सैनिटाइज़्ड DNS-SERVFAIL पोस्टमॉर्टम पढ़ेंगे, कैस्केडिंग विफलता पैटर्न की पहचान करेंगे, और बिना दोषारोपण (blameless) के ऐसे एक्शन आइटम लिखेंगे जो लोगों के बजाय सिस्टम को लक्षित करते हैं।

सहपाठ: geometry_of_ingress_egress_separation इस विभाजन को एक द्विभागीय ग्राफ (bipartite graph) के रूप में पुनर्निर्धारित करता है और कट वर्टेक्स, नेटवर्क विभाजन, और ग्राफ सिद्धांत के द्वारा नेटवर्क सीमा के बारे में क्या बताता है, इसका अन्वेषण करता है।

बहुत अच्छा। आगे बढ़िए।