Pi VPN सर्वर: रेसिपी से नहीं, फ़ोन के ऐप से शुरू करें

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

वह क्रम जो दोबारा बनाने से बचाता है

Pi पर कुछ भी इंस्टॉल करने से पहले फ़ोन का ऑपरेटिंग सिस्टम और सटीक VPN ऐप लिख लें। यही जोड़ी तय करती है कि कौन-सा प्रोटोकॉल संभव है। प्रोफ़ाइल में कोई जाना-पहचाना फ़ील्ड होने भर से क्लाइंट ऐप दूसरा क्लाइंट नहीं बन जाता।

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

ऐप तय होने के बाद सर्वर का चुनाव सिकुड़ जाता है और बाक़ी बिल्ड का एक लक्ष्य होता है।

फ़ोन का ऐप असल में क्या लागू करता है

प्रकाशित क्लाइंट सूची किसी ऐप्लिकेशन का वर्णन करती है, सेवा का नहीं। Android के लिए OpenVPN Connect ऐप OpenVPN सर्वर की अपेक्षा करता है; यह सर्वर पक्ष प्रदान नहीं करता। प्रोफ़ाइल समान दिखने पर यह IPsec या L2TP क्लाइंट भी नहीं बन जाता।

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

सर्वर पैकेज के लिए प्रतिबद्ध होने से पहले ऐप के मौजूदा दस्तावेज़ में देखें कि वह कौन-से प्रोफ़ाइल फ़ॉर्मैट आयात करता है। पाँच मिनट पढ़ना दोबारा बनाने से बेहतर है।

चार हिस्सों का समझौता

चार चीज़ें दर्ज करें और उन्हें साथ रखें: फ़ोन का ऑपरेटिंग सिस्टम और ऐप संस्करण, Pi पर सर्वर का कार्यान्वयन, प्रमाणीकरण और भरोसे की नीति, और बाहरी एंडपॉइंट। इनमें से हर एक बाक़ी तीन को अमान्य कर सकता है।

ऐप अपग्रेड, सर्वर पैकेज का बदलाव या नया प्रमाणपत्र प्राधिकरण समझौता तोड़ देते हैं, और फ़ोन से विफलता हर बार एक जैसी दिखती है। चारों का लिखा होना ही आपको पहचानने देता है कि कौन-सा हिस्सा खिसका है।

क्रेडेंशियल के अलग काम हैं

तय करें कि प्रोफ़ाइल क्लाइंट प्रमाणपत्र, उपयोगकर्ता नाम और पासवर्ड, या समर्थित संयोजन इस्तेमाल करता है, और दोनों सिरों को एकमत करें। सर्वर की पहचान और भरोसेमंद CA सामग्री को भी वही होना चाहिए जो क्लाइंट स्वीकार करेगा।

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

हाथ से प्रोफ़ाइल जोड़ने की बजाय सेवा के समर्थित निर्यात और आयात प्रवाह का उपयोग करें। हाथ से बने प्रोफ़ाइल में आम तौर पर सिर्फ़ डेस्कटॉप के निर्देश होते हैं जिन्हें मोबाइल ऐप अनदेखा या अस्वीकार करता है।

सबसे बढ़कर, पुराने उदाहरण को जोड़ने के लिए प्रमाणपत्र सत्यापन की जगह "कोई भी सर्वर स्वीकार करें" न रखें। यह अनुकूलता की समस्या को प्रमाणीकरण बायपास में बदल देता है, और काम करने के कारण यह आम तौर पर प्रोडक्शन तक टिका रहता है।

पहुँच एक अलग अनुबंध है

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

फिर तय करें कि जुड़ने के बाद क्लाइंट कहाँ तक पहुँच सकता है: निजी प्रीफ़िक्स या पूरा इंटरनेट निकास, उनके फ़ॉरवर्डिंग और उत्तर पथ, DNS व्यवहार, और क्या IPv6 दायरे में है। सफल लॉगिन इनमें से कुछ भी साबित नहीं करता।

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