NetworkManager मा gateway-ping-timeout ले साँच्चै के पर्खन्छ

नेटवर्क प्रयोगयोग्य हुनुअघि बुट हुने ल्यापटपबारेको छलफलमा तपाईंले connection.gateway-ping-timeout भेट्नुहुन्छ, त्यसलाई बढाउनुहुन्छ, र केही परिवर्तन हुन्छ। तपाईंले सोचेको कारणले त्यो परिवर्तनले सहयोग गर्यो कि भन्ने छुट्टै प्रश्न हो। त्यो टाइमर चलिरहँदा सक्रियताले वास्तवमा के गरिरहेको छ र यो पर्खाइका दुई सम्भावित अन्त्य छन् भन्ने कुराबाट उत्तर सुरु हुन्छ।

आदेश लाइनबाट एउटा जडान पछ्याउनुहोस्, अनि अर्थ ठोस हुन्छ।

एउटा सक्रियता पछ्याउँदै

विश्वव्यापी पूर्वनिर्धारित होइन, सुरक्षित जडानबाट सुरु गर्नुहोस्, किनकि यो प्रत्येक जडानको गुण हो। --show-secrets वास्तवमै आवश्यक भएमा मात्र थप्नुहोस्; सेटिङ आफैं गोप्य होइन।

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

गुण शून्य हुँदा, जुन कागजात गरिएको पूर्वनिर्धारित हो, ठेगाना दिने काम सकिएसँगै सक्रियता अगाडि बढ्छ। यसलाई धनात्मक मान राख्नुभयो भने IP कन्फिगरेसनको सक्रियता गेटवेबाट जवाफ आउने वा समयसमाप्ति सकिनेसम्म पर्खन्छ।

त्यसपछि घटना प्रवाह हेर्दै जडान तल र माथि ल्याउनुहोस्। तपाईंले देख्ने क्रम यही सेटिङले गरेको काम हो: यन्त्रको अवस्था, ठेगाना दिने, पर्खाइ, र अन्तमा सक्रिय अवस्था जसअनुसार निर्भर सेवाहरू सामान्यतया क्रमबद्ध हुन्छन्।

पर्खाइका दुई अन्त्य छन्

दुवै अन्त्य महत्त्वपूर्ण छन्, तर धेरैले एउटा मात्र सम्झन्छन्। गेटवेबाट आउने जवाफले पर्खाइ चाँडै अन्त्य गर्छ, र समयसमाप्तिले पनि यसलाई अन्त्य गर्छ, केहीले जवाफ दिए वा नदिए पनि। सक्रियता पूरा हुनुअघि यो गुणले सफल ping माग गर्दैन।

त्यो एउटा वाक्यले होटेल र सम्मेलन स्थलका ल्यापटपबारे धेरै अन्योल हटाउँछ, जहाँ पहुँच पोर्टलले तपाईं लगइन नगरेसम्म ICMP अस्वीकार गर्ने गर्छ। समयसमाप्ति सकिएपछि पनि जडान सक्रिय हुन्छ; यो आवश्यक भन्दा ढिलो मात्र हुन्छ, र जडानपछि क्रमबद्ध हुने प्रत्येक सेवा यससँगै पर्खन्छ।

यो जीवितता जाँच पनि होइन। विवरणमा जडान माथि आएपछि गेटवेमा ping सुरु गर्ने केही छैन, र पछिको ping असफल भयो भनेर सक्रिय प्रोफाइल विच्छेद गर्ने पनि केही छैन। तपाईंलाई हानि पत्ता लगाउनु आवश्यक भए त्यो प्रोटोकल वा सुरुङको मालिकको हो, सक्रियताका क्रममा एक पटक चलेको गुणको होइन।

दुई वस्तु, एउटा सेटिङ

वायरयुक्त आधार प्रोफाइल र VPN प्रोफाइल छुट्टाछुट्टै कन्फिगरेसन वस्तु हुन्, र एउटामा गुण सेट गर्दा अर्कोमा असर पर्दैन। आधार जडान नाम दिने VPN प्रोफाइलले त्यसका कुनै पनि सक्रियता सेटिङ उत्तराधिकारमा लिँदैन, त्यसैले तपाईंले बदलेको मान तपाईंले हेरिरहेको कुरामा कुनै प्रभाव नभएजस्तो देखिन सक्छ।

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

नाम होइन, UUID पढ्नुहोस्। पुनःस्थापना वा पुनर्स्थापित प्रोफाइलपछि नामहरू दोहोरिन्छन्, र देखिने नाम एउटै भएका दुई जडानले वास्तविक फाइल अपरिवर्तित रहँदा तपाईंलाई गलत फाइल सम्पादन गर्न लगाउँछन्।

स्थापित NetworkManager संस्करण पनि महत्त्वपूर्ण छ। प्लगइनको व्यवहार र जडान प्रकारले यो गुणलाई आफ्नै सक्रियता चरणहरूमा कसरी म्याप गर्छ भन्ने फरक पर्छ, त्यसैले भेटिएको लेख जस्ताको तस्तै लागू हुन्छ भन्ने नठानी तपाईंले तैनाथ गर्ने संस्करणमा परीक्षण गर्नुहोस्।

पर्खाइले प्रमाणित गर्न नसक्ने कुरा

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

ती छुट्टाछुट्टै प्रमाण भएका छुट्टाछुट्टै निर्भरता हुन्। DNS असफल हुँदा पनि गेटवेले जवाफ दिन सक्छ, र सबै अनुप्रयोग मार्ग चलिरहँदा पनि गेटवेले नीतिअनुसार ICMP चुपचाप छोड्न सक्छ। त्यसैले यो गुणमा सर्त राख्नु कुन तह ढिलो छ भन्ने अनुमान हो, त्यसको मापन होइन।

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

बदल्नुभयो भने किन भनेर लेख्नुहोस्

स्वीकृत परिवर्तनअघि अघिल्लो मान र कारण लेख्नुहोस्, त्यसपछि सबै ठाउँमा होइन, विशेष जडानमा सेट गर्नुहोस्। लामो पर्खाइले त्यो जडानपछि क्रमबद्ध सबैको सक्रियता समय सार्छ, जसले ढिलो प्रणालीलाई ठीक र छिटो प्रणालीलाई बिग्रेको देखाउन सक्छ।

एउटा ऐतिहासिक पासो नाम दिन लायक छ: यस्तो मान कहिलेकाहीँ पुरानो सम्पादकले प्रोफाइल स्वीकारोस् भनेर बदलिन्छ। साँच्चै त्यही कथा हो भने तपाईंसँग एउटा होइन, दुई घटना छन्। सम्पादकले सुरक्षित गर्यो, र प्रत्यक्ष नेटवर्क नीति बदलियो। सम्पादक वा प्लगइन सुधार्नुहोस् र टाइमर फर्काउनुहोस्।

NetworkManager स्रोतले यो गुणलाई गेटवे जवाफ वा समयसमाप्तिसम्म IP ठेगाना दिने सफलताको ढिलाइका रूपमा परिभाषित गर्छ, पूर्वनिर्धारित शून्य, र जडान सेटिङको परिभाषा अरूको मुखबाट सुनेको व्यवहारमा भर पर्नुअघि पढ्नुपर्ने सन्दर्भ हो।