चार प्रोटोकल परिवारले र्‍याकमा अझै रहेको लगभग हरेक उपकरण ढाक्छन्, र प्रत्येक 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 रिलिजहरूले संस्करण 5 ले leftauth2=xauth प्रयोग गर्ने ठाउँमा xauth=client प्रयोग गर्थे, त्यसैले प्रतिलिपि गरिएको स्निपेट वाक्यरचनाकै कारण असफल हुन सक्छ। 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 असफलताले तपाईंलाई केही सिकाउँदैन। प्रयोग गर्नुअघि काम गर्ने प्रोफाइलको प्रतिलिपि सुरक्षित गर्नुहोस्, किनकि मेटिएको जडान फाइल हराउन सजिलो र फेरि बनाउन झन्झटिलो हुन्छ। प्रस्तावका मानहरू उपकरणको मोडेल र फर्मवेयर संस्करणसँगै एउटै नोटमा राख्नुहोस्, किनकि बाकस फेरिँदा त्यही नोटले स्थानान्तरण र पुरातत्व परियोजनाबीचको फरक देखाउँछ।

सम्बन्धित लेखहरू