Linux VPN क्लाइंट को पुराने उपकरण के प्रोटोकॉल से मिलाएँ
उपकरण के प्रकाशित पोर्ट पढ़ें, फिर वह क्लाइंट इंस्टॉल करें जो फिट बैठता है: GRE पर pppd, IKEv1 XAuth के लिए strongSwan, या पोर्टल के लिए openconnect.
चार प्रोटोकॉल परिवार अब भी रैक में पड़े लगभग हर उपकरण को कवर करते हैं, और Linux पर हर एक अलग तरह से विफल होता है। दूर के सिरे के प्रकाशित पोर्ट और कॉन्फ़िगर किए गए प्रस्ताव आपका पैकेज तय करते हैं, वह डिस्ट्रीब्यूशन नहीं जो संयोग से आप चला रहे हैं। फ़ोरम की पोस्ट में जो लिखा है उसे इंस्टॉल करके तब तक संपादित करना जब तक कुछ कनेक्ट न हो — इसी तरह एक दोपहर खो जाती है। उपकरण पढ़ें, दूसरे में इंस्टॉल करें, तीसरे में जाँचें।
दूर का सिरा क्या प्रकाशित करता है, यह दर्ज करें
पैकेज मैनेजर खोलने से पहले वह प्रोटोकॉल, पोर्ट और प्रमाणीकरण लिख लें जिसकी उपकरण अपेक्षा करता है। चार परिवार अधिकांश पुराने उपकरण कवर करते हैं, और नीचे की तालिका एक ही स्क्रीन पर पूरा निर्णय है।
| Family | Ports | Linux side |
|---|---|---|
| PPTP | TCP 1723 plus GRE, IP protocol 47 | pppd with a peer file |
| L2TP/IPsec | UDP 500, 4500, 1701 | NetworkManager plugin over strongSwan |
| IKEv1 aggressive with XAuth | UDP 500 | native strongSwan connection |
| AnyConnect-style portal | TCP 443 | openconnect with a TUN device |
उपकरण का मैनुअल और उसके अपने फ़ायरवॉल नियम उसके लॉगिन पृष्ठ पर लिखे प्रोटोकॉल नाम से अधिक भरोसेमंद हैं। IPsec का प्रचार करने वाला उपकरण शायद केवल IKEv1 बोलता हो, और कोई फ़र्मवेयर रिलीज़ जिसे किसी ने लागू नहीं किया वही हो सकती है जो अंततः IKEv2 जोड़े। डेटा पथ और सेटअप पोर्ट दोनों की पुष्टि करें, क्योंकि यहीं पुराने उपकरण और आधुनिक नेटवर्क अलग होते हैं। इस चरण में गलती का अर्थ है अपने क्लाइंट को ऐसी सुविधा के विरुद्ध डीबग करना जो दूसरे सिरे के पास कभी नहीं थी।
PPTP: pppd संपादित करने से पहले GRE सिद्ध करें
Linux पर PPTP कोई डेमॉन नहीं जिसे आप शुरू करते हैं, बल्कि pppd का आह्वान है, और कनेक्शन पैरामीटर एक नामित peer फ़ाइल में रहते हैं जिसे pppd बुलाए जाने पर पढ़ता है। डिस्ट्रीब्यूशन इसे अब भी पैकेज करते हैं, हालाँकि प्रोटोकॉल की ज्ञात कमज़ोरियाँ इसे किसी भी संवेदनशील चीज़ के लिए अनुपयुक्त बनाती हैं, इसलिए इसे केवल ऐसे उपकरण के लिए कड़ाई से रखें जो और कुछ न देता हो। क्लाइंट के बातचीत करते समय GRE पर नज़र रखें, अनुमान के बजाय छोटे कैप्चर से। सबसे अधिक समय बर्बाद करने वाली विफलता प्रमाणीकरण नहीं, बल्कि गायब डेटा पथ है।
pppd call branch-office
tcpdump -ni any proto gre -c 5
अगर सेटअप पूरा हो जाए और लिंक कभी ट्रैफ़िक न ढोए, तो क्रेडेंशियल छूने से पहले GRE पथ पर संदेह करें। क्लाउड सुरक्षा समूहों को प्रोटोकॉल 47 के लिए स्पष्ट नियम चाहिए, और कुछ नेटवर्क इसे बिना किसी दिखाई देने वाली त्रुटि के पूरी तरह अवरुद्ध कर देते हैं। उस नेटवर्क से परीक्षण करें जिसे आप वास्तव में उपयोग करेंगे, ऐसी प्रयोगशाला से नहीं जो सब कुछ अनुमत करती है।
L2TP/IPsec: एक मेल खाता प्रस्ताव दस प्रयासों को हराता है
डेस्कटॉप संवाद के बजाय डेमॉन लॉग पढ़ें, क्योंकि संवाद कई अलग विफलताओं को एक संदेश में समेट देता है। NO_PROPOSAL_CHOSEN त्रुटि पहले चरण की है: क्लाइंट ने ऐसा एन्क्रिप्शन, हैश या Diffie-Hellman समूह प्रस्तावित किया जिसे सर्वर स्वीकार नहीं करेगा। सूची बनाएँ कि उपकरण क्या समर्थन करता है और उससे मेल खाता एक प्रस्ताव लिखें, क्योंकि यादृच्छिक संयोजन अधिकतर वही त्रुटि धीमे उत्पन्न करते हैं। डेस्कटॉप पर व्यावहारिक क्लाइंट NetworkManager L2TP प्लगइन है, जिसके नीचे strongSwan या Libreswan होता है।
ऐसा प्रस्ताव स्ट्रिंग जिसका अर्थ डेस्कटॉप प्लगइन के लिए एक है, उस डेमॉन के लिए कुछ और हो सकता है जिसे वह काम सौंपता है, इसलिए जिस परत को आप संपादित कर रहे हैं उसके अनुरूप वाक्यविन्यास रखें। अगर उपकरण टनल रहस्य भी माँगता है, तो वह IPsec कुंजी से अलग चरण है। कुछ भी टाइप करने से पहले पुष्टि करें कि इंटरफ़ेस किसमें से कौन-सा माँग रहा है।
XAuth के साथ आक्रामक IKEv1, और पोर्टल का मामला
FortiGate शैली का एंडपॉइंट आमतौर पर चाहता है XAuth के साथ आक्रामक मोड और कॉन्फ़िगर-मोड पता, जिसे ग्राफ़िकल प्लगइन शायद बिल्कुल न दिखाए। मूल डेमॉन इसे संभालता है, और नीचे का ब्लॉक पूरी फ़ाइल नहीं बल्कि उस कॉन्फ़िगरेशन का स्वरूप है। प्रस्ताव मानों के लिए विक्रेता का ताज़ा दस्तावेज़ देखें।
conn branch
keyexchange=ikev1
aggressive=yes
leftauth=psk
leftauth2=xauth
leftsourceip=%config
right=203.0.113.10
strongSwan के पुराने संस्करण xauth=client का उपयोग करते थे जहाँ संस्करण 5 leftauth2=xauth का उपयोग करता है, इसलिए कॉपी किया गया स्निपेट केवल वाक्यविन्यास पर विफल हो सकता है। TLS पोर्टल के लिए, AnyConnect प्रोटोकॉल बोलने वाला openconnect Cisco और अधिकांश पुनः-ब्रांडेड उत्पादों को संभालता है, और इसे TUN उपकरण तथा उसे कॉन्फ़िगर करने के अधिकार चाहिए। पोर्टल का पता ठीक वैसे ही दें जैसे ब्राउज़र दिखाता है, उपकरण द्वारा अपेक्षित किसी भी पथ सहित, फिर उसके पीछे कुछ भी जाँचने से पहले आवंटित पता देखें। इंटरफ़ेस पहले से बनाना सेटअप के दौरान एक प्रकार का आश्चर्य हटा देता है।
sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com
कनेक्ट करें, फिर निश्चित क्रम में जाँचें
एक समय में ठीक एक VPN मैनेजर चलाएँ, क्योंकि NetworkManager प्रोफ़ाइल और हाथ से शुरू किया गया डेमॉन रूट और DNS पर लड़ेंगे। मैन्युअल कनेक्शन जाँचने से पहले प्रोफ़ाइल नीचे करें, और पुष्टि करें कि कोई पुराना टनल इंटरफ़ेस नहीं बचा। फिर इस क्रम में जाँचें: टनल पता, उस एकमात्र आंतरिक होस्ट का रूट जिसकी आपको आवश्यकता है, नाम विश्लेषण, और अंत में वास्तविक अनुरोध। हरा आइकन प्रमाणीकरण सिद्ध करता है और कुछ नहीं।
ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal
अगर कोई चरण विफल हो, तो अगला जाँचने के बजाय वहीं रुकें, क्योंकि टूटे रूट के नीचे की ओर DNS विफलता आपको कुछ नहीं सिखाती। प्रयोग करने से पहले काम कर रही प्रोफ़ाइल की प्रति सहेजें, क्योंकि मिटाई गई कनेक्शन फ़ाइल खोना आसान है और फिर से बनाना थकाऊ। प्रस्ताव मानों को उसी नोट में रखें जिसमें उपकरण का मॉडल और फ़र्मवेयर संस्करण हो, क्योंकि बक्सा बदलने पर वही नोट माइग्रेशन और पुरातत्व परियोजना के बीच का अंतर है।