VPN टनेल कहिल्यै जडान हुँदैन: प्याकेटहरू वास्तवमा कहाँ रोकिन्छन्

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

ट्राफिक कहाँ रोकिन्छ प्रमाणित गर्नुहोस्

एकै समयमा क्लाइन्टको आउटबाउन्ड इन्टरफेसमा र सर्भरमा क्याप्चर गर्नुहोस्। गएको कुरालाई आएको कुरासँग तुलना गर्नुहोस्, र भिन्नता कुन दिशामा देखिन्छ नोट गर्नुहोस्।

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

प्रोटोकल 47 बिना PPTP मर्छ

PPTP ले नियन्त्रण TCP 1723 मा र डाटा GRE भित्र बोक्छ, जुन पोर्ट नम्बर नभई IP प्रोटोकल 47 हो। केवल 1723 फर्वार्ड गर्दा परम्परागत नतिजा आउँछ: जडान प्रमाणित हुन्छ र त्यसपछि चुप हुन्छ, किनकि पेलोड बोक्ने प्रोटोकलका लागि कुनै नियम छैन। क्लाइन्टले यसलाई अस्वीकृत पासवर्डबाट छुट्याउन सक्दैन, त्यसैले क्याप्चर कन्फिगरेसन परिवर्तनअघि आउनुपर्छ।

पासथ्रु इनबाउन्ड फर्वार्डको विपरीत दिशामा चल्छ, र फर्मवेयरले दुवैका लागि एउटै लेबल प्रायः प्रयोग गर्छ, जुन सबैलाई अलमल्याउन पर्याप्त छ। Linux क्लाइन्टमा स्थानीय फायरवालले राउटर संलग्न हुनुभन्दा धेरै अघि GRE फाल्न सक्छ, त्यसैले प्रोटोकल 47 लाई आफ्नै नियम चाहिन्छ र conntrack सहायक लोड हुनुपर्छ। Ubuntu को ufw ले यी नियमहरू before फाइलमा राख्छ, किनकि सामान्य allow नियमले प्रोटोकल नम्बर व्यक्त गर्न सक्दैनन्। त्यसपछि मेसिन रिबुट गर्नुको सट्टा फायरवाल पुनः लोड गर्नुहोस्।

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

दुई NAT पछाडि L2TP र IPsec

L2TP IPsec भित्र कुञ्जी साटासाटका लागि UDP 500, NAT पहिचान भएपछि UDP 4500, र प्रोटोकल 50 का रूपमा ESP चाहिन्छ। यीमध्ये प्रत्येक स्वतन्त्र रूपमा फिल्टर हुन्छ, त्यसैले एउटालाई अनुमति दिने नियमले अन्य दुईबारे केही प्रमाणित गर्दैन। शृंखलामा दुई राउटरले प्रत्येक प्याकेट दुई पटक अनुवाद गर्छन्, र छेउहरू के वार्ता भयो भन्नेमा अब सहमत छैनन्।

बाहिरी मोडेम ब्रिज गर्नुहोस्, वा भित्री राउटरमा NAT बन्द गर्नुहोस्, ताकि सार्वजनिक ठेगाना टनेल अन्त्य गर्ने यन्त्रसम्म पुगोस्। दुवै सम्भव नभए, टनेल दोहोरो NAT सीमाभित्रबाट सुरु गर्नुपर्छ, त्यहाँ अन्त्य गर्नु हुँदैन।

क्यारियर सञ्जाल र ठेगाना साझेदारी

WAN ठेगाना 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 वा 100.64.0.0/10 भित्र हुनु भनेको राउटरसँग सार्वजनिक ठेगाना छैन र इन्टरनेटबाट कुनै पनि इनबाउन्ड फर्वार्डले त्यससम्म पुग्न सक्दैन। क्यारियर-ग्रेड NAT ले अपेक्षा नगरेका प्रोटोकलहरू पनि फिल्टर गर्छ, र मोबाइल लिंकमा GRE प्रायः बलि पर्छ। राउटरमै रहेको WAN ठेगानाको तुलना गर्नुहोस्, त्यसको पछाडिको क्लाइन्टका लागि लुकअप साइटले बताउने ठेगानासँग होइन।

त्यही राउटर तार भएको लाइनमा चलाउँदा एउटै परीक्षणमा क्यारियरको निष्कर्ष र कन्फिगरेसन त्रुटि छुट्याइन्छ। क्यारियरले प्रोटोकल अस्वीकार गरे 443 मा अर्को यातायात वा भित्रबाट सुरु गरिएको टनेल बाँकी विकल्प हुन्।

पोर्ट बन्द गर्नु अघि श्रोताहरूको सूची पढ्नुहोस्

चिन्ता लाग्ने पोर्ट स्क्यान प्रायः चालु अवस्थामा आउने सुविधा समूह मात्र हो। श्रोताहरूको सूची बनाउनुहोस्, प्रत्येक सकेटलाई सुविधासँग जोड्नुहोस्, अनि पोर्ट ब्लक गर्नुको सट्टा सुविधा बन्द गर्नुहोस्, ताकि दुई दृश्य अलग नहोऊन्।

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther का पूर्वनिर्धारित मानहरू राम्रो उदाहरण हुन्: TCP 443, 992 र 5555, साथै L2TP/IPsec र DNS-टनेल सुविधाले आफ्नै सकेट थप्छन्। ती सुविधा बन्द गर्दा श्रोताहरू लुकाउने होइन, हट्छन्, र बाहिरी होस्टबाट गरिएको परीक्षणले क्यारियरले पोर्ट पठाउँछ कि भन्ने बताउँछ। स्थानीय रूपमा जवाफ दिने श्रोता माथिल्लो तहमा बन्द हुन सक्छ, त्यसैले राउटरको आफ्नै WAN ठेगानालाई बाहिरी सेवाले बताउनेसँग तुलना गर्नुहोस्।