एक ही राउटर के पीछे केवल एक VPN क्लाइंट ही क्यों जुड़ता है

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

किसी क्लाइंट को छूने से पहले गेटवे का लॉग पढ़ें

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

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

कुछ भी बदलने से पहले नतीजा लिख लें, क्योंकि लॉग के तीन नतीजे तीन असंबंधित मरम्मतों की ओर ले जाते हैं। तीन में से कौन सा देखा, यह बताने वाला नोट क्लाइंट त्रुटि के स्क्रीनशॉट से अधिक मूल्यवान है।

राउटर GRE और NAT-T के साथ क्या करता है

PPTP क्लासिक अपराधी है: नियंत्रण चैनल TCP 1723 है जबकि डेटा मार्ग GRE, यानी IP प्रोटोकॉल 47 है। कई उपभोक्ता राउटर PPTP सहायक के साथ आते हैं जो एक ही नियंत्रण कनेक्शन पर नज़र रखता है, इसलिए उसी NAT के पीछे दूसरा क्लाइंट अपना नियंत्रण चैनल खोलता है और फिर उसे कोई डेटा मार्ग ही नहीं मिलता। 47 नंबर का TCP पोर्ट फ़ॉर्वर्ड करने से GRE के लिए कुछ नहीं होता, क्योंकि GRE एक प्रोटोकॉल नंबर है, पोर्ट नहीं।

L2TP IPsec के ऊपर डिज़ाइन से अलग व्यवहार करता है: IKE UDP 500 का उपयोग करता है, NAT ट्रैवर्सल संरक्षित पेलोड को UDP 4500 पर ले जाता है, और एनकैप्सुलेशन ठीक इसलिए है कि एक पते के पीछे कई क्लाइंट उसी गेटवे तक पहुँच सकें। यह डिज़ाइन किसी गेटवे या बीच के बॉक्स को प्रति-पता सत्र सीमा लगाने से नहीं रोकता, और सोफ़े से दोनों विफलताएँ एक जैसी दिखती हैं। SoftEther के अपने प्रोटोकॉल में भी यही श्रेणी की समस्या है: काम करते पास-थ्रू के बिना राउटर LAN से पहले क्लाइंट को अंदर लेता है और दूसरे को गिरा देता है। राउटर का ALG या पास-थ्रू स्विच दोनों स्थितियों में जाँचें, क्योंकि पुराने क्लाइंट के लिए लिखा सहायक उन पैकेटों को खराब कर सकता है जो मौजूदा क्लाइंट भेजता है।

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

पहचान की सीमाएँ जो ट्रांसपोर्ट सीमाएँ जैसी दिखती हैं

राउटर एकमात्र संदिग्ध नहीं है, और लॉग उसे विकल्प से अलग करता है। जब OpenVPN सर्वर किसी साझा नाम को एक सुरंग पते से बाँधता है, तो दोनों डिवाइस वह पता पा लेते हैं, और duplicate-cn के बिना नया सत्र पुराने को बाहर धकेल देता है। उस विकल्प को चालू करने से दोनों जुड़े रहते हैं पर उनके पास एक पहचान, एक प्रमाणपत्र और एक निरसन निर्णय ही रहता है, जो दिखने से बुरा है। तब दूसरा डिवाइस कभी अकेले निरस्त नहीं हो सकता, इसलिए सुविधा का एक स्विच चुपचाप वह नियंत्रण हटा देता है जिसकी आपको बाद में ज़रूरत पड़ सकती है।

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

मरम्मत को लॉग प्रविष्टि से मिलाएँ

लॉग में अस्वीकृति के लिए हर डिवाइस की अलग लॉगिन जानकारी, सेवा चलाने वाले से अधिक सीमा, या एक मशीन के लिए दूसरा गेटवे एंडपॉइंट चाहिए। अगर कोई दूसरा प्रयास कभी सर्वर तक नहीं पहुँचता, तो टिकाऊ मरम्मत वह राउटर है जो प्रोटोकॉल फ़ॉर्वर्ड करता है और एक से अधिक सत्र रखता है, या वह ट्रांसपोर्ट जिसे राउटर अच्छी तरह संभालता है, जैसे एक ही TCP या UDP प्रवाह। इनमें से चुनना हार्डवेयर की उम्र का निर्णय है, क्लाइंट सेटिंग का नहीं।

काम करते डिवाइस की प्रोफ़ाइल दूसरी मशीन पर कॉपी करके काम ख़त्म मत मानिए। इससे कनेक्शन की समस्या एक्सेस नियंत्रण की समस्या बन जाती है, क्योंकि खोया लैपटॉप अब अभी इस्तेमाल में रही प्रतिलिपि से अलग नहीं पहचाना जा सकता। यह मूल ख़राबी को भी छिपाता है, जो तीसरा डिवाइस दिखते ही लौट आती है।

दो जीवित सत्रों का सत्यापन

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

अगर दोनों सत्र टिके रहें और ट्रैफ़िक ढोएँ, तो समाधान टिकता है और शुरू में लिखा नोट यह रिकॉर्ड बन जाता है कि क्या गड़बड़ थी। अगर केवल एक टिके, तो पहले चरण पर लौटें और देखें कि अब तीन लॉग नतीजों में से कौन सा आपके पास है, क्योंकि उत्तर बदल सकता है। राउटर के सहायक किसी ऐसी समस्या को छिपा सकते हैं जो दूसरे नेटवर्क पर फिर दिखती है, जबकि प्रति-पता सीमा डिवाइस नहीं, उपयोगकर्ता का पीछा करती है। दूसरे नेटवर्क से परीक्षण करना यह जानने का सबसे सस्ता तरीका है कि इनमें से आपने वास्तव में क्या ठीक किया।