VPN मार्ग वा फायरवाल नियम: प्याकेट कुनले छोडिरहेको छ?

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

दुई निर्णय, एउटा प्याकेट, दुई मालिक

मार्ग खोजीले पहिले नीति नियमसँग परामर्श गर्छ, त्यसपछि तिनले देखाउने तालिकासँग, र गन्तव्यसँग मिल्ने सबैभन्दा विशिष्ट प्रिफिक्स छान्छ। टनेल मार्ग स्थापना गरेको क्लाइन्ट त्यो निर्णयको मालिक हो, र फायरवाल नियममा केहीले पनि त्यसको ठाउँ लिन सक्दैन। जब खोजी अप्रत्याशित ठाउँमा देखाउँछ, प्रत्येक पछिल्लो चरण गलत प्याकेटमा काम गर्छ।

फिल्टरिङ अलग छ। Linux होस्टमा netfilter हुकहरूले प्याकेट कसका लागि हो त्यसअनुसार ट्राफिक विभाजन गर्छन्: आउटपुट मेसिन छोड्छ, इनपुट त्यसमा अन्त्य हुन्छ, फर्वार्ड त्यसबाट जान्छ। VPN क्लाइन्ट स्वीकार गरी तिनलाई LAN मा मार्गनिर्देशन गर्ने गेटवेलाई फर्वार्ड मार्ग चाहिन्छ, र अधिकांश डिफल्ट कन्फिगरेसनहरूले खाली छोड्ने त्यही शृंखला हो।

स्रोत छनोट त्यही निर्णयको भाग हो, र त्यहीँ धेरै बेमेलहरू लुकेका हुन्छन्। मार्गले एउटा नतोकेसम्म कर्नेल बाहिर जाने इन्टरफेसबाट स्रोत ठेगाना छान्छ, त्यसैले LAN सबनेटका लागि लेखिएको फिल्टर नियम टनेल ठेगानासँग बाहिर जाने प्याकेटसँग कहिल्यै मिल्दैन।

खोजीले वास्तवमा के छान्यो त्यो पढ्नुहोस्

निर्णय अनुमान नगरी छाप्नुहोस्। तलको आदेशले त्यो गन्तव्यका लागि कर्नेलले प्रयोग गर्ने मार्ग समाधान गर्छ, जसमा इन्टरफेस र त्यसले छान्ने स्रोत समावेश छ:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN क्लाइन्टहरूले प्रायः मुख्य तालिकाभन्दा तलका प्राथमिकतामा नीति नियम स्थापना गर्छन्, त्यसैले सफा मुख्य तालिका आफैंमा केही प्रमाणित गर्दैन। नियमहरूको प्राथमिकतालाई तिनले छान्ने तालिकासँग तुलना गर्नुहोस्, र टनेल मार्ग एक पटक हातले थप्नुको सट्टा पुनः जडानपछि टिक्छ कि भनेर जाँच्नुहोस्।

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

फिल्टरिङ हुकमा लागू हुन्छ, मार्गमा होइन

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

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

क्लाइन्टले प्रयोग गर्ने बाटोबाट प्रोब पठाउनुहोस्

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

प्रत्येक परिवर्तन पुनः जडानपछि टिक्ने ठाउँमा राख्नुहोस्

ip route add ले थपिएको मार्ग इन्टरफेस तल नगएसम्म बाँच्छ। यसलाई जडान प्रोफाइलमा सुरक्षित राख्नुहोस्: NetworkManager ले जडानमा थप मार्ग स्वीकार गर्छ, र netplan ले तिनलाई बुटहरूबीच राख्छ। त्यही नियम क्लाइन्ट-साइड फायरवाल अपवादमा लागू हुन्छ, जो अर्को रिलोडपछि हराउँछ।

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

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