दोस्रो VPN क्लाइन्टले पहिलो बिगार्यो: साझा स्रोत खोज्नुहोस्

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

चारै तह क्रममा हेर्नुहोस्

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

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

दुई पटक नचल्ने सेवाबाट सुरु गर्नुहोस्

Windows मा कर्पोरेट क्लाइन्ट सामान्यतया सुरुङभन्दा बढी हुन्छ, किनकि यसले प्रोफाइलसँगै सेवा, फिल्टर ड्राइभर र कहिलेकाहीँ प्रमाण प्रदायक इन्स्टल गर्छ। परिवर्तनअघि र पछि कुन सेवा चल्छन् लेख्नुहोस्, त्यसपछि केही चलेसम्म रिबुट गर्नुको सट्टा दुई सूची तुलना गर्नुहोस्। सेवाहरू निर्भरताद्वारा एकअर्कालाई बहिष्कृत गर्न सक्छन्, जहाँ एउटा सुरु गर्दा अर्को रोकिन्छ, र त्यही ढाँचा macOS मा launchd काम र साझा डेमनसँग देखिन्छ। केही सेकेन्डमा सुरु भएर निस्कने क्लाइन्ट कन्फिगरेसन होइन, स्वामित्व जनाउँछ।

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

त्यसपछि पोर्ट कसको हो भनी सोध्नुहोस्

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

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

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

फिल्टर ड्राइभर तपाईंको रुटमुनि बस्छ

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

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

कुन उत्पादनले बुटको स्वामित्व राख्छ निर्णय गर्नुहोस्, त्यसपछि लेख्नुहोस्

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

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