VPN દ્વારા નિશ્ચિત 1,500 બાઇટનું આંતરિક પેકેટ વહન કરો

તમારી પાસે એક જરૂરિયાત છે જે નમતી નથી: દૂરની બાજુએ એ જ 1,500 બાઇટનું IP પેકેટ મળવું જોઈએ જે મોકલનાર મોકલે છે, હેડર સહિત. ટનલ તે પેકેટને પોતાના ફ્રેમિંગ સાથે બીજા 1,500 બાઇટના IP પેકેટની અંદર લપેટી શકતી નથી, તેથી ડિઝાઇનમાં કંઈક ઘટવું પડશે. નીચેનો ક્રમ એ છે જે હું ફેરફાર વિન્ડોમાં વાપરું છું: બાઇટ બજેટ લખો, અંડરલે ખરેખર શું વહન કરી શકે તે સાબિત કરો, પછી બરાબર એક વહન પદ્ધતિ પસંદ કરો અને દૂરની બાજુએ આંતરિક પેકેટની પુષ્ટિ કરો.

પ્રોફાઇલ સંપાદિત કરતા પહેલા બાઇટ બજેટ લખો

એન્કેપ્સ્યુલેશન ઘણા સ્તરો પર બાઇટ ઉમેરે છે, અને કુલ સંખ્યા તમારી પ્રોફાઇલની લાક્ષણિકતા છે, એવો સ્થિરાંક નહીં જે તમે શોધી શકો. એડ્રેસ ફેમિલી, સાઇફરની પસંદગી, ટ્રાન્સપોર્ટ પ્રોટોકોલ અને કોઈપણ કમ્પ્રેશન કે ફ્રેમિંગ વિકલ્પ આ સંખ્યા બદલે છે, તેથી બીજા ડિપ્લોયમેન્ટમાંથી કોપી કરેલી બાદબાકી બજેટ તરીકે નકામી છે. આંતરિક જરૂરિયાતથી શરૂ કરો, તમારા પોતાના કન્ફિગરેશનનો માપેલો પ્રતિ-પેકેટ ઓવરહેડ ઉમેરો, અને પરિણામી બાહ્ય કદ કોઈ ફાઇલ સંપાદિત કરે તે પહેલા ફેરફાર ટિકિટ પર લખો.

બે સંખ્યાઓ ડિઝાઇન નક્કી કરે છે: પાથ ફ્રેગમેન્ટેશન વિના વહન કરે તે સૌથી મોટું બાહ્ય પેકેટ, અને તમારા એન્કેપ્સ્યુલેશનને જરૂરી વધારાના બાઇટ. જ્યારે પ્રથમ બીજા વત્તા 1,500 કરતાં નાનું હોય, ત્યારે તેમાંથી એક બદલવું પડશે. પછી પસંદગી સર્જનાત્મક નહીં પણ સાંકડી હોય છે, તેથી વિકલ્પો ચર્ચા પહેલા હું બંને સંખ્યાઓ લખી લઉં છું. ટનલ સ્તરે કંઈ પણ તે બાઇટને કમ્પ્રેસ કરી નાખતું નથી, અને કોઈ એક પણ MTU પૂર્ણાંક તમને આપેલી જરૂરિયાત દૂર કરતો નથી.

નો-ફ્રેગમેન્ટ પિંગ સાથે અંડરલે ચકાસો

ઇન્ટરફેસ MTU પર ભરોસો કરવાને બદલે પાથ માપો, કારણ કે બાહ્ય પાથમાં સૌથી નાની કડી મહત્ત્વની છે. Linux માં -M do નો-ફ્રેગમેન્ટ બિટ સેટ કરે છે અને -s ICMP પેલોડ લે છે, તેથી 1,500 બાઇટની ફ્રેમ 20 બાઇટનું IP હેડર અને 8 બાઇટનું ICMP હેડર બાદ કર્યા પછી 1,472 બાઇટ પેલોડ પર જવાબ આપે છે. પેલોડ વધારતા જાઓ જ્યાં સુધી ચકાસણી નિષ્ફળ ન જાય, પછી જમ્બો સાઇઝ પર કૂદો કે પાથ તેને બિલકુલ વહન કરે છે કે નહીં.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

જે પાથ 1,472 પાસ કરે છે અને 8,972 પર નિષ્ફળ જાય છે તે 1,500 બાઇટનું આંતરિક પેકેટ વત્તા ઓવરહેડ એક બાહ્ય પેકેટમાં વહન કરી શકતું નથી. VPN કન્ફિગરેશન ખોલતા પહેલા તમને આ જ જવાબની જરૂર હતી. તે એ પણ નક્કી કરે છે કે આગલા બે વિભાગોમાંથી કયો તમને લાગુ પડે છે, તેથી બંને ચકાસણી પરિણામો ટિકિટ પાસે રાખો. અહીં અનુમાન કરવાથી એક જાળવણી વિન્ડોનો ખર્ચ થાય છે, કારણ કે પોતાને ચાલુ જાહેર કરતી ટનલ પાથ કયું સૌથી મોટું પેકેટ સ્વીકારશે તે વિશે કંઈ કહેતી નથી.

પાથ MTU ફક્ત ત્યાં જ વધારો જ્યાં દરેક હોપ સહમત હોય

