strongSwan मा पूर्ण टनेलका लागि दुवैतिर 0.0.0.0/0 आवश्यक

एउटा निजी सबनेटका लागि काम गर्ने strongSwan जडानले कसैले एउटा लाइन सम्पादन गरेको भरमा इन्टरनेट ट्राफिक बोक्ने छैन। पूर्ण टनेल भनेको child SA ले कुन ठेगानाहरू सुरक्षित गर्छ भन्ने बारे दुई पक्षबीचको सहमति हो, र प्रत्येक पक्षले अर्को पक्षलाई आफ्नै सन्दर्भमा नाम दिन्छ। एउटा पक्ष ठीक र अर्को गलत बनाउनुहोस्, child SA या त उठ्दैन या अपेक्षाभन्दा साँघुरो उठ्छ। तलका पाँच जाँचले त्यो सहमतिलाई क्लाइन्टबाट गेटवे हुँदै इन्टरनेटसम्म पछ्याउँछन्।

पहिले क्लाइन्टको सिलेक्टर जाँच गर्नुहोस्

क्लाइन्टले टाढाको तर्फ के सुरक्षित गर्न चाहन्छ त्यसलाई remote_ts का रूपमा वर्णन गर्छ, र उसले पठाउने सबै आफ्नै तोकिएको ठेगानाबाट जान्छ। इन्टरनेट ट्राफिकका लागि त्यो मानले प्रयोगकर्ताले वास्तवमै पुग्ने गन्तव्यहरू समेट्नुपर्छ, जसको व्यवहारमा अर्थ सम्पूर्ण IPv4 क्षेत्र हो। अझै एउटा सबनेट सूचीबद्ध गर्ने क्लाइन्टले इन्टरफेसमा प्रोफाइलको नाम जे भए पनि विभाजित टनेल मागिरहेको छ। स्रोत पक्ष सामान्यतया dynamic हुन्छ किनभने ठेगाना जडान हुँदा तोकिन्छ। त्यहाँ लेखिएको स्थिर स्रोत ठेगाना समूह बदलिएपछि बिग्रन्छ।

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

यो अंश पूर्ण जडान फाइल होइन, र यसले प्रमाणीकरण, पहिचान र भर्चुअल ठेगाना समूह पहिले नै कन्फिगर भइसकेको मान्छ। क्लाइन्टको स्रोत सिलेक्टर र सर्भरले तोक्ने ठेगाना अझै मिल्नुपर्छ, नत्र child SA कुनै पक्षले अपेक्षा नगरेको दायरासँग उठ्छ। यसलाई swanctl --load-all ले लोड गर्नुहोस् र सफलता मान्नुअघि आउटपुट पढ्नुहोस्। पार्स हुने फाइल पनि अर्को पक्षको प्रस्तावसँग नमिल्ने सिलेक्टरका कारण अस्वीकार हुन सक्छ।

गेटवेको सिलेक्टर उसको आफ्नै तर्फ जाँच गर्नुहोस्

गेटवेले त्यही अवधारणा विपरीत दिशाबाट पढ्छ। इन्टरनेट गन्तव्यहरू गेटवेका लागि स्थानीय हुन्छन्, त्यसैले उसको local_ts फराकिलो हो र remote_ts ले क्लाइन्ट समूह वर्णन गर्छ। यो उल्टाइ नै पूर्ण-टनेल कन्फिगरेसनमा सबैभन्दा सामान्य गल्ती हो, र दुवै लाइन अलग-अलग विश्वसनीय देखिने भएकाले यो समीक्षा पार गर्छ।

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

क्लाइन्टको अंश गेटवे फाइलमा प्रतिलिपि गर्दा उपयोगी केही पनि वर्णन नगर्ने सिलेक्टर जोडी बन्छ, किनभने दुवै पक्षले एउटै भूमिका दाबी गर्नेछन्। strongSwan फर्वार्डिङ गाइड ले क्लाइन्ट र गेटवेको जोडीलाई स्पष्ट रूपमा अभिलेख गर्छ, र यो असफलतापछि नभई जडान फाइलको छेउमा पढ्न लायक छ। गेटवे फाइललाई remote_ts ले सन्दर्भ गर्ने समूहको परिभाषा पनि चाहिन्छ। नभएको समूहको नाम लिने सिलेक्टर उजुरीबिना लोड हुन्छ र जडान गर्दा असफल हुन्छ।

पुरानो ipsec.conf ले फरक कुञ्जीसँग देब्रे र दाहिने भूमिका प्रयोग गर्छ, र rightsubnet लाइन swanctl मानको सीधा प्रतिस्थापन होइन। दुई वाक्यरचनालाई एउटालाई अर्कोमा टाँस्नुको सट्टा छुट्टाछुट्टै फाइलमा राख्नुहोस्। तिनलाई एउटै डाइरेक्टरीमा मिसाउनु नै चलिरहेको जडान रिबुटपछि चुपचाप पछाडि फर्कने बाटो हो।

फाइल होइन, वार्ता गरिएको child SA जाँच गर्नुहोस्

सुरक्षित कन्फिगरेसनले मनसाय मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन। अर्को पक्षले मागिएको दायरा साँघुरो बनाउन सक्छ, र त्यसको तलको फाइल बदलियो भरमा विद्यमान child SA प्रतिस्थापित हुँदैन। अरू केही बदल्नुअघि वास्तवमा के स्थापित छ भनी पुष्टि गर्नुहोस्।

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

