નેસ્ટેડ VPN ટનલ: મોટા પેકેટ પર અંદરની ટનલ કેમ અટકે છે
દરેક ટનલ આગલી શરૂ થાય તે પહેલાં પાથના પેકેટ બજેટનો ભાગ ખર્ચે છે. હેડર ઉમેરો અને મોટા પેકેટ પર અંદરનું સત્ર નિષ્ફળ જાય છે.
DNS ઉકેલાય છે, SSH સત્ર ચાલુ રહે છે, અને પછી મોટું અપલોડ અટકી જાય છે જ્યારે તે જ હોસ્ટ પરનું ping હજી પણ જવાબ આપે છે. એ વિભાજન તૂટેલા ટનલ તરફ નહીં, પણ પેકેટના કદ તરફ ઇશારો કરે છે. નેસ્ટેડ ટનલ એવા કદ સુધી પહોંચે છે જે કોઈ એક ટનલ એકલું ન પહોંચી શકે. અંદરનું સત્ર ઠીક છે; તેને એવા પેકેટ આપવામાં આવે છે જે હવે બંધ બેસતા નથી.
પાથ MTU ખરેખર ક્યાં જાય છે
દરેક એન્કેપ્સ્યુલેશન આગલા સ્તરને વારો મળે તે પહેલાં બાઇટ ખર્ચે છે. Ethernet પાથ બહારના પેકેટને 1500 બાઇટ આપે છે, અને બહારની ટનલ તેની અંદર કંઈ પણ સરનામું મળે તે પહેલાં પોતાનો હિસ્સો લઈ લે છે. એક અનુમાનિત ઓવરહેડ મૂલ્ય બરાબર તેટલું જ ખોટું હશે જેટલું મહત્ત્વનું છે.
સ્તરોને ક્રમમાં સૂચિબદ્ધ કરો: એક્સેસ પાથ, બહારનું પરિવહન, બહારની ટનલ, અંદરનું પરિવહન, અંદરની ટનલ, એપ્લિકેશન. દરેક હેડર એક વાર ગણો, અને UDP ને ટનલના પોતાના હેડર અને ટેગથી અલગ રાખો.
બે WireGuard સ્તર, એક વાર ગણાયેલા
એક IPv4 એક્સેસ પાથ લો, તેની અંદર બીજી WireGuard ટનલ સાથે. બહારનું સ્તર 20 બાઇટ IPv4, 8 બાઇટ UDP અને WireGuard ડેટા હેડર તથા તેના પ્રમાણીકરણ ટેગ માટે 32 બાઇટ ખર્ચે છે. તેની અંદર અંદરની ટનલને પોતાનું 20 બાઇટનું IPv4 હેડર અને 8 બાઇટનું UDP હેડર જોઈએ, તેના બીજા 32 બાઇટ WireGuard ઓવરહેડ પહેલાં. જે બાકી રહે છે તે IPv4 હેડર, TCP હેડર અને ડેટા સમાવે છે. બહારનો IPv6 પાથ 20ને બદલે 40 ખર્ચે છે અને 1320 બાકી રાખે છે.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
ગણતરી 1340 બાઇટ પર આવે છે. એક જ સ્તર એ જ નિયમો હેઠળ TCP પેલોડ માટે 1400 બાકી રાખે છે, એટલે કે 1500 ઓછા 20, 8, 32, 20 અને 20, અને 60 બાઇટનો તફાવત બરાબર એ જ અંદરનું એન્કેપ્સ્યુલેશન છે જે બીજી ટનલ ઉમેરે છે.
1400 ને નેસ્ટેડ પાથ પર લાગુ કરો અને અંદરની ટનલ 60 બાઇટ ઓછી પડે છે, જે પેકેટ પૂરતું મોટું ન થાય ત્યાં સુધી અદ્રશ્ય રહે છે. પેડિંગ અને પ્રોટોકોલનો પોતાનો ફ્રેગ્મેન્ટેશન વિકલ્પ આંકડા ફરી ખસેડે છે, તેથી ટેબલ પર ભરોસો રાખો.
MTU, MSS અને ફ્રેગ્મેન્ટેશન અલગ અલગ જગ્યાએ કામ કરે છે
ઇન્ટરફેસ MTU મર્યાદિત કરે છે કે ઇન્ટરફેસ શું મોકલશે, જ્યારે TCP MSS ક્લેમ્પિંગ બદલે છે કે TCP સાથી શું મોકલવા તૈયાર છે. ક્લેમ્પિંગ TCP સત્રો સુધારે છે અને મોટા UDP ડેટાગ્રામ માટે કંઈ કરતું નથી, એ રીતે એક સુધારો એક એપ્લિકેશન માટે સફળ દેખાય છે અને આગલીને ચૂપચાપ ચૂકી જાય છે. પ્રોટોકોલનો પોતાનો ફ્રેગ્મેન્ટેશન વિકલ્પ પોતાની નિષ્ફળતાઓ સાથે ત્રીજો લીવર છે. ઇન્ટરફેસ MTU સામાન્ય પહેલું પગલું અને સૌથી કઠોર છે.
બ્રિજ્ડ અને રાઉટેડ ટનલ અલગ ફ્રેમ વહન કરે છે, તેથી બીજા ડિપ્લોયમેન્ટના આંકડા ભાગ્યે જ લાગુ પડે છે. પાથ MTU ડિસ્કવરી, જેનું વર્ણન RFC 8201 માં છે, ફક્ત ત્યારે જ મદદ કરે છે જ્યારે તેના પર નિર્ભર ICMP સંદેશાઓને પસાર થવા દેવામાં આવે.
ઓછું પડતું સ્તર શોધવું
જરૂરિયાતો સરખામણીની મંજૂરી આપે તો, નેસ્ટ કરતા પહેલાં દરેક ટનલ અલગથી ચકાસો. નિશ્ચિત કદની પ્રોબ આ નક્કી કરે છે: ping -M do -s 1472 -c 3 10.8.0.1 તે સ્તરની અંદર 1500 બાઇટનું પૂર્ણ IPv4 પેકેટ મોકલે છે. બીજું સ્તર ઉમેરો અને એ જ પ્રોબ પુનરાવર્તિત કરો, જેથી કોઈ પણ નિષ્ફળતા જાણીતા ફેરફારની હોય.
જ્યારે ટ્રાન્સફર અટકે, ત્યારે એક વારમાં એક દસ્તાવેજી પરિમાણ બદલો અને નિષ્ફળ થતું કદ નોંધો. પરત માર્ગ પણ તપાસો, કારણ કે નેસ્ટેડ રૂટ રિકર્ઝન પેકેટ-કદની સમસ્યાને એટલી નજીકથી નકલ કરી શકે છે કે એક બપોર ખર્ચી નાખે. ફિલ્ટર કરેલો ICMP જવાબ સાચી મર્યાદા છુપાવી શકે છે, તેથી પ્રોબ તર્ક કરતાં વધુ મહત્ત્વની છે.
બજેટ એ જગ્યાએ લખો જ્યાં આગલી વ્યક્તિને તે મળશે
દરેક સ્તર માટે એક પંક્તિવાળું ટેબલ અંગૂઠાના નિયમ કરતાં વધુ ટકે છે. તેને ટનલ ડાયાગ્રામની બાજુમાં રાખો જેથી દબાણ હેઠળ કોઈ ગણતરી ફરી ન કરે.
વધુ ટનલ એટલે વધુ નિર્ભરતા, તેથી રોલબેક યોજના બજેટની બાજુમાં પોતાનું સ્થાન લાયક છે. જો આંકડા હજી મળતા ન હોય, તો ફરી અનુમાન કરવાને બદલે પાથ માપો. ધ્યેય એ આંકડો છે જેનું તમે રક્ષણ કરી શકો, યાદ રાખી શકો તેવો નહીં.