જમ્બો ફ્રેમ એન્ડ-ટુ-એન્ડ ગુણધર્મ છે, તમે નિયંત્રિત કરો છો તે બે એન્ડપોઇન્ટ પર ચાલુ કરવાની સેટિંગ નહીં. બાહ્ય પાથ પરના દરેક સ્વિચ, રાઉટર અને પ્રોવાઇડર હેન્ડઓફને મોટા કદ સાથે સહમત થવું પડશે, અને એક જ 1,500 બાઇટનો હોપ તમે હમણાં મોટું કરેલું પેકેટ ચૂપચાપ ફેંકી દેશે. ફક્ત સ્થાનિક ઇન્ટરફેસ વધારવું એ જાણીતો અડધો ફેરફાર છે જેમાં ટનલ તૂટેલી લાગે છે જ્યારે અંડરલે ચૂપચાપ પડી જાય છે.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

ઇન્ટરફેસ બદલો, પછી બીજું કંઈ બદલતા પહેલા એ જ પાથ ફરી ચકાસો. જો ચકાસણી હજી પણ નિષ્ફળ જાય, તો ip link set dev eth1 mtu 1500 થી પાછું ફેરવો અને તમારી માલિકીની ન હોય તેવી કડી માટે પ્રોવાઇડર સાથે દલીલ કરવાને બદલે ફ્રેગમેન્ટેશન તરફ જાઓ.

જ્યારે અંડરલે વધી શકતું ન હોય ત્યારે ટનલ ફ્રેગમેન્ટેશન વાપરો

આંતરિક પેકેટની નીચે સમર્થિત ફ્રેગમેન્ટેશન પદ્ધતિ ઘણાં બાહ્ય પેકેટને એક આંતરિક પેકેટ વહન કરવા દે છે, અને દૂરનું ટનલ એન્ડપોઇન્ટ મૂળને સ્ટેક પર આપતા પહેલા તેમને ફરી જોડે છે. Community OpenVPN નો UDP ફ્રેગમેન્ટ વિકલ્પ તે વિચારનો એક અમલીકરણ છે, અને તે બાહ્ય પેકેટના સામાન્ય IP ફ્રેગમેન્ટેશન જેવું જ નથી. બંને પક્ષોએ ફોર્મેટને સમર્થન આપતું સંસ્કરણ ચલાવવું પડશે, અને ડેટા પાથ તમે ધારો છો તે જ હોવો જોઈએ: OpenVPN 3 ક્લાયન્ટ અને કર્નલ-એક્સેલરેટેડ ડેટા ચેનલની મર્યાદા અલગ છે, તેથી એક ક્લાયન્ટ પર ચાલતી પ્રોફાઇલ બીજા પર નિષ્ફળ જઈ શકે છે.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

સામાન્ય બાહ્ય ફ્રેગમેન્ટેશન બીજો વિકલ્પ છે, અને તે નબળો છે. IPv6 રાઉટર ફોર્વર્ડ કરેલા પેકેટનું ફ્રેગમેન્ટેશન બિલકુલ કરતા નથી, તેથી ખૂબ મોટું બાહ્ય પેકેટ સીધું મરી જાય છે અને મોકલનારને તેની ખબર ફક્ત ત્યારે પડે છે જ્યારે સંબંધિત ICMPv6 સંદેશ પાથ પાર કરે. ફ્રેગમેન્ટ ફિલ્ટરિંગ અને લોસ એમ્પ્લિફિકેશનને પણ આમંત્રે છે, તેથી હું તેને યોજના નહીં પણ બેકઅપ તરીકે ગણું છું.

સ્ટ્રીમ-આધારિત બાહ્ય વાહક પોતાનો બાઇટ સ્ટ્રીમ સેગમેન્ટ કરીને કદનો પ્રશ્ન ટાળે છે, અને પુનર્નિર્મિત આંતરિક પેકેટ હજી 1,500 બાઇટ હોઈ શકે છે. તે પોતાનો ખર્ચ ધરાવતો ટ્રાન્સપોર્ટ નિર્ણય છે, જેમાં TCP ની અંદર TCP ની જાણીતી વર્તણૂકનો સમાવેશ થાય છે, તેથી તેને MTU ચર્ચાની આડઅસર નહીં પણ જાણી જોઈને લો.

ખાતરી કરો કે આંતરિક પેકેટ અપરિવર્તિત પહોંચે છે

ચકાસણી એ સફળ હેન્ડશેક નથી. બંને છેડે ટનલ ઇન્ટરફેસ પર કેપ્ચર કરો અને એપ્લિકેશને ખરેખર મોકલેલા પેકેટનું કદ અને સામગ્રી દૂરની બાજુએ મળેલા પેકેટ સાથે સરખાવો.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

જો કેપ્ચર દૂરના છેડે પૂર્ણ કદનું આંતરિક પેકેટ દર્શાવે, તો વહનની પસંદગી કામ કરે છે અને બાકીનું કામ તેને નોંધવાનું છે. જો ટનલ પોતાને ચાલુ જાહેર કરે ત્યારે કંઈ દેખાય નહીં, તો બાહ્ય પેકેટ એન્ડપોઇન્ટ વચ્ચે ક્યાંક ફેંકાઈ રહ્યું છે, જે તમને સાઇફર સેટિંગ્સ નહીં પણ ચકાસણી તરફ પાછા લઈ જાય છે.

ટિકિટ બંધ કરતા પહેલા ત્રણ વસ્તુઓ નોંધો: માપેલું બાહ્ય બજેટ, તમે પસંદ કરેલી પદ્ધતિ અને એ આદેશ જેણે સાબિત કર્યું કે આંતરિક પેકેટ ટકી ગયું. આ ટનલને અડનારી આગલી વ્યક્તિને ત્રણેયની જરૂર પડશે, અને એક પણ ફક્ત કન્ફિગરેશન ફાઇલમાંથી ફરી બનાવી શકાતું નથી.