Linux पर FortiGate IPsec: कौन-सा क्लाइंट वास्तव में जुड़ता है

आपका Windows सहकर्मी FortiGate विज़ार्ड प्रोफ़ाइल आयात करता है और एक मिनट में ऑनलाइन हो जाता है। आप Ubuntu पर वही विक्रेता पैकेज इंस्टॉल करते हैं, IPsec टैब खोजते हैं और ऐसा क्लाइंट पाते हैं जो केवल SSL VPN पोर्टल खोलना जानता है। इसके बाद निकाला गया निष्कर्ष आमतौर पर दो बार गलत होता है: गेटवे आपको अस्वीकार नहीं कर रहा है, और Linux बिल्ड टूटा नहीं है। Fortinet वह क्लाइंट केवल SSL VPN समर्थन के साथ भेजता है, इसलिए मोबाइल IPsec प्रोफ़ाइल के रहने की जगह नहीं है और उसे वहाँ फिर से बनाना पड़ता है जहाँ IKEv1 बोला जाता है।

पहले तय करें कि आपको वास्तव में कौन-सा प्रोटोकॉल दिया गया है

यह पुनर्निर्माण यांत्रिक है, जैसे ही आप विक्रेता क्लाइंट को संदर्भ कार्यान्वयन मानना छोड़ देते हैं।

FortiGate डिवाइस SSL VPN और IPsec दोनों प्रकाशित करते हैं, और हैंडओवर ईमेल शायद ही बताता है कि आपको कौन-सा दिया गया। पोर्टल URL के साथ ब्राउज़र-शैली का लॉगिन पेज SSL VPN का अर्थ है, और Linux पर वहाँ उत्तर openfortivpn है, नीचे दिया फ़ील्ड मैपिंग नहीं। समूह पहचानकर्ता के साथ पूर्व-साझा कुंजी का अर्थ मोबाइल IPsec है, जिसे vpnc और strongSwan संभालते हैं।

इसमें गलती करना Linux प्रयास के पहले चरण के पूरा होने से पहले मरने का सबसे आम कारण है: क्लाइंट HTTPS पोर्टल को IKEv1 प्रस्तावित कर रहा है या इसका उल्टा. कुछ भी इंस्टॉल करने से पहले व्यवस्थापक से प्रोटोकॉल का नाम लिखित में मांगें।

चार क्रेडेंशियल चार अलग-अलग फ़ील्ड में यात्रा करते हैं

password शब्द अधिकांश हैंडओवर में दो बार आता है और दो अलग बातों का अर्थ रखता है। पूर्व-साझा कुंजी स्वयं पीयर को प्रमाणित करती है, और यह एक मशीन रहस्य है जिसे व्यवस्थापक गेटवे कॉन्फ़िगरेशन से पढ़ता है। आपका खाता पासवर्ड एक अलग क्रेडेंशियल है जो साबित करता है कि उस पीयर के पीछे कौन-सा मनुष्य है।

बाकी दो मान चूकना आसान है। समूह पहचानकर्ता वह स्ट्रिंग है जो विज़ार्ड ने IPsec समूह ऑब्जेक्ट में लिखी थी, और 0 एक वैध मान है, खाली फ़ील्ड नहीं। प्रस्ताव में हर चरण के लिए एन्क्रिप्शन, हैशिंग और Diffie-Hellman समूह के साथ PFS सेटिंग शामिल है, और उसका हर मद गेटवे से मेल खाना चाहिए। जब कोई कनेक्शन चरण 1 पर विफल होता है, तो लगभग हमेशा उन चार में से एक दोषी होता है, इसलिए उन्हें एक ही संवाद में डालने के बजाय अलग-अलग लिखें।

हर vpnc फ़ील्ड में क्या होना चाहिए

क्लाइंट को एडिटर फ़्रंट-एंड के साथ इंस्टॉल करें, फिर VPNC कनेक्शन बनाएँ:

sudo apt install vpnc network-manager-vpnc network-manager-vpnc-gnome

