WireGuard PersistentKeepalive: NAT म्यापिङ जीवित राख्नुहोस्
यदि उल्टो जडान पियरले ट्राफिक पठाएपछि मात्र काम गर्छ भने, म्यापिङ समाप्त हुँदै छ। राउटरको पछाडि keepalive सेट गर्नुहोस् अनि वास्तविक समयसीमा पढ्नुहोस्।
घरको बाकसले सुरुङ खोल्छ र कुनै समस्या बिना क्लाउड सर्भरमा पुग्छ। घरको बाकसले अन्तिम पटक केही पठाएपछि क्लाउड सर्भरले एक वा दुई मिनेटसम्म घरको अनुप्रयोगमा पुग्न सक्छ, अनि रोकिन्छ। WireGuard लगमा केही देखिँदैन, कुनै ह्यान्डसेक त्रुटि रिपोर्ट गरिँदैन, र सुरुङ पुनः सुरु गर्दा यो केही समयका लागि ठीक हुन्छ। त्यो ढाँचा समाप्त हुँदै गरेको म्यापिङ हो, बिग्रेको सुरुङ होइन, र तलको मार्गदर्शिकाले केही बदल्नु अघि यसलाई पुष्टि गर्छ।
ढाँचा निष्क्रियतामा समाप्ति हो भनी पुष्टि गर्नुहोस्
छुट्याउने विवरण समय हो। यदि उल्टो जडान घरको पियरले ट्राफिक पठाएपछि तुरुन्तै काम गर्छ र शान्त अन्तरालपछि असफल हुन्छ भने, बाटो ठीक छ र बीचको अवस्था होइन। यदि यो कहिल्यै काम गरेन, ट्राफिकपछि पनि, यो गलत निदान हो।
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferघरको पियरले केही पठाएपछि तुरुन्तै पहिलो दुई चलाउनुहोस्, पाँच मिनेट पर्खनुहोस् र फेरि चलाउनुहोस्। नयाँ इन्डपोइन्ट बिना तालिका अनुसार नवीकरण हुने ह्यान्डसेक टाइमस्ट्याम्पले तपाईंलाई सुरुङ जीवित छ भनी बताउँछ। परिवर्तन भएको कुरा बाहिरबाट नमागिएका प्याकेटहरू आउने क्षमता हो, जुन सुरुङको होइन, बाटोको गुण हो।
त्यसपछि उल्टो प्रयास गर्नुहोस् र स्थानान्तरण काउन्टरहरू हेर्नुहोस्। यदि क्लाउड पक्षले बाइट पठाउँछ र घरको पक्षले एउटै पनि प्राप्त गर्दैन भने, प्याकेट क्लाउड छोडेर बाटोमा अवस्था राख्ने उपकरणमा मर्यो। तपाईंले खोजिरहनुभएको हस्ताक्षर त्यही हो। यदि दुवै काउन्टर चल्छन् भने, सुरुङले प्याकेट पुर्यायो र शंकास्पद अनुप्रयोग हो।
keepalive राउटरको पछाडिको पियरमा राख्नुहोस्
स्थायी keepalive हरूले तालिका अनुसार सानो प्रमाणित प्याकेट पठाएर NAT म्यापिङ र कुनै पनि फायरवाल अवस्था जीवित राख्छन्। सेटिङ राउटरको पछाडिको मेसिनमा, टाढाको पियरका लागि उसको प्रविष्टिमा हुनुपर्छ, किनकि त्यही पक्षको बाहिर जाने प्याकेटले अवस्था सिर्जना गर्छ।
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25यसलाई विद्यमान पियर खण्डमा मिलाउनुहोस्। उही सार्वजनिक कुञ्जीसँग दोस्रो ब्लक थप्नु विकल्प थप्ने वैध तरिका होइन, र wg-quick ले तिनीहरूलाई तपाईंका लागि मिलाउने छैन। अभिलेखित 25 सेकेन्ड सामान्य UDP समयसीमाभन्दा तल रहन छानिएको उदाहरण हो, विशेष अर्थ भएको मान होइन।
उही निर्देश क्लाउड पक्षमा राख्नाले यो समस्यामा मद्दत गर्दैन। त्यो पियरका प्याकेट पहिले नै सार्वजनिक ठेगानाबाट आइरहेका छन्, त्यसैले महत्त्वपूर्ण दिशामा जोगाउनुपर्ने म्यापिङ छैन। यसले ट्राफिक थप्छ र केही बदल्दैन।
अन्तराल अनुमान नगरी टाइमर पढ्नुहोस्
keepalive हरू काम गर्छन् किनकि तिनीहरू अवस्था समाप्त हुनुभन्दा बढी पटक आउँछन्। यसले समयसीमालाई तपाईंलाई साँच्चै चाहिने संख्या बनाउँछ, र Linux मा यो अनुवाद गर्ने उपकरणमा पढ्न सकिन्छ:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820पहिलो मान एउटा दिशामा मात्र देखिएको UDP प्रवाहको समयसीमा हो, र दोस्रो जवाफ देखिएपछि लागू हुन्छ। दुवै सामान्यतया छोटा हुन्छन्, र शान्त हुने म्यापिङले तपाईंको प्रवाहमा लागू हुने कुरा पछ्याउँछ।
त्यो संख्यालाई तपाईंको अन्तरालसँग तुलना गर्नुहोस्। 30 सेकेन्डको समयसीमा अन्तर्गत 25 सेकेन्डको keepalive काम गर्छ; त्यही keepalive 15 सेकेन्डको समयसीमा अन्तर्गत काम गर्दैन। जतिपटक पुनःप्रयास गरे पनि त्यो गणित बदलिँदैन। केही उपभोक्ता राउटर र मोबाइल सञ्चालकहरूले Linux को पूर्वनिर्धारितभन्दा धेरै छोटा मान प्रयोग गर्छन्, त्यसैले एउटा नेटवर्कमा काम गर्ने कन्फिगरेसन अर्कोमा असफल हुन्छ।
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
श्रोता र फायरवाल अलग-अलग जाँच्नुहोस्
जीवित म्यापिङ आवश्यक छ र पर्याप्त छैन। घरको बाकसमा रहेको अनुप्रयोगले सही ठेगानामा सुन्नुपर्छ, र होस्ट फायरवालले डिक्रिप्ट भएपछि प्याकेटलाई अनुमति दिनुपर्छ।
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthयदि सकेट सुरुङको ठेगानामा होइन, भौतिक इन्टरफेसको ठेगानामा मात्र बाँधिएको छ भने, सुरुङमा आउने प्याकेटहरू फायरवाललाई सोध्नुअघि नै खारेज हुन्छन्। यो असफलता क्लाउड पक्षबाट म्यापिङ समस्याजस्तै देखिन्छ, र हरेक keepalive समायोजनलाई जोगिन्छ।
अनुमति दिइएको सूचीको जाँच अर्को दिशामा पनि त्यत्तिकै महत्त्वपूर्ण छ। क्लाउड पियरले जवाफ दिने हो भने घरको सुरुङ ठेगानालाई स्रोतको रूपमा अनुमति दिनुपर्छ, र घरको पियरले क्लाउड ठेगानालाई गन्तव्यको रूपमा अनुमति दिनुपर्छ। keepalive प्याकेट प्रमाणित ट्राफिक हुन् र तिनीहरूले उही नियम लागू गर्छन्, त्यसैले काम गरेजस्तो देखिने keepalive काम नगर्ने अनुप्रयोगसँगै रहन सक्छ।
परिवर्तन रोल आउट गर्नुहोस् र यसको सीमा जान्नुहोस्
सेटिङ लागू गर्नुहोस्, यदि त्यो तपाईंको अपडेट विधि हो भने इन्टरफेस पुनः सुरु गर्नुहोस्, अनि तत्काल परीक्षणको सट्टा निष्क्रियता परीक्षण दोहोर्याउनुहोस्। अघि पढेको समयसीमाभन्दा लामो पर्खनुहोस्, उल्टो अनुरोध गर्नुहोस् र दुवै छेउमा काउन्टर चलेको पुष्टि गर्नुहोस्।
अन्तराल र नापिएको समयसीमा त्यसको छेउमा लेख्नुहोस्। भविष्यमा राउटरको फर्मवेयरमा परिवर्तन, वा मोबाइल जडानमा जाँदा समयसीमा बदलिन सक्छ। टिप्पणीले नै कसैलाई मान प्रतिलिपि गर्नुको सट्टा फेरि निकाल्न दिन्छ। एक लाइनमा दुई संख्याले पछि पूरै अनुसन्धान बचाउँछ।
स्थायी keepalive हरूले अवस्था रक्षा गर्छन्। तिनीहरूले पोर्ट खोल्दैनन्, अनुमति दिइएको सूचीमा प्रविष्टि थप्दैनन्, र श्रोता देखा पर्न लगाउँदैनन्। जब उल्टो जडान बिल्कुलै काम गर्दैन, दोष ती तीनमध्ये एउटामा हुन्छ, र WireGuard को द्रुत सुरुवात ले keepalive सेटिङलाई त्यही साँघुरो सर्तहरूमा वर्णन गर्छ।