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 बंद झाल्यावर अपस्ट्रीम वाहतूक टाकू शकते। त्या भूमिका वेगवेगळ्या नोडवर विभागल्यास ही सूचना जाते आणि प्रत्येक मार्ग व फायरवॉल धोरणाला एकच मालक मिळतो। भूमिका एकत्र ठेवाव्या लागल्यास हे वर्तन अपेक्षित धरा आणि क्लायंटला दोष देण्यापूर्वी त्याची चाचणी करा। मार्ग, स्विच सेटिंग आणि भूमिका वाटप एकाच टिपेत ठेवा, कारण पुढची जोडणी अपयशी झाल्यावर ते एकत्र वाचले जातात।