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 कमी करण्यापासून रोखते।