WireGuard अड्किन्छ: MTU सीमा कि हराएको फर्वार्ड नियम?
सर्भरभन्दा पर केही नचल्नु फर्वार्डिङ वा फिर्ती मार्गको समस्या हो। साना अनुरोध चल्ने र ठूला अड्किने कुरा प्याकेट आकारको लक्षण हो।
WireGuard बिग्रन थालेपछि तुरुन्तै MTU घटाउने बानी पर्छ, र त्यो बानीले अर्को खराबी लुकाउँछ। जुन गेटवेले अगाडि पठाउँदैन र जुन बाटोले ठूला प्याकेट बोक्दैन, तिनले छुट्याउन सकिने ढाँचा बनाउँछन्: एउटा दुवै दिशामा र हरेक आकारमा असफल हुन्छ, अर्को साना अनुरोधमा बाँच्छ र ठूलामा मर्छ। कुनै पनि सङ्ख्या बदल्नु अघि तपाईंसँग कुन आकार छ त्यो निर्धारण गर्नुहोस्। परीक्षण सस्तो छ र सम्भावित कारणको आधा हटाउँछ।
दुई असफलता, दुई फरक आकार
फर्वार्डिङ समस्या सर्भरपछि तुरुन्तै देखिन्छ। ह्यान्डसेक सफल हुन्छ, टनेल ठेगानाले जवाफ दिन्छ, र गेटवेपछाडि सानो अनुरोधले पनि केही पुग्दैन। प्याकेट सर्भरसम्म पुग्यो र अगाडि पठाइएन, वा जवाफसँग फर्कने मार्ग थिएन।
आकारको समस्या एउटा सीमाभन्दा माथि मात्र देखिन्छ। DNS, TCP ह्यान्डसेक र सानो API कल चल्छन्, जबकि फाइल डाउनलोड वा ठूलो जवाफ अड्किन्छ। जो प्याकेट अटाए ती एक छेउबाट अर्को छेउसम्म गए, र जो अटाएनन् ती कतै उपयोगी प्रतिवेदनबिना फालिए।
ती विवरणहरू फरक मानिस र फरक कन्फिगरेसन फाइलतिर सङ्केत गर्छन्, त्यसैले अनुमानभन्दा आकार नाप्नु बढी मूल्यवान् छ। गेटवेमा एउटै पिङले तिनलाई छुट्याउन सक्दैन।
केही सानो बनाउनु अघि फर्वार्डिङ हटाउनुहोस्
गेटवे आफैलाई होइन, गेटवेभन्दा परको गन्तव्य परीक्षण गर्नुहोस्। सर्भरको टनेल ठेगानामा पिङले इन्टरफेस चालु छ र टनेल अन्त्य गर्ने मेसिनसम्म पुग्छौ भन्ने मात्र प्रमाणित गर्छ। फराकिलो सञ्जालको ट्राफिक त्यो मेसिनमा IP फर्वार्डिङ सक्रिय हुनु र फर्वार्ड भएको प्रवाहलाई अनुमति दिने फायरवालमा निर्भर छ। दुवै सत्य हुनुपर्छ, र एउटा असत्य भए उही मौनता आउँछ।
फिर्ती मार्गनिर्देशन पनि उत्तिकै महत्त्वपूर्ण छ। यदि गन्तव्य सञ्जाललाई ग्राहकको टनेल ठेगानामा कसरी पुग्ने थाहा छैन भने अनुरोध आउँछ र जवाफ हराउँछ, र ग्राहकले फालिएको फर्वार्डजस्तै देखिने समय समाप्तिको रिपोर्ट गर्छ।
जहाँ डिजाइनले ठेगाना अनुवाद प्रयोग गर्छ, त्यहाँ अनुवाद नियम त्यो फिर्ती मार्गको भाग हो। MTU समस्याको पछि लाग्दा त्यो हटाउँदा चलिरहेको डिजाइन बिग्रिएको बन्छ, त्यसैले सम्पादन गर्नु अघि विद्यमान नियम पढ्नुहोस्।
भाँचिएको कहाँबाट सुरु हुन्छ नाप्नुहोस्
पहिले फर्वार्डिङको स्थिति र फिल्टर नियम पढ्नुहोस्। यी पढ्ने मात्रका जाँच हुन् र सस्तो प्रश्नको जवाफ दिन्छन्:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9त्यसपछि ग्राहकबाट गेटवेभन्दा परको होस्टतिर, don’t-fragment बिटसहित आकार परीक्षण गर्नुहोस्:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9यदि पहिलो जाँच चल्यो र दोस्रो खण्डीकरण त्रुटिले असफल भयो भने, मार्गले आफ्नो प्रयोगयोग्य आकार बताइरहेको छ। यदि दुवै चलेनन् भने, तपाईं फर्वार्डिङ वा मार्गनिर्देशन हेर्दै हुनुहुन्छ, र MTU बदल्नुपर्ने चल होइन।
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
तपाईंले प्रमाणित गरेको तह सुधार्नुहोस्
जब फर्वार्डिङ खराबी हो, सुधार फर्वार्डिङ नियम वा मार्ग हो, डिजाइनले अनुमति दिएजति साँघुरो रूपमा व्यक्त गरिएको। जब आकार खराबी हो, सुधार त्यो विशेष मार्गको इन्क्याप्सुलेसन हिसाब गर्ने MTU हो, जो आवश्यक पर्ने इन्टरफेसमा लागू हुन्छ, बेडाको हरेक एडाप्टरमा होइन।
जे भए पनि, त्यसपछि उही गन्तव्यमा उही काम दोहोर्याउनुहोस्। यदि मूल ठूलो स्थानान्तरण अब पूरा हुन्छ भने, परिवर्तनले असफल भइरहेको तहलाई सम्बोधन गर्यो। यदि सानो जाँच मात्र सुधारियो भने, तपाईंले लक्षणको उपचार गर्नुभयो र वास्तविक सीमा अझै आफ्नै ठाउँमा छ।
परिवर्तन अघि तपाईंले कुन आकार देख्नुभयो लेख्नुहोस्। सुधारको छेउमा लेखिएको त्यो एक लाइनले नै अर्को व्यक्तिलाई कहिल्यै समस्या नभएको MTU घटाउनबाट रोक्छ।