VPN युनिट नेटवर्कभन्दा अघि किन सुरु भएर पछि मर्छ

मेसिन बुट गर्नुहोस्, लग इन गर्नुहोस्, र थाहा पाउनुहोस् कि टनेल माथि आयो र केही सेकेन्डपछि मर्यो। प्रोफाइल ठीक थियो, प्रमाणपत्र ठीक थियो, र बाँकी रहेको एउटै चिन्ह त्यो बुटको जर्नल हो। सामान्यतया जे भयो त्यो एउटा दौड थियो: मेसिनमा ठेगाना आउनुअघि नै युनिट सुरु भयो, र यसले घोषणा गरेको क्रम देखिने अर्थ दिँदैनथ्यो। तलको सबै कुरा त्यो दौड प्रमाणबाट प्रमाणित गर्ने र यसलाई राम्ररी बन्द गर्ने बारे हो।

लक्ष्य भेटघाटको बिन्दु हो, प्रबन्धक होइन

network-online.target लाई नेटवर्क के हो भन्ने थाहा छैन। यो एउटा समन्वय बिन्दु हो जसले लिङ्क प्रयोगयोग्य नहुँदासम्म सुरुवात ढिलो गर्नुपर्ने सेवा सङ्कलन गर्छ, र परिभाषा मेसिनको मालिक नेटवर्क म्यानेजरलाई सुम्पन्छ। अधिकांश डेस्कटप र सर्भरमा यसको अर्थ NetworkManager वा systemd-networkd ले उपलब्ध गराउने प्रतीक्षा-सेवा हो। दुवैलाई सक्रिय नगरे लक्ष्यसँग प्रतीक्षा गर्ने केही हुँदैन, त्यसैले कुनै कुराले यसलाई तान्ने क्षणमै यो पूरा हुन्छ, र त्यो DHCP जवाफ दिनुभन्दा धेरै अघि हुन सक्छ। तपाईंको युनिटको क्रम-पङ्क्ति इमानदार थियो र तैपनि बेकार।

त्यसैले पहिलो प्रश्न तपाईंको युनिटले के घोषणा गर्छ भन्ने होइन। यो मेसिनमा साँच्चै केही प्रतीक्षा गरिरहेको छ कि छैन भन्ने हो।

युनिट फाइलको सट्टा अन्तिम बुट पढ्नुहोस्

युनिट फाइलहरूले मनसाय वर्णन गर्छन्, र जर्नलले के भयो भन्ने वर्णन गर्छ। त्यही बुट मात्र माग्नुहोस्, मोनोटोनिक टाइमस्ट्याम्पसहित ताकि हरेक सन्देश एउटै घडीमा बसोस्। त्यसपछि दुई लाइन खोज्नुहोस्: टनेल युनिट सुरु हुन थालेको क्षण, र ठेगाना देखा परेको वा प्रतीक्षा-सेवा सकिएको क्षण। ती दुई सङ्ख्यालाई क्रममा राख्नुहोस् र दौड या त प्रमाणित हुन्छ या बहिष्कृत।

निर्भरताको दृश्यले यसलाई पुष्टि गर्छ। यदि टनेल युनिटको महत्त्वपूर्ण शृङ्खलामा प्रतीक्षा-सेवा छैन भने त्यो बाटोमा कसैले सुरुवात ढिलो गरेन, र लक्ष्यले तपाईंले अनुमान गरेको काम गरेन। दुई दृश्य, एउटा निष्कर्ष।

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

प्रतीक्षा थप्नुहोस्, त्यसपछि पुनःप्रयास

प्याकेज गरिएको युनिट सम्पादन गर्नुको सट्टा drop-in प्रयोग गर्नुहोस्, ताकि प्याकेज अपडेटले परिवर्तन चुपचाप नफालोस्। दुई निर्देश महत्त्वपूर्ण छन्: युनिट लक्ष्यपछि क्रमबद्ध हुनुपर्छ, र यसले लक्ष्यलाई त्यही कारोबारमा तान्नुपर्छ। केवल क्रमले लक्ष्यलाई बोलाउँदैन; इच्छाले त्यो गर्छ।

OpenVPN क्लाइन्टको प्याकेज गरिएको युनिटले पहिले नै दुवै बोक्छ। हातले लेखिएका युनिटले सामान्यतया एउटा वा कुनै पनि बोक्दैनन्, जुन केही थप्नुअघि जाँच्न लायक छ।

[Service]
Restart=on-failure
RestartSec=15

किन निश्चित निद्रा एउटा जाल हो

ExecStartPre भित्रको निद्रा क्रम-सुधार जस्तो लाग्छ र थप कदमहरू भएको ढिलाइ जस्तै व्यवहार गर्छ। यसले हरेक बुटलाई सुस्त बनाउँछ, स्वस्थ भएकाहरूलाई पनि, र तपाईंले छानेको सङ्ख्याभन्दा लिङ्कले बढी समय लिँदा पनि हार्छ।

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

जब क्रम ठीक हुन्छ र नामहरू अझै असफल हुन्छन्

टनेल मार्ग भएको सक्रिय युनिट भनेको क्रमले आफ्नो काम गर्यो र बाँकी गडबडी एक तह माथि छ। सामान्य रूप टनेलको up स्क्रिप्टले लागू गर्ने रिजोल्भर सेटिङ हो, लिङ्क वा रिजोल्भरले यसलाई राख्न तयार हुनुअघि। असफलताको समयमा रिजोल्भरको अवस्थालाई टनेल युनिट पुनःसुरु गरेपछिको अवस्थासँग तुलना गर्नुहोस्।

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