Pi वर VPN सर्व्हर: फोन ॲपपासून सुरुवात करा, कृतीपत्रिकेपासून नाही

बहुतेक Pi VPN बांधणी सर्व्हरच्या कृतीपत्रिकेपासून सुरू होते आणि जोडणी होऊ न शकणाऱ्या फोनवर संपते। क्रम उलटा आहे। फोनवरील क्लायंट एक विशिष्ट प्रोटोकॉल विशिष्ट प्रमाणीकरण देवाणघेवाणीसह राबवतो, आणि सर्व्हरने त्या देवाणघेवाणीशी जुळणे आवश्यक आहे, उलट नाही। ॲप आधी ठरवल्यास दुपारभराची डीबगिंग एका छोट्या तपासणी यादीत बदलते।

पुनर्बांधणी टाळणारा क्रम

Pi वर काहीही स्थापित करण्यापूर्वी फोनची कार्यप्रणाली आणि नेमके VPN ॲप लिहून ठेवा। ती जोडी कोणता प्रोटोकॉल शक्य आहे हे ठरवते। एखाद्या प्रोफाइलमध्ये परिचित क्षेत्र आले म्हणून क्लायंट ॲप दुसरा क्लायंट होत नाही।

प्रोफाइलमधील सामायिक गुप्त की, किंवा परिचित वाटणारा पोर्ट क्रमांक, एका प्रोटोकॉलचे दुसऱ्यात रूपांतर करत नाही। देवाणघेवाण ॲप राबवत असलेल्या गोष्टीशी जुळते, नाहीतर अशा टप्प्यावर अपयशी ठरते जिथे वाचण्यास फारसे काही मिळत नाही। "चुकीचा प्रोटोकॉल" असे स्पष्ट शब्दांत सांगणारे कोणतेही निदान नसते। तुम्हाला कालबाह्यता, प्रमाणपत्र त्रुटी किंवा शांत पुनःप्रयत्न चक्र मिळते, आणि तिन्ही सर्व्हरची अडचण वाटतात।

ॲप ठरल्यावर सर्व्हरची निवड आकुंचित होते आणि उर्वरित बांधणीला लक्ष्य मिळते।

फोन ॲप प्रत्यक्षात काय राबवते

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

जुना मार्गदर्शक वापरताना हा फरक सर्वाधिक महत्त्वाचा ठरतो। सध्याच्या ॲपने सोडलेल्या प्रोटोकॉलसाठी लिहिलेल्या कृतीपत्रिका Pi वर स्वच्छ स्थापित होतील आणि तरीही फोनवर अपयशी ठरतील, जे संरचना त्रुटीसारखे वाटते, प्रोटोकॉल विसंगतीसारखे नाही।

सर्व्हर पॅकेज निश्चित करण्यापूर्वी ॲप कोणती प्रोफाइल स्वरूपे आयात करते याचे सध्याचे दस्तऐवज पाहा। पाच मिनिटांचे वाचन पुनर्बांधणीपेक्षा बरे।

चार भागांचा करार

चार गोष्टी नोंदवा आणि त्या एकत्र ठेवा: फोनची कार्यप्रणाली व ॲप आवृत्ती, Pi वरील सर्व्हर अंमलबजावणी, प्रमाणीकरण व विश्वास धोरण, आणि बाह्य अंतबिंदू। यातील प्रत्येक जण उर्वरित तिघांना अवैध करू शकतो।

ॲप अपग्रेड, सर्व्हर पॅकेज बदल किंवा नवीन प्रमाणपत्र प्राधिकरण हे सर्व करार मोडतात, आणि प्रत्येक वेळी अपयश फोनवरून सारखेच दिसते। चारही लिहून ठेवल्यामुळे कोणता भाग बदलला हे ओळखता येते।

ओळखपत्रांची स्वतंत्र कामे

प्रोफाइल क्लायंट प्रमाणपत्रे, वापरकर्तानाव व परवलीचा शब्द, की समर्थित संयोजन वापरते हे ठरवा आणि दोन्ही टोके जुळवा। सर्व्हरची ओळख आणि विश्वसनीय CA सामग्रीही क्लायंट स्वीकारेल त्याशी जुळली पाहिजे।

CA चे सार्वजनिक प्रमाणपत्र आणि त्याची स्वाक्षरी करणारी खाजगी की या वेगळ्या वस्तू आहेत। फोन प्रोफाइलमध्ये फक्त सार्वजनिक भागच असावा। स्वाक्षरीची की फोनवर ठेवणे म्हणजे ओळख निर्माण करण्याची क्षमता देणे, जे CA च्या उद्देशाच्या विरुद्ध आहे। ती फाइल संपूर्ण बांधणीतील सर्वात संवेदनशील वस्तू म्हणून हाताळा।

प्रोफाइल हाताने जुळवण्याऐवजी सेवेच्या समर्थित निर्यात व आयात प्रक्रियेचा वापर करा। हाताने बनवलेल्या प्रोफाइलमध्ये फक्त डेस्कटॉपसाठीचे निर्देश असतात, जे मोबाइल ॲप दुर्लक्षित किंवा नाकारते।

सर्वात महत्त्वाचे म्हणजे, जुने उदाहरण जोडण्यासाठी प्रमाणपत्र पडताळणीऐवजी "कोणताही सर्व्हर स्वीकारा" वापरू नका। त्यामुळे सुसंगतीची अडचण प्रमाणीकरण बायपासमध्ये बदलते, आणि ते कार्य करत असल्याने सहसा उत्पादनात टिकून राहते।

पोहोचणे हा वेगळा करार

फोनने प्रत्यक्ष अपस्ट्रीम रचनेतून सर्व्हरच्या बाह्य अंतबिंदूपर्यंत पोहोचले पाहिजे। घरगुती राउटरचे रूपांतरण, गाळणी आणि वाहक NAT हे दोन्हींच्यामध्ये असतात। डायनॅमिक DNS नाव फक्त अंतबिंदूला स्थिर नाव देते; ते आवक मार्ग तयार करत नाही।

मग क्लायंट जोडल्यावर काय पोहोचू शकतो ते ठरवा: खाजगी उपसर्ग की पूर्ण इंटरनेट निर्गम, त्यांचे फॉरवर्डिंग व प्रत्युत्तर मार्ग, DNS वर्तन, आणि IPv6 च्या कक्षेत आहे का। यशस्वी लॉगिन यापैकी काहीही सिद्ध करत नाही।

इच्छित फोन व प्रोफाइल थेट स्वीकारा, यात अनधिकृत संसाधन पोहोचण्याबाहेर राहते आणि रद्द करणे प्रत्यक्षात प्रवेश काढून टाकते याची तपासणी समाविष्ट करा। डेस्कटॉप क्लायंटसह यश त्या डेस्कटॉप क्लायंटची पुष्टी करते, तुमच्या हातातील फोनची नाही। OpenVPN Connect यादी हे जुळणारी सेवा अपेक्षणाऱ्या क्लायंट ॲपचे ठोस उदाहरण आहे।