Linux IPsec गेटवेमा TCP MSS क्ल्याम्पिङ: यसले के सुधार्छ

Ping काम गर्छ, SSH काम गर्छ, एउटा सानो पृष्ठ लोड हुन्छ, र त्यसपछि हरेक ठूलो प्रतिक्रिया समय सकिएसम्म अड्किन्छ। परम्परागत ढाँचाले पहुँचयोग्यता होइन, प्याकेटको आकारतर्फ संकेत गर्छ: मार्गले ह्यान्डशेक र पहिलो केही किलोबाइट बोक्छ, त्यसपछि पूर्ण आकारको खण्ड हराउँछ। Linux IPsec गेटवेमा TCP MSS नियम प्रायः समाधान हो, तर यसले के बदल्छ र यसले छुने प्याकेट वास्तवमा कहाँ छ भन्ने बुझेमा मात्र। तलको क्रमले लक्षणदेखि नियमको स्थानसम्म प्याकेटलाई पछ्याउँछ, ताकि व्याख्या मिल्न छाड्ने बित्तिकै तपाईं रोक्न सक्नुहुन्छ।

MSS तर्फ संकेत गर्ने लक्षण

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

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

TCPMSS नियमले के गर्छ र के गर्दैन

नियमले TCP ह्यान्डशेक प्याकेटहरू पार हुँदा तिनमा भएको MSS विकल्प पुनः लेख्छ। यसले सुरुङ इन्टरफेसको MTU सेट गर्दैन, IPsec नीति बदल्दैन, र हालका कर्नेलमा पहिले नै सानो भएको मान बढाउनुको सट्टा घोषित मान घटाउँछ। यसले TCP मात्र छुन्छ; UDP पेलोड, DNS व्यवहार र वार्ता गरिएका ट्राफिक चयनकर्ता यसको पहुँचबाहिर छन्।

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

नियमलाई भित्री TCP मार्गमा राख्नुहोस्

नीतिमा आधारित Linux गेटवेमा, फायरवालले देख्दा अगाडि पठाइएको प्याकेट अझै साधारण TCP जस्तै देखिन्छ। IPsec नीतिले प्याकेट सुरक्षित हुने निर्णय गर्छ; फायरवालले भित्री प्रवाहका लागि ESP हेडर देख्दैन, त्यसैले यहाँ ESP सँग मिलाउनु पूर्ण रूपमा अर्को प्याकेटको वर्णन गर्छ। त्यही असंगतिले केही नियम सही देखिने र कहिल्यै नमिल्ने हुन्छ।

iptables का सर्तमा नियम अगाडि पठाउने मार्गको mangle तालिकामा पर्छ, ह्यान्डशेक प्याकेटमा सीमित: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270। संख्या एउटा उदाहरण हो, सार्वभौमिक स्थिरांक होइन; यसलाई एन्क्याप्सुलेसन ओभरहेड र मार्गको वास्तविक MTU बाट निकाल्नुहोस्। nftables को समतुल्यले forward वा postrouting शृंखलामा अधिकतम खण्ड आकार सेट गर्छ।

IKE र ESP का बाह्य सुन्ने नियमहरूलाई भित्री अगाडि पठाउने नियमहरूबाट अलग राख्नुहोस्। अनुप्रयोगको प्रवाह र बाह्य प्रोटोकल दुवैलाई अधिकृत गर्न खोज्ने एउटै नियम अन्ततः दुवैमध्ये कसैसँग पनि भरपर्दो रूपमा मिल्दैन।

फायरवालको मालिक र NAT क्रमको सम्मान गर्नुहोस्

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

स्रोत अनुवाद यससँग प्रायः अन्तरक्रिया गर्ने छुट्टै निर्णय हो। सामान्य masquerade नियमअघि राखिएको छुटले सुरक्षित ट्राफिकले आफ्नो नीतिले माग गर्ने स्रोत गुमाउनबाट रोक्छ; यसले आकारको समस्या सुधार्दैन, र आकारको नियमले अनुवादको समस्या सुधार्दैन।

साँघुरो रूपमा प्रमाणित गर्नुहोस्, त्यसपछि रोक्नुहोस्

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

नीतिले अनुमति दिने ठाउँमा ICMP आकार-प्रतिक्रिया काम गरिरहन दिनुहोस्, र बाह्य IPsec मार्ग भित्री रुटद्वारा प्रतिनिधित्व नभएको बेला मार्ग-MTU आधारित स्वचालित क्ल्याम्पिङलाई सावधानीपूर्वक व्यवहार गर्नुहोस्। निष्कर्ष जति साँघुरो, अर्को घटनाको निदान त्यति सजिलो।