IPsec ઓવરહેડ: મોડ, NAT-T અને અલ્ગોરિધમ બધું જ તેને બદલે છે
એક પ્રકાશિત ઓવરહેડ આંકડો એક માર્ગ પર એક એન્કેપ્સ્યુલેશન વર્ણવે છે. તમારી ટનલ ખરેખર જે હેડરો પર સંમત થાય છે તે ઉમેરો, પછી માર્ગ માપો.
કોઈ માર્ગદર્શિકામાં ક્યાંક એક સંખ્યા હોય છે, સામાન્ય રીતે સાઠ અને એંસી બાઇટ વચ્ચે, જે કોઈએ 1500 માંથી બાદ કરીને ઇન્ટરફેસ MTU મેળવી હતી. તે સંખ્યા એક ચોક્કસ માર્ગ પર એક ચોક્કસ એન્કેપ્સ્યુલેશન વર્ણવે છે. મોડ, બાહ્ય સરનામા કુટુંબ, સાઇફર અથવા NATની હાજરી બદલો, અને ગણિત હવે તમારી ટનલને લાગુ પડતું નથી.
આ સંખ્યા બીજી ટનલમાંથી આવી છે
ઓવરહેડ એ અમૂર્ત રીતે IPsecની ગુણધર્મ નથી. તે એ પેકેટની ગુણધર્મ છે જે ખરેખર બને છે: સંમત મોડ, બાહ્ય હેડર, સંરક્ષણ હેડર, પેડિંગ, અખંડિતતા ક્ષેત્ર અને કદાચ વધારાનું UDP આવરણ.
IPv4 સાથે અને NAT વગરના ટ્રાન્સપોર્ટ મોડ માટે ટાંકાયેલો આંકડો NAT ટ્રાવર્સલ હેઠળ IPv6 સાથેના ટનલ મોડ કરતાં નાનું પેકેટ વર્ણવે છે. બંને પોતપોતાના કિસ્સામાં સાચા છે. તેમાંથી એકને બીજા ડિપ્લોયમેન્ટમાં કોપી કરવી એ જ રીત છે જેનાથી લોકો એવા MTU સુધી પહોંચે છે જે મોટા ટ્રાન્સફર તોડી નાખે છે. નિષ્ફળતા શાંત છે, કારણ કે નાની વિનંતીઓ ચાલુ રહે છે.
ખરેખર હાજર સ્તરો ઉમેરો
બાહ્ય IP હેડરથી શરૂ કરો અને અંદર તરફ જાઓ. ટનલ મોડમાં મૂળ પેકેટ અંદર હોય છે, તેથી બાહ્ય હેડર બદલી નહીં પણ ઉમેરો છે. RFC 4303 ESP હેડર, પેડિંગ અને તેના પછીના અખંડિતતા ડેટાનું વર્ણન કરે છે.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
તેમાંની કોઈ પણ પંક્તિ ડિપ્લોયમેન્ટ વચ્ચે સ્થિર નથી, અને પેડિંગ પંક્તિ એક જ ડિપ્લોયમેન્ટની અંદર પણ સ્થિર નથી. એક જ પ્રકાશિત ઓવરહેડ આંકડો નિરાશ કરે તેનું આખું કારણ આ જ છે.
બે સાઇટ એક જ ટનલ વિશે અસહમત થઈ શકે છે
સંરક્ષિત પેકેટને હજી પણ બાહ્ય માર્ગ પાર કરવો પડે છે, અને બાહ્ય માર્ગ દરેક જગ્યાએ સરખો નથી. PPPoE એક્સેસ લિંક સ્વચ્છ Ethernet સેગમેન્ટ કરતાં ઓછું વહન કરે છે. મોબાઇલ નેટવર્ક વધુ સંકોચાઈ શકે છે, અને પોતાનું ટ્રાફિક ટનલ કરતો પ્રદાતા બીજું એન્કેપ્સ્યુલેશન ઉમેરે છે જે કોઈએ ઉલ્લેખ કર્યો ન હતો. જે ટનલ એક લિંક પર કામ કરે છે અને બીજી પર નિષ્ફળ જાય છે તે બીજી લિંકનું વર્ણન કરે છે, પ્રોટોકોલનું નહીં.
બંને દિશાઓ પણ અલગ હોઈ શકે છે. અસમમિત માર્ગ તમને કામ કરતું અપલોડ અને અટકેલું ડાઉનલોડ આપી શકે છે, જે પેકેટના આકાર તરફ નહીં પણ પહોંચ તરફ જોતાં સુધી એપ્લિકેશનની સમસ્યા જેવું લાગે છે. નાનું ping સફળ થવું પૂર્ણ આકારના પ્રતિભાવ વિશે ઘણું ઓછું સાબિત કરે છે.
બાદબાકી કરવાને બદલે માપો
માર્ગમાંથી પસાર થતું સૌથી મોટું ડેટાગ્રામ શોધો. પછી તેને ઇન્ટરફેસ જે મૂલ્ય જણાવે છે તેની સાથે સરખાવો:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
જવાબો ન આવે ત્યાં સુધી pingનું માપ નીચે લાવો, અને સૌથી મોટા કામ કરતા મૂલ્યને તે માર્ગનું બજેટ ગણો. xfrmનું આઉટપુટ કહે છે કે કયો મોડ અને કયા અલ્ગોરિધમ સંમત થયા, અને તે જ કોઈપણ પ્રામાણિક ગણતરીનું ઇનપુટ છે. કેપ્ચર પુષ્ટિ કરે છે કે તાર પર ESP છે કે UDP-એન્કેપ્સ્યુલેટેડ ESP, અને એ NATનો પ્રશ્ન અનુમાન વિના ઉકેલે છે.
નિયંત્રણ પ્લેન માટે પણ એક મૂલ્ય ફાળવો. IKE હેન્ડશેક પેકેટની રચના ડેટા પેકેટ કરતાં અલગ હોય છે, તેથી હેન્ડશેક કેપ્ચરમાંથી મેળવેલું માપ ડેટા પ્લેનનું MTU નથી.
સંખ્યાને તેની જગ્યાએ મૂકો
ટનલમાંથી TCP માટે, MSS ક્લેમ્પ ઘણી વાર સૌથી ઓછું હસ્તક્ષેપકારી નિયંત્રણ છે, કારણ કે તે ટનલને જ બદલ્યા વિના છેડા જે મોકલે છે તે ઘટાડે છે. રૂટ-આધારિત ટનલ માટે, ટનલ ઇન્ટરફેસનું MTU જાણી જોઈને સેટ કરો અને કેમ તે દસ્તાવેજ કરો. બંને એકસાથે કરીને પછી માપવાથી તમને કયું મદદ કર્યું તે વિશે કોઈ માહિતી મળતી નથી.
ટિકિટમાં સંમત મોડ, બાહ્ય કુટુંબ, NAT સ્થિતિ અને પુનરાવર્તિત લક્ષણ સાથે રાખો. ચાર તથ્યોનો નોંધાયેલો સમૂહ યાદ રાખેલા સ્થિરાંક કરતાં સારો છે, અને આગલા ક્લાયન્ટ અપગ્રેડ સુધી ટકી રહેની આ એકમાત્ર આવૃત્તિ છે.