PPTP/MS-CHAPv2 हटाउने: पुरानो VPN का लागि रनबुक

प्रत्येक महिना परिवर्तन गरी तिजोरीमा राखिने बीस अक्षरका पासवर्डले MS-CHAPv2 चलाउने PPTP सर्भरलाई आधुनिक VPN बनाउँदैन। पासवर्ड त्यस्तो आदानप्रदानको इनपुट हो जसको कमजोरी आदानप्रदानमै हुन्छ। यो रनबुक त्यसका लागि हो जसले त्यो सर्भर उत्तराधिकारमा पाएको छ र त्यसमा निर्भर साइट नकाटी प्रयोगकर्ताहरूलाई त्यहाँबाट सार्नुपर्ने छ। चरणहरू क्रममा पूरा गर्नुहोस्, किनकि प्रत्येकले एउटा अभिलेख छोड्छ, जो कसैले पहुँच अचानक किन बदलियो भनी सोध्दा चाहिने हुन्छ।

केही छुनुअघि स्ट्याक लेख्नुहोस्

PPTP शब्दमा तीन तह एकसाथ मिसिन्छन्, र प्रत्येक आफ्नै तरिकाले असफल हुन्छ। सुरुङ PPTP आफैं हो, GRE सहित TCP 1723। प्रमाणीकरण सर्भरले दिने PPP विधि हो, यहाँ MS-CHAPv2। लिङ्क सुरक्षा MPPE हो, जसका कुञ्जीहरू त्यही प्रमाणीकरण आदानप्रदानबाट बन्छन्। तीनैको नाम लिँदा पछिको सुधार गलत तहमा पर्दैन।

विकि पृष्ठमा भर पर्नुको सट्टा जीवित कन्फिगरेसन पढ्नुहोस्, र फाइल, श्रोता तथा प्रमाणित भएका अन्तिम सत्रहरू टिप्नुहोस्।

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

Windows को टाढा पहुँच भूमिकामा त्यही सूची दुई आदेशबाट आउँछ, र दोस्रो महत्त्वपूर्ण छ किनकि भूमिकाले एकैपटक धेरै विधिको विज्ञापन गर्न सक्छ, तर क्षेत्रका ग्राहकहरू सधैं सबैभन्दा कमजोरमा मात्र सहमत हुन्छन्।

Get-VpnAuthProtocol
netstat -ano | findstr :1723

आज सुरुङले वास्तवमा के बोक्छ त्यो निर्धारण गर्नुहोस्

प्रतिस्थापन छान्नुअघि प्रयोगकर्ताहरूको सूची बनाउनुहोस्: घुम्ने ल्यापटप, शाखा राउटर, भुक्तानी टर्मिनल, क्षेत्रीय ट्याब्लेटको समूह। एउटा आन्तरिक होस्टसम्म पुग्नु पर्ने प्रयोगकर्तालाई सार्न सजिलो हुन्छ। पुनः फ्ल्यास गर्न नसकिने हार्डवेयरमा गाडिएको प्रयोगकर्तालाई ग्राहक स्तरोन्नतिको सट्टा मध्यस्थ गेटवे चाहिन सक्छ, र त्यो निर्णय संक्रमणको बीचमा नभई योजनामा हुनुपर्छ।

त्यसपछि सोध्नुहोस्, लगइन आदानप्रदान हेर्न वा त्यसमा प्रभाव पार्न सक्ने आक्रमणकारीले के पाउँछ। MS-CHAPv2 का हकमा उत्तरमा त्यस्तो सामग्री हुन्छ जसले प्रयोगकर्ताको पासवर्ड अफलाइन पुनःप्राप्त गर्न दिन्छ, र त्यसैले लम्बाइ र परिवर्तनले डिजाइन सुधार्दैन: पुनःप्राप्त गोप्य कुरा प्रयोगकर्ताले पुनः प्रयोग गरेको हरेक प्रणालीमा मान्य हुन्छ।

MPPE ले पनि त्यही कमजोरी उत्तराधिकारमा पाउँछ, किनकि यसका कुञ्जीहरू त्यही आदानप्रदानबाट आउँछन्, र यसले आधुनिक AEAD साइफरको प्रति-प्याकेट अखण्डता र पुनःप्ले व्यवहार दिँदैन। सफा रूपमा प्रमाणित भएको सत्रले कन्फिगर गरिएका जाँचसँगको अनुकूलता मात्र प्रमाणित गरेको छ, त्यसभन्दा बढी केही होइन।

न छोटो दिउँसोको विश्रामले न कम प्रयोगकर्ता संख्याले कुनै क्रिप्टोग्राफिक गुणलाई नीतिगत गुणमा बदल्छ।

स्थानान्तरण एउटै मर्मत झ्यालभित्र गर्नुहोस्

