VPN टनल कभी कनेक्ट नहीं होता: पैकेट असल में कहाँ रुकते हैं

जो टनल कभी बनता ही नहीं, वह दोनों सिरों पर खाली लॉग छोड़ता है। जाँचें कि GRE, ESP या UDP 4500 छोड़े जा रहे हैं या नहीं, और सर्वर संपादित करने से पहले कैरियर NAT पहचानें।

क्लाइंट बार-बार फिर कोशिश करता रहता है, हैंडशेक पूरा होने से पहले लॉग रुक जाता है, और सर्वर कुछ भी दर्ज नहीं करता। यह पैटर्न क्रेडेंशियल से दूर रास्ते की ओर इशारा करता है: दोनों सिरों के बीच कुछ ऐसा है जो उस प्रोटोकॉल को ले जाने से इंकार करता है जिसकी टनल को ज़रूरत है। किसी भी कॉन्फ़िगरेशन को छूने से पहले तय करें कि पैकेट कहाँ रुकते हैं, क्योंकि फ़िल्टर किया गया प्रोटोकॉल और गलत पासवर्ड ज़्यादातर क्लाइंट में वही मिलनसार त्रुटि देते हैं। परीक्षण लागत के क्रम में हैं, सबसे सस्ता पहले।

साबित करें कि ट्रैफ़िक कहाँ रुकता है

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

सर्वर पर कुछ न होने का अर्थ है कि रास्ता या पहला NAT ट्रैफ़िक गिरा रहा है, जबकि बिना उत्तर आने वाले आगमन सर्वर पर फ़ायरवॉल या ऐसे रिटर्न रूट की ओर इशारा करते हैं जो मौजूद नहीं है। जो राउटर अक्सर टनल समाप्त करता है, वह अक्सर कोई उपयोगी लॉग नहीं रखता, इसलिए कैप्चर ही रिकॉर्ड बन जाता है। गंतव्य पोर्ट और प्रोटोकॉल संख्या लिख लें, क्योंकि दोनों विफलताएँ क्लाइंट संवाद में एक जैसी दिखती हैं।

प्रोटोकॉल 47 के बिना PPTP मर जाता है

PPTP नियंत्रण TCP 1723 पर और अपना डेटा GRE के अंदर ले जाता है, जो पोर्ट संख्या नहीं बल्कि IP प्रोटोकॉल 47 है। केवल 1723 आगे भेजने से पुराना परिणाम मिलता है: कनेक्शन प्रमाणित होता है और फिर चुप हो जाता है, क्योंकि पेलोड ले जाने वाले प्रोटोकॉल के लिए कोई नियम नहीं है। क्लाइंट इसे अस्वीकृत पासवर्ड से अलग नहीं कर सकता, इसीलिए कैप्चर कॉन्फ़िगरेशन बदलावों से पहले आना चाहिए।

पासथ्रू इनबाउंड फ़ॉरवर्ड की विपरीत दिशा में चलता है, और फ़र्मवेयर अक्सर दोनों के लिए एक ही लेबल इस्तेमाल करता है, जो सबको उलझाने के लिए काफ़ी है। लिनक्स क्लाइंट पर स्थानीय फ़ायरवॉल राउटर के शामिल होने से बहुत पहले GRE गिरा सकता है, इसलिए प्रोटोकॉल 47 को अपना नियम चाहिए और conntrack सहायक लोड होना चाहिए। उबंटू का 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 सीमा के भीतर से शुरू होनी चाहिए, वहाँ समाप्त नहीं।

कैरियर नेटवर्क और पता साझाकरण

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 या 100.64.0.0/10 के भीतर WAN पता होने का अर्थ है कि राउटर के पास कोई सार्वजनिक पता नहीं है और इंटरनेट से कोई इनबाउंड फ़ॉरवर्ड उस तक नहीं पहुँच सकता। कैरियर-ग्रेड 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 पते की तुलना बाहरी सेवा के बताए से करें।

संबंधित लेख