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 बन्द भएपछि माथिल्लो ट्राफिक खसाल्न सक्छ। ती भूमिकाहरू फरक नोडमा छुट्याउँदा यो चेतावनी हट्छ र प्रत्येक मार्ग र फायरवाल नीतिलाई एउटै मालिक मिल्छ। यदि भूमिकाहरू सँगै रहनैपर्छ भने, यो व्यवहार अपेक्षा गर्नुहोस् र ग्राहकलाई दोष दिनुअघि यसको परीक्षण गर्नुहोस्। मार्ग, स्विच सेटिङ र भूमिका बाँडफाँट एउटै टिप्पणीमा राख्नुहोस्, किनकि अर्को जडान विफल हुँदा ती सँगै पढिन्छन्।