गेटवे को FortiGate के सार्वजनिक पते पर सेट करें, और समूह नाम को ठीक गेटवे के पहचानकर्ता पर सेट करें, जिसमें नंगला शून्य भी शामिल है। Group password पूर्व-साझा कुंजी लेता है, जबकि उपयोगकर्ता नाम और पासवर्ड आपका खाता लेते हैं, कोई भी टोकन गेटवे की अपेक्षा के अनुसार जोड़कर। उन्नत संवाद में, प्रस्ताव में नामित Diffie-Hellman समूह चुनें, PFS को उसी समूह से मिलाएँ, क्लाइंट घरेलू राउटर के पीछे होने पर NAT ट्रैवर्सल सक्षम करें, और डेड पीयर डिटेक्शन को गेटवे के साथ एक ही कदम पर रखें।

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

वही प्रोफ़ाइल strongSwan के लिए लिखी गई

इन मानों के लिए strongSwan बेहतर दीर्घकालिक पात्र है, क्योंकि कॉन्फ़िगरेशन एक टेक्स्ट फ़ाइल है जिसे आप देख सकते हैं और रख सकते हैं:

conn office-fw
    keyexchange=ikev1
    aggressive=yes
    left=%any
    leftauth=psk
    leftauth2=xauth
    xauth_identity=YOUR_USER
    right=GATEWAY_ADDRESS
    rightauth=psk
    rightsubnet=OFFICE_SUBNET
    ike=aes128-sha1-modp1536!
    esp=aes128-sha1-modp1536!

ब्लॉक से पहले प्रस्ताव की पंक्तियाँ पढ़ें, क्योंकि अंत में लगा विस्मयादिबोधक चिह्न उनका अर्थ बदल देता है: यह उसी एक प्रस्ताव को पिन करता है और उन विकल्पों को हटा देता है जो क्लाइंट अन्यथा देता। एक ही ट्रांसफ़ॉर्म जोड़ी के लिए कॉन्फ़िगर गेटवे सूची के साथ खुलने वाले क्लाइंट को अस्वीकार करेगा, इसलिए पिनिंग ही बातचीत को मिलान में बदलती है. काम करने वाले गेटवे प्रोफ़ाइल से एल्गोरिदम के सटीक नाम लें, और प्लेसहोल्डर को अपने मानों से बदलें।

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

दूसरा फ़ील्ड बदलने से पहले विफलता पढ़ें

संवाद को फिर से यादृच्छिक बनाने के बजाय लक्षण से पीछे की ओर काम करें। बिना आवंटित पते के ऊपर आने वाला IKE SA का अर्थ है कि उपयोगकर्ता प्रमाणीकरण का आदान-प्रदान विफल हुआ या कभी चला ही नहीं, इसलिए खाता और टोकन प्रबंधन जाँचें। कभी पूरा न होने वाला चरण 1 प्रस्ताव, समूह पहचानकर्ता या आक्रामक मोड की ओर इशारा करता है, और उनमें से हर एक की तुलना गेटवे से होती है, केवल Windows क्लाइंट से नहीं।

जो टनल बनता है और फिर हर कुछ मिनट में मर जाता है, वह दोनों सिरों के बीच डेड पीयर डिटेक्शन का मतभेद है; हर जगह keepalive बंद करने के बजाय गेटवे का टाइमर मिलाएँ। स्थापित टनल में अगर ऑफ़िस के होस्ट अप्राप्य रहते हैं, तो आमतौर पर इसका अर्थ है कि धकेला गया सबनेट कभी स्थानीय रूटिंग तालिका में नहीं पहुँचा, जो तीसरे पक्ष का क्लाइंट शायद स्वयं न करे।

काम पूरा होने पर काम करने वाले मान गेटवे के मालिक को लौटाएँ: प्रोटोकॉल, समूह पहचानकर्ता, पूर्व-साझा कुंजी, प्रस्ताव, PFS और DPD निर्णय। तब अगली Linux मशीन पूरी शाम के बजाय कुछ मिनट लेगी, और किसी को यह फिर से खोजना नहीं पड़ेगा कि समूह का नाम शून्य था।