Tailscale सबनेट SNAT बंद करने के बाद एकतरफ़ा ट्रैफ़िक

Tailscale सबनेट राउटर पर स्रोत NAT बंद करें, सुरंग काम करती रहती है जबकि उससे गुज़रने वाले कनेक्शन रुक जाते हैं। अनुरोध गंतव्य तक दूरस्थ क्लाइंट के अपने ओवरले पते के साथ पहुँचते हैं, जो बदलाव का उद्देश्य ही है, और जवाबों को अब ऐसा रास्ता चाहिए जो LAN को कभी जानना नहीं था। उस रास्ते के बिना पैकेट उतरते हैं, जवाब सामान्य गेटवे से बाहर जाते हैं, और विफलता ऐसी फ़ायरवॉल समस्या दिखती है जिसे कोई फ़ायरवॉल नियम समझाता नहीं। सुरंग स्वस्थ है; वापसी हिस्सा गायब है।

SNAT क्या छिपा रहा था

SNAT सक्रिय होने पर राउटर सबनेट में भेजने से पहले स्रोत पते को अपने ही LAN पते में बदल देता है, इसलिए गंतव्य ऐसे होस्ट को जवाब देता है जिसे वहाँ पहुँचना पहले से जानता है और कुछ और सेट नहीं करना पड़ता। इसे बंद करने से मूल स्रोत बना रहता है, और गंतव्य फिर अपने तार पर पड़ोसी के बजाय ओवरले श्रेणी के भीतर का पता देखता है। वह पता वास्तविक है और tailnet भर में रूट हो सकता है, पर डिफ़ॉल्ट गेटवे से LAN से उस तक पहुँचा नहीं जा सकता। दस्तावेज़ी स्विच --snat-subnet-routes=false है, जो Linux सबनेट राउटर पर ही लागू होता है।

यह हर पैकेट का टॉगल नहीं बल्कि स्थायी सेटिंग है, इसलिए जिस भी गंतव्य नेटवर्क को वह राउटर सेवा देता है उसके लिए वापसी मार्ग मौजूद होना चाहिए। यही बदलाव को चेकबॉक्स के बजाय परिनियोजन का निर्णय बनाता है। उस राउटर की हर सेवा को यह आवश्यकता उसी पल विरासत में मिलती है।

वापसी मार्ग कहाँ रह सकता है

तीन जगहें आम हैं, और वे शुद्धता में नहीं बल्कि पहुँच में अलग हैं। गंतव्य होस्ट पर स्थिर मार्ग सबसे सीधा और सबसे कम मापनीय है, क्योंकि हर उपकरण को अपनी प्रतिलिपि चाहिए। VPC या साइट राउटर की मार्ग तालिका पूरा नेटवर्क एक साथ ढक लेती है, और वर्गहीन स्थिर मार्ग ले जाने वाला DHCP विकल्प क्लाइंट तक अपने आप पहुँचता है पर उसे अनदेखा करने वाले उपकरणों पर चुपचाप विफल हो जाता है।

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

आप कोई भी जगह चुनें, अगला हॉप राउटर का LAN पता है और कभी उसका tailnet पता नहीं। LAN होस्ट इस मार्ग के बिना ओवरले तक नहीं पहुँच सकता, इसलिए ओवरले के भीतर अगला हॉप चक्रीय है और पैकेट को कहीं नहीं भेजता। यही एक गलती उन ज़्यादातर कॉन्फ़िगरेशन को समझाती है जो सही दिखते हैं और फिर भी विफल होते हैं, और यह केवल राउटर की अपनी तालिका पढ़ने वाली हर जाँच से बच निकलती है। लिख लें कि आपने कौन सी जगह इस्तेमाल की, वरना अगला व्यक्ति गलत वाली जाँचेगा।

विफलता को एकतरफ़ा ट्रैफ़िक के रूप में पढ़ना

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

इसके बजाय राउटर पर कैप्चर करें, क्योंकि वह एक अदला-बदली की दोनों दिशाएँ देखता है और दिखाता है कि जवाब कभी आया या नहीं। यदि जवाब गंतव्य पर दिखता है पर राउटर पर कभी नहीं, तो गंतव्य की ओर मार्ग गायब या गलत है। यदि वह राउटर पर दिखता है और वहीं रुक जाता है, तो समस्या आगे है और किसी और जाँच की है।

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

क्या असली पता एक मार्ग के लायक है

जब भी गंतव्य नेटवर्क को फिर से कॉन्फ़िगर नहीं किया जा सकता, SNAT रखना आसान जवाब रहता है, और कीमत यह है कि हर क्लाइंट गंतव्य के लॉग और नीति में राउटर जैसा दिखता है। इसे बंद करना तब उचित है जब किसी एप्लिकेशन को असली स्रोत पता चाहिए या जब नेटवर्क नीति को राउटर साझा करने वाले क्लाइंट में फ़र्क करना हो। दोनों वैध कारण हैं और कोई भी मुफ़्त नहीं। लाभ को हर गंतव्य नेटवर्क पर मार्ग बनाए रखने के साथ-साथ नीचे बताई गई फ़ायरवॉल समीक्षा के लायक होना चाहिए।

एक छोटे LAN के लिए यह अदला-बदली आम तौर पर फ़ायदेमंद होती है, जबकि स्थिर मार्ग न ले सकने वाले उपकरणों के फैलाव के लिए आम तौर पर नहीं। निर्णय और कारण राउटर कॉन्फ़िगरेशन के पास दर्ज करें, ताकि अगले प्रशासक को पता रहे कि कौन सा व्यवहार जानबूझकर है। जिस डिफ़ॉल्ट को किसी ने नहीं लिखा, उसे लापरवाही से अलग नहीं किया जा सकता।

फ़ायरवॉल, लॉगिंग और दोहरी भूमिका

राउटर के LAN पते से मेल खाने वाला हर नियम अब किसी दूसरे स्रोत से मेल खाता है, और इसमें अनुमति नियम तथा वह हर लॉग फ़ील्ड शामिल है जो राउटर को क्लाइंट के रूप में दर्ज करता था। उन नियमों को पहली जाँच से पहले पढ़ें, पहली विफलता के बाद नहीं, क्योंकि केवल राउटर के पते की अनुमति देने वाला नियम नए स्रोत को पूरी तरह रोक देता है। बदली को उन क्लाइंट और पोर्ट तक सीमित करें जिन्हें इसकी ज़रूरत है, फिर पुष्टि करें कि वह चुपचाप पूरे tailnet को स्वीकार नहीं कर रही।

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

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