चार प्रोटोकॉल कुटुंबे रॅकमध्ये अजून उभी असलेली जवळपास प्रत्येक उपकरणे व्यापतात, आणि प्रत्येक Linux वर वेगळ्या पद्धतीने अयशस्वी होते. आपल्याला कोणते पॅकेज हवे हे दूरच्या टोकाने प्रकाशित केलेले पोर्ट आणि संरचित प्रस्ताव ठरवतात, आपण योगायोगाने चालवत असलेले वितरण नाही. फोरमच्या पोस्टमध्ये जे लिहिले आहे ते इन्स्टॉल करून नंतर काहीतरी जोडले जाईपर्यंत संपादित करणे — अशाच पद्धतीने एक दुपार जाते. उपकरण वाचा, दुसरे इन्स्टॉल करा, तिसरे पडताळा.

दूरचे टोक काय प्रकाशित करते ते नोंदवा

पॅकेज मॅनेजर उघडण्यापूर्वी उपकरण ज्या प्रोटोकॉल, पोर्ट आणि प्रमाणीकरणाची अपेक्षा करते ते लिहा. चार कुटुंबे जुन्या उपकरणांचा बहुतांश भाग व्यापतात, आणि खालील तक्ता एका स्क्रीनवरील संपूर्ण निर्णय आहे.

FamilyPortsLinux side
PPTPTCP 1723 plus GRE, IP protocol 47pppd with a peer file
L2TP/IPsecUDP 500, 4500, 1701NetworkManager plugin over strongSwan
IKEv1 aggressive with XAuthUDP 500native strongSwan connection
AnyConnect-style portalTCP 443openconnect with a TUN device

उपकरणाचे मॅन्युअल आणि त्याचे स्वतःचे फायरवॉल नियम त्याच्या लॉगिन पानावरील प्रोटोकॉल नावापेक्षा अधिक विश्वासार्ह आहेत. IPsec ची जाहिरात करणारे उपकरण फक्त IKEv1 बोलू शकते, आणि कोणीही लागू न केलेली फर्मवेअर आवृत्तीच शेवटी IKEv2 जोडणारी असू शकते. डेटा मार्ग आणि सेटअप पोर्ट दोन्ही पडताळा, कारण इथेच जुनी उपकरणे आणि आधुनिक नेटवर्क वेगळी होतात. हा टप्पा चुकवला तर दुसऱ्या टोकाकडे कधीच नसलेल्या वैशिष्ट्याविरुद्ध आपला क्लायंट डीबग करावा लागतो.

PPTP: pppd संपादित करण्यापूर्वी GRE सिद्ध करा

Linux वर PPTP हा आपण सुरू करता तो डेमॉन नाही, तर pppd चा कॉल आहे, आणि कनेक्शनचे मापदंड pppd ला बोलावल्यावर वाचतो त्या नावाच्या peer फाइलमध्ये राहतात. वितरणे ते अजूनही पॅकेज करतात, तरीही प्रोटोकॉलच्या ज्ञात कमकुवतपणांमुळे ते कोणत्याही संवेदनशील गोष्टीसाठी अयोग्य होते, म्हणून ते फक्त असे उपकरणासाठी कडकपणे ठेवा जे दुसरे काही देत नाही. क्लायंट वाटाघाटी करत असताना GRE कडे लक्ष द्या, अंदाजाऐवजी छोट्या कॅप्चरने. सर्वाधिक वेळ वाया घालवणारे अयशस्वी होणे प्रमाणीकरण नाही, तर गहाळ डेटा मार्ग आहे.

pppd call branch-office
tcpdump -ni any proto gre -c 5

सेटअप पूर्ण झाल्यावर दुवा कधीही रहदारी वाहत नसेल, तर क्रेडेन्शियल्सना हात लावण्यापूर्वी GRE मार्गाचा संशय घ्या. क्लाउड सुरक्षा गटांना प्रोटोकॉल 47 साठी स्पष्ट नियम आवश्यक असतो, आणि काही नेटवर्क तो दृश्य त्रुटीशिवाय पूर्णपणे अडवतात. आपण प्रत्यक्षात वापरणार असलेल्या नेटवर्कमधून चाचणी करा, सर्व काही परवानगी देणाऱ्या प्रयोगशाळेतून नाही.

L2TP/IPsec: एक जुळणारा प्रस्ताव दहा प्रयत्नांना हरवतो

डेस्कटॉप संवादाऐवजी डेमॉन लॉग वाचा, कारण संवाद अनेक वेगवेगळ्या अयशस्वीता एका संदेशात एकत्र करतो. NO_PROPOSAL_CHOSEN त्रुटी पहिल्या टप्प्याची आहे: क्लायंटने सर्व्हर स्वीकारणार नाही असे एन्क्रिप्शन, हॅश किंवा Diffie-Hellman गट सुचवले. उपकरण काय समर्थन देते त्याची यादी करा आणि त्याला जुळणारा एक प्रस्ताव लिहा, कारण यादृच्छिक संयोजने बहुतेक वेळा तीच त्रुटी हळू देतात. डेस्कटॉपवर व्यावहारिक क्लायंट म्हणजे खाली strongSwan किंवा Libreswan असलेला NetworkManager L2TP प्लगइन.

डेस्कटॉप प्लगइनसाठी एक अर्थ असलेली प्रस्ताव मालिका ज्या डेमॉनला काम दिले जाते त्याच्यासाठी वेगळा अर्थ असू शकतो, म्हणून आपण संपादित करत असलेल्या स्तराला योग्य अशी वाक्यरचना ठेवा. उपकरणाने टनेल रहस्यही मागितले तर तो 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 अयशस्वी होणे आपल्याला काहीच शिकवत नाही. प्रयोग करण्यापूर्वी कार्यरत प्रोफाइलची प्रत जतन करा, कारण हटवलेली कनेक्शन फाइल हरवणे सोपे आणि पुन्हा तयार करणे कंटाळवाणे आहे. प्रस्तावाची मूल्ये उपकरणाचे मॉडेल आणि फर्मवेअर आवृत्ती यांच्यासोबत त्याच टिपेत ठेवा, कारण बॉक्स बदलला की तीच टीप स्थलांतर आणि पुरातत्त्व प्रकल्प यातील फरक ठरवते.

संबंधित लेख