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 આધારિત સ્વચાલિત ક્લેમ્પિંગ સાથે સાવચેતીથી વર્તો. નિષ્કર્ષ જેટલો સાંકડો, આગલી ઘટનાનું નિદાન તેટલું સરળ.