OpenVPN हुक स्क्रिप्ट आत्ताच तयार केलेली बोगदा वापरू शकते का?

हुक स्क्रिप्ट बोगद्याच्या पलीकडे पोहोचते का हे तीन अटींवर अवलंबून आहे: ती कोणत्या घटनेशी जोडलेली आहे, स्क्रिप्ट चालत असताना OpenVPN अजून तिच्या सुरुवातीच्या क्रमात आहे का, आणि काम त्या क्रमापासून वेगळे केले आहे का। बहुतेक स्क्रिप्ट तिसऱ्यावर अपयशी ठरतात। झोप जोडणे जीवनचक्राच्या समस्येला वेळेची समस्या मानते, आणि ते गोंधळवण्याइतक्याच वेळा चालते।

आधी घटना ठरवा, नंतर काम लांबणीवर टाकण्याची पद्धत, नंतर लांबवलेले काम जिथे चालते ते स्थान। हे तीन निर्णय स्वतंत्र आहेत, आणि ते एकत्र करणे हेच दोन ओळींच्या हुकचे पूर्ण दुपार होण्याचे कारण आहे।

हुक तिची वाट पाहणाऱ्या बोगद्याची वाट का पाहते

OpenVPN आपले हुक समकालिकपणे बोलावते, पॅकेट हलवणाऱ्या त्याच प्रक्रियेच्या आत। tun किंवा tap उपकरण असल्यावर पण कोणताही मार्ग जोडण्यापूर्वी up सक्रिय होते, आणि मार्गांनंतर route-up सक्रिय होते; या दोन्ही क्षणांपैकी कोणीही समोरचा पक्ष उत्तर देईल असे वचन देत नाही। कोणत्याही हुकची स्क्रिप्ट चालू असताना डेमन पुढे पाठवत नाही, म्हणून बोगद्यातून रहदारी जाईल अशी अपेक्षा करणारा आदेश त्या आदेशाची वाट पाहणाऱ्या बोगद्याची वाट पाहतो। हे वर्तुळाकार प्रतीक्षाच हाताने चालवल्यास यश मिळण्याचे आणि हुकची मुदत संपण्याचे कारण आहे।

स्पष्ट उपाय, म्हणजे काही सेकंद झोपणे, कधीकधी चालतो कारण दूरचे टोक स्वतः वर आले, झोपेने काही दुरुस्त केले म्हणून नाही। तयारी विचारणारा सहायक वेगळे उत्तर आहे: हुक परत येते, पाठवणी सुरू होते, आणि सहायकाला आवश्यक ते खरोखर तिथे असल्यावर मिळते।

सोयीनुसार नाही, घटनेनुसार हुक निवडा

फक्त उपकरण लागणाऱ्या कामाशी up जोडा, मार्ग लागणाऱ्या कामाशी route-up, आणि client-connect व client-disconnect ठेवा सर्व्हर बाजूच्या प्रत्येक क्लायंटच्या कामांसाठी। डिस्कनेक्टवर स्वच्छता दोन वेळा चालणे सहन केले पाहिजे, कारण स्थिर इंटरफेसवरून पुन्हा जोडणे पूर्ण रीस्टार्टसारखाच क्रम पाळत नाही। सर्व्हरवर, डेमन सुरू होताना नाही तर क्लायंट प्रमाणित होताना client-connect सक्रिय होते, जे तिथे तर्क हलवण्यापूर्वी पुष्टी करण्यासारखे आहे। काम एकाच जोडणीऐवजी सेवेच्या जीवनचक्राचे असेल, तर systemd एकक कोणत्याही हुकपेक्षा चांगले स्थान आहे।

हुक आदेश डेमन थेट चालवतो, मध्ये कोणतेही शेल नाही, म्हणून up ओळीतील ifconfig_remote शब्दशः मजकूर म्हणून येते। आदेश स्पष्ट शेलमध्ये गुंडाळा, किंवा तर्क पर्यावरण वाचणाऱ्या स्क्रिप्टमध्ये ठेवा। ipchange स्वतःचे वितर्क जोडणारे एक निर्देश आहे: ते आदेशाला पत्ता आणि पोर्ट देतो, म्हणून कोणासाठीही न लिहिलेली स्क्रिप्ट दोन अनपेक्षित वितर्क पाहते।

काम वेगळे करण्याचे तीन मार्ग

पहिला पर्याय हुकच्या आतून सहायकाला पार्श्वभूमीवर पाठवणे आहे: setsid किंवा systemd-run --scope ने तो सुरू करा, वारसाहक्काने मिळालेले डिस्क्रिप्टर बंद करा, आणि ताबडतोब शून्यासह बाहेर पडा। दुसरा म्हणजे हुक एक लहान स्थिती फाइल लिहावे आणि systemd टाइमर किंवा पथ एकक त्यावर कार्य करावे, ज्यामुळे हुक साधा राहतो आणि पुनःप्रयत्न धोरण लॉग असलेल्या ठिकाणी जाते। तिसरा म्हणजे हुक पूर्णपणे सोडून काम VPN सेवेनंतर क्रमबद्ध केलेल्या एककात हलवणे, जे काम अजिबात प्रति-जोडणी नसल्यास योग्य उत्तर आहे। तीनही एक नियम सामायिक करतात: बोगद्याची गरज भासण्यापूर्वी हुकने परत यायला हवे।

काय निवडले तरी सहायक इडेम्पोटेंट आणि निरीक्षणयोग्य करा। दोन अतिव्यापी आवाहनांनी एकच अपरिवर्तनीय क्रिया दोनदा चालवू नये, आणि अपयशी सहायकाने माणूस वाचू शकेल असे काहीतरी सोडले पाहिजे।

सँडबॉक्स अपयशांना जीवनचक्र अपयशांपासून वेगळे करा

स्क्रिप्ट root प्रॉम्प्टवरून चालते आणि सेवा म्हणून अपयशी ठरते तेव्हा कारण सहसा नेटवर्क नसून सँडबॉक्स असते। मर्यादित ProtectHome, फक्त-वाचनीय ProtectSystem, किंवा अस्तित्वात नसलेली कार्य निर्देशिका स्क्रिप्ट किंवा तिचा डेटा अगम्य करू शकतात, आणि SELinux होस्टवर फाइलला अंमलबजावणी परवानगी देणारा संदर्भही लागतो। systemctl cat openvpn-server@server ने एकक आणि journalctl -u openvpn-server@server -n 80 ने जर्नल वाचा, नंतर कनेक्शन टाइमआउटऐवजी परवानगी किंवा संदर्भ त्रुटी शोधा। सँडबॉक्स अक्षम करणे पहिले नाही, शेवटचे पाऊल असावे।

जीवनचक्र अपयश वेगळे दिसते: हुक सुरू होते, सहायक चालतो, आणि सॉकेट अजून तिथेच नाही। हुकमधूनच टाइमस्टॅम्प असलेली ओळ लिहा, डिस्कनेक्ट करा आणि पुन्हा जोडा, आणि घटना क्रमाने वाचा। सहायकाला खरोखर बोगदा लागत असेल, तर ठराविक काळ झोपण्याऐवजी तयारी विचारू द्या।

तीन क्षेत्रे पुढील अहवाल उपयुक्त करतात: कोणता हुक चालला, कोणत्या खात्याचा वापर केला, आणि कुठे थांबला। ती नसतील तर प्रत्येक पुढील तपास सुरुवातीपासून होतो।