Windows को अन्तर्निहित VPN ले विक्रेताको SSL गेटवेसम्म किन पुग्दैन
Windows सँग चार प्रकारका सुरुङ आउँछन्, र विक्रेताको गेटवे तीमध्ये एक होइन। प्रमाणपत्र, मार्ग वा प्रमाणहरू छुनुअघि प्रोफाइलको प्रकार जाँच्नुहोस्।
Windows सँग चार प्रकारका सुरुङ आउँछन्, र विक्रेताको SSL गेटवे तीमध्ये एक होइन। त्यसै पनि अन्तर्निहित प्रोफाइल त्यस्तै गेटवेतिर फर्काउनुभयो भने प्रमाण माग्नुअघि नै जडान असफल हुन्छ, प्रायः स्थानीय प्रणालीले जडान अन्त्य गरेको भन्ने सन्देशसँगै। त्यो पाठ मेल नखाएको सङ्केत हो, निदान होइन। प्रोफाइलको प्रकार र प्रोटोकलको स्वामित्व भएको क्लाइन्ट मिल्नुपर्छ, र तीमध्ये एक हराइरहेको छ।
चार प्रकार र एउटा संवाद
हरेक भण्डारित प्रोफाइलले सुरुङको प्रकार बोक्छ। अन्तर्निहित क्लाइन्टले PPTP, L2TP, IKEv2 र SSTP स्वीकार्छ, साथै तिनलाई क्रमैसँग परीक्षण गर्ने स्वचालित मोड पनि। कुनै सामान्य SSL VPN प्रविष्टि छैन, र संवादबाट एक थप्ने उपाय पनि छैन। विक्रेताको गेटवेले TLS माथि आफ्नै अनुप्रयोग प्रोटोकल बोल्छ, जुन त्यही विक्रेताको क्लाइन्टले मात्र कार्यान्वयन गर्छ।
सूची एक आदेशको दूरीमा छ, र अन्य कुनै पनि समस्या-निवारणअघि यो चलाउनु उपयुक्त हुन्छ, किनभने यसले एक सेकेन्ड लिन्छ र गलत अनुमानको एउटा पूरै वर्ग हटाइदिन्छ:
Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling Get-VpnConnection -Name "Office" | Format-List
यदि प्रोफाइलले SSTP भन्छ र गेटवे RRAS सर्भर होइन भने, मेल नखाएको कुरा पहिले नै स्थापित भइसक्यो। प्रमाणपत्र वा फायरवालको कुनै कामले त्यो बदल्दैन।
SSTP र विक्रेताको TLS पोर्ट 443 मा उस्तै देखिन्छन्
SSTP ले PPP सत्रलाई TLS भित्र बेरेर TCP 443 मा गुड्छ। Microsoft स्ट्याकमा यसलाई RRAS ले अन्त्य गर्छ, जसले क्लाइन्टले प्रमाणित गर्ने सर्भर प्रमाणपत्र प्रस्तुत गर्छ। Fortinet, Citrix वा Pulse यन्त्रले पनि 443 मा TLS अन्त्य गर्छ, र त्यसको पोर्टल जुनसुकै ब्राउजरमा बिना गुनासो खुल्छ।
त्यो ब्राउजर परीक्षणले पुग्ने क्षमता प्रमाणित गर्छ, मिलनसारिता होइन। पोर्टलपछाडिको सत्र प्रोटोकल विक्रेताको हो, र अन्तर्निहित क्लाइन्टसँग त्यसको कुनै कार्यान्वयन छैन। विक्रेताले आफ्नै क्लाइन्ट दिन्छ कि भन्नेले तपाईं मेल नखाएको कुराको कुन आधासँग व्यवहार गर्दै हुनुहुन्छ भन्ने बताउँछ।
उल्टो अलमल पनि हुन्छ। वास्तविक RRAS सर्भरसामु SSTP का रूपमा मिलाइएको प्रोफाइल प्रमाणपत्र प्रमाणीकरणमा असफल हुन सक्छ, जबकि पोर्टल ठीक हुन्छ, र त्यो प्रमाणपत्रको समस्या हो, प्रोटोकलको होइन।
सुरुङ बन्नुअघि देखिने त्रुटिहरू
800 शृङ्खलाका कोडहरू कुनै पनि सुरुङ स्थापना हुनुअघि नै रिपोर्ट गरिन्छ, त्यसैले फायरवाल नियमले तिनलाई विरलै सार्छ। त्रुटि 812 सर्भर-पक्षको नीति हो जसले क्लाइन्टले दिएको प्रमाणीकरण विधि अस्वीकार गर्छ। यो दायराका अरू स्थानीय जडान व्यवस्थापकबाट आउँछन्, सञ्जालबाट होइन।
केही पनि पुनर्निर्माण गर्नुअघि ट्रेसिङ खोल्नुहोस्। ट्रेसिङले असफल हुने चरणको नाम बताउँछ, र चरणको नाम संवादको पाठभन्दा बढी मूल्यवान् हुन्छ:
netsh ras set tracing * enable Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5
ट्रेसहरू ट्रेसिङ निर्देशिकामुनि पर्छन् र तपाईंले सफा नगरेसम्म त्यहीँ रहन्छन्, त्यसैले पछि ट्रेसिङ बन्द गर्नुहोस्, हप्तौंसम्म खुला राख्नुहोस् न।
जोडिएको प्रोफाइलले पनि सबै थोक बिगार्न सक्छ
जोडिने र त्यसपछि ब्राउजिङ, स्थानीय साझेदारी वा कन्टेनर इन्जिन बिगार्ने प्रोफाइलमा मार्गनिर्देशनको समस्या हुन्छ, सुरुङको होइन। पूर्वनिर्धारित गेटवे सुरुङमा सर्यो, त्यसैले अब हरेक गन्तव्य त्यसलाई मार्गनिर्देशन नगर्न सक्ने साथीबाट जान्छ।
दुई नियन्त्रणले यो निर्धारण गर्छन्। एउटा प्रोफाइलमा रहेको स्प्लिट-टनेलिङ गुण हो। अर्को दूरस्थ सञ्जालमा पूर्वनिर्धारित गेटवे प्रयोग गर्ने प्रत्येक एडाप्टरको विकल्प हो, जो IPv4 का उन्नत सेटिङमुनि छ।
Set-VpnConnection -Name "Office" -SplitTunneling $true Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16
मार्ग नथपी स्प्लिट टनेलिङ खोल्दा जोडिने तर कतै नपुग्ने सुरुङ बन्छ। DNS नजाँची त्यो बन्द गर्दा आन्तरिक नामहरू सार्वजनिक उत्तरमा परिणत हुन्छन्, किनभने एडाप्टरको आफ्नै प्रत्यय र सर्भरहरू प्रयोग हुँदैनन्।
पहिले प्लम्बिङ जाँच्नुहोस्, त्यसपछि प्रकार
यही क्रममा काम गर्नुहोस्, र सबै कुरा एकैचोटि मिलाउनुको सट्टा कुनै चरण असफल भएमा रोकिनुहोस्:
Test-NetConnection vpn.example.net -Port 443 Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix netsh interface ipv4 show route rasdial Office
पहिलो आदेशले पुग्ने क्षमतालाई प्रोटोकलबाट अलग गर्छ। दोस्रोले प्रोफाइलले आफूलाई के भन्छ भन्ने पुष्टि गर्छ। मार्ग तालिकाले सुरुङले पूर्वनिर्धारित मार्ग समात्यो कि भन्ने देखाउँछ। डायल आदेशले जडान व्यवस्थापकको आफ्नै त्रुटि रिपोर्ट गर्छ, जो प्रायः संवादभन्दा स्पष्ट हुन्छ।
टिकटमा सुरुङको प्रकार, गेटवेको उत्पादन र ठ्याक्कै त्रुटि लेख्नुहोस्। त्यसपछि अर्को व्यक्तिले एक मिनेटभित्र यो प्रोटोकल मेल नखाएको, प्रमाणपत्र असफलता वा मार्गनिर्देशनको निर्णय हो भन्ने थाहा पाउँछ, “VPN चल्दैन” बाट सुरु गर्नुको सट्टा।