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 पत्त्याची तुलना बाहेरील सेवा जे सांगते त्याशी करा।