Windows VPN सुदृढीकरण: सुरुङ अघि प्रमाणीकरण सुधार्नुहोस्

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

आक्रमणकारीले काम गर्ने क्रममै काम गर्नुहोस्। पहिले तारबाट समात्न सकिने कुरा। त्यसपछि त्यो रेकर्डिङसँग पछि फेरि चलाउन सकिने कुरा। अन्तमा, प्रमाणित आक्रमणकारी भित्र पसेपछि पुग्न सक्ने कुरा।

तीन कर्तव्य, एउटा संवाद

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

जब तीनवटै एउटै मानसिक बाल्टिनमा बस्छन्, सामान्य नतिजा त्यस्तो सर्भर हुन्छ जसले बलियो प्रमाणीकरण गर्छ र त्यसपछि प्रयोगकर्तालाई सबै कुरा पुग्न दिन्छ। त्यसलाई पछि सुधार्नु अहिले नीति तय गर्नुभन्दा कठिन हुन्छ, किनकि त्यतिबेला फायरवाल प्रोफाइल, ठेगाना पूल र मार्गहरू सबैले पुरानो अनुमान कोड गरिरहेका हुन्छन्।

कुनै पनि सेटिङ छुनु अघि तीनवटैलाई तपाईंको टिप्पणीमा अलग गर्नुहोस्, त्यसपछि तिनलाई सबैभन्दा कमजोर कडीबाट माथि सुधार्नुहोस्।

MS-CHAPv2 पुनःप्ले परीक्षण किन टिक्न सक्दैन

यदि सर्भरले अझै MS-CHAPv2 सहित PPTP स्वीकार गर्छ भने सुरुङले पासवर्डलाई कुनै अर्थपूर्ण अर्थमा जोगाउँदैन। चुनौती र प्रतिक्रिया समात्न सकिन्छ र अफलाइन आक्रमण गर्न सकिन्छ, र 2012 मा एउटा सार्वजनिक क्र्याकिङ सेवाले सामान्य पासवर्डका लागि त्यस्तो हात मिलाउने क्रमबाट करिब एक दिनमा पुनःप्राप्ति देखाएको थियो। लामो र जटिल पासवर्डले लागत बढाउँछ; यसले आक्रमणकारीलाई सञ्जालबाट चाहिने सामग्री हटाउँदैन।

तपाईंले चाहेको गुण त्यस्तो प्रमाण हो जो दोहोर्याउन सकिँदैन। क्लाइन्ट प्रमाणपत्रसहित EAP-TLS ले प्रत्येक यन्त्रलाई आफ्नै पहिचान दिन्छ र तपाईंलाई ठ्याक्कै एउटा यन्त्र रद्द गर्न दिन्छ।

प्रमाणपत्र परिनियोजन साँचो काम हो: निजी CA, क्लाइन्टले जाँच्ने रद्दीकरण मार्ग, र कर्मचारी परिवर्तन टिक्ने नवीकरण योजना। त्यो कामलाई परियोजना मान्नुहोस्, तपाईं र चल्ने सुरुङबीचको बाधा होइन। फायरवाल परिवर्तनका लागि बजेट राख्नुहुन्छ जस्तै त्यसका लागि राख्नुहोस्। साझा पासवर्ड पहिलो रद्दीकरणसम्म मात्र सस्तो हुन्छ।

पूर्व-साझा कुञ्जीले जोडीलाई प्रमाणित गर्छ, व्यक्तिलाई होइन

L2TP/IPsec पूर्व-साझा कुञ्जीसहितले दुई गेटवेले एउटै रहस्य जान्छन् भनी प्रमाणित गर्छ। यसले कुन मानिस जोडिँदै छ भन्ने कुरा केही भन्दैन, र त्यो तहमा एक कर्मचारीलाई अर्कोबाट छुट्याउन सक्दैन। लामो अनियमित मान प्रयोग गर्नुहोस्, केही मार्गदर्शनले सुझाएका दस अक्षरभन्दा धेरै माथि, किनकि हात मिलाउने क्रम समात्ने जो कोहीले कुञ्जीमा अफलाइन आक्रमण गर्न सक्छ।

त्यो प्रोफाइलका प्रत्येक क्लाइन्टले रहस्य साझा गर्छ, त्यसैले एक व्यक्ति हटाउनु भनेको बाँकी सबैलाई त्यो फेरि बाँड्नु हो। मेसिन-स्तरको रहस्यमाथि प्रयोगकर्ता प्रमाणीकरणको छुट्टै चरण राख्नुहोस्, र क्लाइन्ट संख्या बढ्दै जाँदा प्रमाणपत्रतिर जानुहोस्। पूर्व-साझा कुञ्जी MS-CHAPv2 सँग मिल्दा दुई कमजोर तह हुन्छन्, र दोस्रोले पहिलोलाई निष्फल बनाउँछ।

अधिकार Network Policy Server मा छ

Windows मा NPS ले को जोड्न सक्छ भनी निर्धारण गर्छ, र यो प्रमाणीकरण पहिले नै सफल भइसकेपछि गर्छ। त्यो विभाजन उत्पादनको सबैभन्दा उपयोगी सुदृढीकरण नियन्त्रण हो, र धेरै परिनियोजनहरूले यसलाई अछुतो छोड्छन्।

वास्तविक सीमा प्रतिबिम्बित गर्ने नीति सर्तहरू प्रयोग गर्नुहोस्: समूह सदस्यता, सहयोग कर्मचारीसहित उपलब्ध हुने समय खिड्की, र स्वास्थ्य जाँचबाट यन्त्रको अवस्था। डेटाले घर्षणलाई न्यायोचित ठहराउने ठाउँमा दोस्रो कारक थप्नुहोस्, र नीति प्रत्येक जडान प्रयासका लागि मूल्याङ्कन गरिन्छ भनी सम्झनुहोस्, जसले यसलाई कागजात होइन जीवित नियन्त्रण बनाउँछ।

RADIUS लेखाजोखाले तपाईंलाई को कहिले जोडियो भन्ने एउटा अभिलेख पनि दिन्छ। त्यो लग घटना समीक्षा र अनुमानबीचको फरक हो, र कसैले पढोस् वा नपढोस् त्यो रहन्छ।

सफल लगइन कहाँ पुग्न सक्छ सीमित गर्नुहोस्

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

दुवैमध्ये कुनै विकल्प सुरक्षा पूर्वनिर्धारित होइन। दुवैलाई तिनले अनुमान गर्ने फायरवाल प्रोफाइलको छेउमा लेख्नुपर्छ।

असफलताका मार्गहरू प्रमाणित गर्नुहोस्

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

त्यसपछि कुन पोर्ट प्रकाशित छन् र किन भनी पुष्टि गर्नुहोस्। PPTP लाई TCP 1723 र पोर्टको सट्टा IP प्रोटोकलका रूपमा GRE चाहिन्छ, IKEv2 लाई UDP 500 र 4500 चाहिन्छ, र L2TP लाई UDP 1701 सहित IPsec चाहिन्छ। क्लाइन्ट जोडिनका लागि व्यवस्थापन इन्टरफेस खोल्नु मर्मत होइन, त्यो पत्ता लाग्न बाँकी दोस्रो घटना हो।

अन्तमा, सर्भरले के र कति समय अभिलेख गर्छ निर्धारण गर्नुहोस्। प्रमाणीकरण इतिहास नभएको अन्तिम बिन्दुले घटनापछिको पहिलो प्रश्नको उत्तर दिन सक्दैन, अर्थात् त्यो प्रयास कहिल्यै अधिकृत थियो कि थिएन।