पहिलो आदेशले डिमनले के लोड गर्‍यो देखाउँछ, दोस्रोले स्थापित child SA हरू देखाउँछ, र तेस्रोले कर्नेलले लागू गर्ने नीतिहरू देखाउँछ। फाइलले 0.0.0.0/0 भन्छ र सूचीले एउटा सबनेट देखाउँछ भने, वार्ताले दायरा साँघुरो बनाएको हो र फाइल फेरि पढ्दा त्यो व्याख्या हुने छैन। child रोक्नुहोस्, फेरि सुरु गर्नुहोस्, र तीनै आउटपुट फेरि तुलना गर्नुहोस्। उही साँघुरो दायरासँग फर्कने child स्थानीय फाइलले होइन, टाढाको पक्षले साँघुरो बनाइरहेको हुन्छ, र त्यो स्थानीय सम्पादन होइन, अर्को प्रशासकसँगको कुराकानी हो।

नीति सूचीमा दुवै दिशा पढ्नुहोस्, किनभने एउटा दिशा स्थापित गरेर अर्को नगर्ने टनेल कन्फिगरेसनको पोशाकमा रहेको राउटिङ समस्या हो। अगाडि र पछाडिका नीतिहरूले उही सिलेक्टर जोडीलाई ऐनाजस्तै नाम दिनुपर्छ, र हराएको ऐना सिलेक्टर पाठमा होइन, डिमन वा प्रस्तावमा खोट हो।

फर्वार्डिङ र फर्कने मार्ग जाँच गर्नुहोस्

सिलेक्टरले ट्राफिकलाई गेटवेसम्म आउन दिन्छ, तर गेटवेलाई त्यो ट्राफिक अगाडि राउट गर्न बाध्य पार्दैन। फर्वार्डिङ सक्षम हुनुपर्छ, फायरवालले प्रवाहलाई अनुमति दिनुपर्छ, र जवाफले क्लाइन्ट समूहसम्म फर्कने बाटो भेट्नुपर्छ। यी तीन अलग आवश्यकता हुन्, र प्रत्येक फरक लक्षणसँग असफल हुन्छ। हराएको फर्वार्ड नियम कालो प्वालजस्तै व्यवहार गर्छ, जबकि हराएको फर्कने मार्ग एकतर्फी टनेलजस्तै।

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

निजी क्लाइन्ट ठेगानालाई सार्वजनिक इन्टरफेस छोड्नुअघि सामान्यतया जानाजान स्रोत अनुवाद चाहिन्छ, जबकि स्पष्ट रूपमा राउट गरिएको बाँडफाँटलाई अर्कै व्यवहार चाहिन्छ। NAT संलग्न भएमा, कार्यान्वयनले समर्थन गर्ने अपवादहरू राख्नुहोस् ताकि सुरक्षा नीतिले जाँच्नुपर्ने ट्राफिक यसलाई छल्दै अनुवाद नहोस्। अर्को गेटवेबाट प्रतिलिपि गरिएको फराकिलो masquerade नियमले लेखकले सोचेभन्दा धेरै प्रवाह बदल्छ। नियम क्लाइन्ट समूहका लागि मात्र लेख्नुहोस्, र यो किन छ भनी बताउने टिप्पणी छोड्नुहोस्।

क्लाइन्टमा तपाईंले अनुमान गरेका मार्गहरू होइन, ब्याकएन्डले स्थापित गरेका मार्गहरू पुष्टि गर्नुहोस्। मार्ग स्थापना बन्द भएको म्यानेजरलाई हातले सम्हालिएको राउटिङ डिजाइन चाहिन्छ, र टनेल बदलिएपछि त्यो डिजाइन अद्यावधिक गर्नुपर्छ। फेरि जोडिएपछि राउटिङ तालिका जाँच गर्नुहोस्, नयाँ बुटपछि मात्र होइन।

टनेलले अझै के समेट्दैन त्यो जाँच गर्नुहोस्

सिलेक्टर जोडीले IPv4 मात्र समेट्छ, अरू केही होइन। IPv6, DNS र कुनै पनि अनुप्रयोग-स्तरीय नीति अलग निर्णय हुन्, जसलाई फराकिलो IPv4 सिलेक्टरले चुपचाप बेवास्ता गर्छ। हरेक IPv4 प्याकेट बोक्ने टनेलले पनि हरेक नाम खोजी चुहाउन सक्छ।

इच्छित DNS मार्ग स्पष्ट रूपमा भन्नुहोस्, किनभने स्थानीय रिजोल्भरमार्फत नामहरू समाधान गर्ने पूर्ण टनेलले प्रश्नहरू टनेलबाहिर चुहाउँछ र निजी नामहरू बिगार्छ। क्लाइन्टलाई IPv6 ठेगाना तोकिएमा त्यो ठेगाना परिवारलाई पनि उही व्यवहार चाहिन्छ, नत्र होस्टले टनेलले सुरक्षित नगर्ने मार्गलाई प्राथमिकता दिन्छ। निजी पक्षले मात्र जवाफ दिन सक्ने नामसँग परीक्षण गर्नुहोस्, र सार्वजनिक जवाफलाई चुहावट मान्नुहोस्।

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

माथिको सूचीबाट वार्ता गरिएका सिलेक्टरसहित ती दुई आदेशले शृंखला पुष्टि गर्नुहोस्। traceroute ले स्थानीय राउटरलाई पहिलो हप देखाउँछ भने, सिलेक्टरले जे दाबी गरे पनि ट्राफिकले टनेल प्रयोग गरिरहेको छैन। इन्टरनेट पहुँच तब मात्र पूर्ण हुन्छ जब छानिएको ट्राफिक डिजाइन गरिएको गेटवेबाट स्वीकार, फर्वार्ड र फर्काइन्छ। प्रोफाइलमा 0.0.0.0/0 भेट्नु त्यो शृंखलाको सुरुवात हो, प्रमाण होइन।