क्लाउड सीमा पर VPN क्लाइंट के IP सुरक्षित रखें या 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 नहीं है उसके लिए यह आमतौर पर बिलकुल उपलब्ध नहीं होती।

लिखें कि हर सीमा क्या देखती है

आप जो भी चुनें, डिज़ाइन समीक्षा एक ऐसी तालिका के साथ समाप्त होनी चाहिए जो हर हॉप पर स्रोत पता और सिद्ध हो सकने वाली पहचान का नाम बताए। उसके बिना, पहली घटना तीन टीमें बना देती है जो हर एक अलग क्लाइंट का वर्णन करती हैं।

फिर चुनें। स्रोत सुरक्षित रखें जब एप्लिकेशन का प्राधिकरण वास्तव में क्लाइंट पते पर निर्भर हो और आप मार्ग का दायित्व ले सकें। जब ऐसा न हो और आप पहचान को बैंड के बाहर ले जा सकें तो अनुवाद करें, और प्लेटफ़ॉर्म-विशिष्ट अग्रेषण सेटिंग्स के लिए AWS अग्रेषण-इंस्टेंस मार्गदर्शिका का उपयोग करें। जब सेवा HTTP बोलती हो और आप चाहते हों कि पहचान पूरी तरह पता होना छोड़ दे, तो रिले की ओर जाएँ।