सेवा थांबवल्यास persist-tun सेट असतानाही इंटरफेस काढला जातो। हा पर्याय दस्तऐवजानुसार काम करत आहे, अपयश नाही। पर्याय चालू प्रक्रियेतील एक रीस्टार्ट मार्ग वर्णन करतो, आणि systemctl stop तो मार्ग नाही।

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

दोन संसाधने आणि ते ज्या रीसेटचे आहेत

OpenVPN दोन सामान्य परिस्थितीत स्वतःच्या रीस्टार्टचा संकेत देतो। स्पष्ट SIGUSR1 ते करतो, आणि मृत साथीदाराने ट्रिगर केलेला ping-restart तेच करतो। दोन्ही प्रक्रिया जिवंत ठेवतात आणि कनेक्शन सेटअप पुन्हा चालवतात, आणि तिथेच पर्याय आपली जागा मिळवतात।

EventTUN/TAP deviceKey and auth filesAddresses and routesup/down hooks
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itselfsurvives only with persist-tunsurvive only with persist-keysurvive with the device, otherwise rebuiltrun again only when restart hooks are enabled
Configuration reload, SIGHUPrecreatedre-read from diskrebuilt once the device returnsrun again
Service stoplostre-read at the next startremovedrun at the next start

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

हे पर्याय अजिबात का आहेत

कठोर केलेला OpenVPN सर्व्हर सामान्यतः root म्हणून सुरू होतो, त्याच्या की आणि उपकरण उघडतो, नंतर विशेषाधिकार नसलेल्या वापरकर्त्याकडे जातो। त्या संक्रमणानंतर काही क्रिया फक्त नाहीशा होतात। मोड 0600 की फाइल वाचणे, नेटवर्क इंटरफेस तयार करणे किंवा मार्ग बदलणे हे सर्व नाकारले जाऊ शकते।

persist पर्यायांशिवाय, ping-restart ट्रिगर करण्यापुरता वेळ गप्प राहणारा साथीदार नेमक्या त्या क्रिया बळजबरी करेल। कॉन्फिगरेशनमध्ये काहीही न बदलल्यासही पुन्हा जोडणी अपयशी होईल। प्रक्रिया कारणाशिवाय मरत असल्यासारखी दिसेल, आणि लॉग नेटवर्क त्रुटीऐवजी परवानगी त्रुटी दाखवेल।

त्यांच्यासह, मऊ रीस्टार्ट विशेषाधिकारित टप्प्याने आधीच मिळवलेले पुन्हा वापरतो। कोणतेही जादू नाही आणि प्रक्रिया काहीही टिकवत नाही। संसाधने मिळवणे फक्त पुढे ढकलले जाते।

शेवटची नाही, पहिली त्रुटी वाचा

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

हुकचे स्वतःचे स्विच असते। OpenVPN मॅन्युअल persist पर्याय up-restart शी जोडते, जे रीस्टार्टनंतर up आणि down स्क्रिप्ट पुन्हा चालतील का हे ठरवते। म्हणून वर राहिलेला इंटरफेस तुमचे रिझोल्व्हर एकीकरण रीफ्रेश झाले का याबद्दल काहीही सांगत नाही।

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

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

ठेवलेला इंटरफेस kill switch नाही

आवश्यकता अशी असेल की रहदारी कधीही बोगद्याबाहेर जाऊ नये, तर ठेवलेले उपकरण ते देत नाही। दुसऱ्या पत्ता कुटुंबासाठीचे मार्ग, दुसरा डीफॉल्ट मार्ग, आणि प्रक्रिया पूर्णपणे बाहेर पडण्याची स्थिती हे सर्व पर्यायाच्या व्याप्तीबाहेर राहतात।

दोन्ही आवश्यकता वेगळ्या हाताळा। पुन्हा जोडण्यांदरम्यान बोगदा वस्तू ठेवणे डेमनसाठी सोय आहे। बोगदा बंद असताना बाहेर जाणे अडवणे हे स्वतःचे नियम आणि स्वतःची चाचणी असलेले फायरवॉल धोरण आहे। ती एकत्र करणे अशी कॉन्फिग तयार करते जी संरक्षणात्मक दिसते आणि सर्वोत्तम-प्रयत्न पुन्हा जोडणीसारखी वागते।

निदानापूर्वी घटनेला नाव द्या। मऊ रीस्टार्ट, अपयशी कनेक्शन प्रयत्न आणि सेवा थांबवणे हे तीन वर्तन असलेल्या तीन घटना आहेत, आणि फक्त पहिलीच हे पर्याय वर्णन करतात ती।

संबंधित लेख