प्रतिस्थापन उभ्याउनुहोस्, एउटा पाइलट समूहसँग प्रमाणित गर्नुहोस्, अनि पुरानो श्रोतालाई शान्त ब्याकअपका रूपमा छोड्नुको सट्टा रोक्नुहोस्। सबैले अझै पुग्न सक्ने ब्याकअप स्थानान्तरण होइन, र यसले कमजोर आदानप्रदानलाई बदल्न कहिल्यै दुःख नगर्ने प्रयोगकर्ताहरूकै लागि खुला राख्छ।

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

त्यही झ्यालमा फायरवाल मार्ग बन्द गर्नुहोस्। GRE सँग सम्झनुपर्ने पोर्ट हुँदैन, त्यसैले नम्बरद्वारा प्रोटोकल 47 लाई अनुमति दिने नियम सजिलै छुट्छ र डेमन गएपछि पनि सेवा पुग्नयोग्य राख्छ। हटाइएको नियम, त्यसको अघिल्लो स्थान र कारण टिप्नुहोस्, ताकि पछिको परिवर्तन समीक्षाले यसलाई भूलवश पुनर्स्थापित नगरोस्।

प्रमाण-पत्रलाई कन्फिगरेसनबाट अलग व्यवस्थापन गर्नुहोस्। ग्राहक प्रोफाइल हटाउनु रद्द गर्नु होइन, र अन्यत्र अझै प्रमाणित हुने खाता अवकाश लिइसकेको हुँदैन।

प्रतिस्थापनले PPTP ले गरेका कामहरू गर्छ कि भनी प्रमाणित गर्नुहोस्

जाँचसूची “जोडिन्छ कि” होइन। यो हो कि प्रमाणीकरण, ठेगाना बाँडफाँट, DNS समाधान, मार्ग छनोट, पुनःजडान व्यवहार र सहकर्मी प्रमाणीकरण सबै प्रतिस्थापनमुनि टिक्छन् कि। प्रत्येकलाई पाइलट उपकरणमा, त्यही क्रममा जाँच्नुहोस्, र देखिएको नतिजा अपेक्षाको छेउमा लेख्नुहोस्।

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

इन्टरफेसमा ठेगाना हुनुले वार्ता पूरा भएको प्रमाणित गर्छ। त्यसले टाढाको पक्षले तपाईंले अपेक्षा गरेको मार्ग अधिकृत गरेको प्रमाणित गर्दैन, र माथिको खोजी यही होस्टका लागि मात्र उत्तर दिन्छ, अगाडि पठाइएको LAN का लागि होइन। रिजोल्भरको उत्तरले रिजोल्भरसम्मको पहुँच प्रमाणित गर्छ, विभाजित DNS नीतिले सही नामहरू त्यहाँ पठाउँछ भन्ने होइन।

पुनःजडान सबैभन्दा पछि जाँच्नुहोस्, किनकि धेरै प्रतिस्थापन त्यहीँ पछाडि पर्छन्: ल्यापटपलाई निद्रामा राख्नुहोस्, सञ्जाल बदल्नुहोस्, र पुराना मार्ग नछोडी सुरुङ फेरि स्थापित हुन्छ भनी पुष्टि गर्नुहोस्।

रोलब्याक, रद्द र तपाईंले छोड्ने अभिलेख

रोलब्याकले सेवा पुनर्स्थापित गर्छ; सुरक्षा पुनर्स्थापित गर्दैन, र यो भिन्नता झ्याल खुल्नुअघि ठूलो स्वरले भन्नुपर्छ। नयाँ मार्ग असफल भएमा प्रयोगकर्ताहरूलाई सबैका लागि PPTP फेरि खोल्नुको सट्टा दोस्रो आधुनिक अन्त्यबिन्दु वा अस्थायी गेटवेमार्फत फर्काउनुहोस्। पुरानो प्रोटोकलमा एउटा आपत्कालीन मार्ग राख्नु भर्खरै अभिलेख गरिएको जोखिम फराकिलो बनाउँछ।

संक्रमणपछि PPTP मार्फत प्रमाणित खाताहरू रद्द गर्नुहोस्, तिनका सङ्ग्रहित प्रोफाइलहरूको अवधि सकिन दिनुहोस्, र GRE नियम कुनैले पनि सम्झना नगर्ने विपद्-पुनःप्राप्ति प्रतिलगायत हरेक किनारा उपकरणबाट हटेको पुष्टि गर्नुहोस्।

छोटो अभिलेख छोड्नुहोस्: तपाईंले भेटेका प्रोटोकलहरू, प्रत्येक श्रोता रोकिएको मिति, प्रतिस्थापनले समर्थन गर्ने ग्राहक संस्करणहरू, र निर्णय फेरि खोल्न सक्ने मालिक। पासवर्ड स्वच्छता पछि पनि महत्त्वपूर्ण छ, तर योग्य प्रोटोकलमा स्वच्छताका रूपमा, पुरानोलाई जीवित राख्ने तर्कका रूपमा होइन।