दूसरे 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 स्टैक ऐसे प्रॉक्सी के बगल में जो केवल एप्लिकेशन ट्रैफ़िक संभालता है। जहां दोनों एक ही पोर्ट, एक ही फ़िल्टर परत या डिफ़ॉल्ट रूट प्रकाशित करने का अधिकार चाहते हैं, वहां वे बारी-बारी चलते रहेंगे और हर विफलता नई खराबी जैसी दिखेगी।

मालिक को जानबूझकर चुनें। रीबूट के बाद टिकने वाले रूपों में दूसरे क्लाइंट को वर्चुअल मशीन के अंदर चलाना, उसे समर्पित हार्डवेयर पर रखना, या एक ऐसे क्लाइंट पर मानकीकरण शामिल है जो दोनों प्रोटोकॉल बोलता है। हारने वाले के ऑटोस्टार्ट और सेवा को बंद करना हर शुरुआत के बाद रूटिंग तालिका दोबारा बनाने से छोटा बदलाव है, और यह एक सेटिंग संपादन में वापस हो जाता है।