VPN MTU පිළිබඳ මිථ්‍යා: ඔබේ පැකට් කුඩා වන්නේ ඇයි සහ ඉඩ යන්නේ කොහේද

යමෙක් ඔබට පවසන්නේ VPN "MTU නිසා පැකට් අහිමි වෙනවා" කියාය, ඔබ ටනලය 1400 ට සකසන අතර, සම්ප්‍රේෂණය නැවත ක්‍රියා කරයි. එම ප්‍රතිඵලය රෝග නිර්ණයක් මෙන් දැනේ. සාමාන්‍යයෙන් එය අංක ගණිතමය අහම්බයකි: ඔබ කිසිදා හඳුනා නොගත් සීමාවකට යටින් ගැලපෙන තරම් කුඩා අංකයක් තෝරාගත් අතර, ඊළඟ ජාලයේ වෙනස් අයවැයක් සමඟ එම සීමාවම නැවත හමුවේ.

මෙයින් බොහොමයක් ඇති කරන්නේ මිථ්‍යා දෙකකි. පළමුවැන්න ටනල අතුරුමුහුණතේ MTU එක මාර්ගයේ MTU එක බවයි. දෙවැන්න එන්කැප්සුලේෂන් සඳහා "එක් ශීර්ෂයක්" වැය වන අතර PPPoE සඳහා ගණන් කිරීමට වටිනා කිසිවක් වැය නොවන බවයි. දෙකම ඔබ තෝරන අංකය අත්තනෝමතික ලෙස පෙනෙන ආකාරයෙන් වැරදිය, එය ඇත්තෙන්ම තීරණය වී ඇති විට.

පළමු මිථ්‍යාව: ටනලයේ MTU එක මාර්ගයේ MTU එකයි

ටනල අතුරුමුහුණතක ඔබ සකසන අගය වන්නේ ක්‍රියාත්මක කිරීම පහළට භාර දෙන විශාලතම අභ්‍යන්තර පැකට්ටුව පිළිබඳ දේශීය පොරොන්දුවකි. මාර්ගයේ සැබෑ ධාරිතාව ඔබ සහ දුර කෙළවර අතර එක් එක් සබැඳියේ ගුණාංගයක් වන අතර, මාර්ගය වෙනස් වන විට, ජංගම සම්බන්ධතාවය භාර දෙන විට හෝ රහස්‍ය ගමනාගමනය වෙනත් සමගාමීකරණයක් ගන්නා විට එය වෙනස් විය හැක. සකසා ඇති 1500 ඔබේ සත්කාරකය ගොඩනඟන දේ පවසයි, ජාලය ගෙනයන දේ නොවේ.

මාර්ග-MTU සොයාගැනීම දෙකම සමගි කිරීමට පවතින අතර, එය ප්‍රතිපෝෂණය මත රඳා පවතී. IPv4 හි, පූර්ණ ප්‍රමාණයේ පැකට්ටුවක් ඉදිරියට යැවීමට නොහැකි රවුටරයක් ICMP "fragmentation needed" පණිවිඩයක් යැවිය යුතු අතර, යවන්නා තම ඇස්තමේන්තුව පහත හෙළයි. IPv6 හි සමාන වන්නේ Packet Too Big පණිවිඩයක් වන අතර, රවුටර කිසිසේත් ගමන් මගේ කැබලි නොකරයි. එම ප්‍රතිපෝෂණය පෙරහන් වූ විට, යවන්නා මාර්ගයට ගෙනයා නොහැකි පැකට් නිපදවමින් සිටින අතර, කිසිවක් ඔහුට හේතුව නොපවසයි.

දෙවන මිථ්‍යාව: එන්කැප්සුලේෂන් සඳහා එක් ශීර්ෂයක් වැය වේ

පිටත ස්තර අවංකව ගණන් කරන්න. පිටත IP ශීර්ෂය IPv4 හි බයිට් 20ක් හෝ IPv6 හි 40ක් වේ. NAT හරහා යාමට UDP එන්කැප්සුලේෂන් 8ක් එකතු කරයි. ටනල ප්‍රොටොකෝලය තම ශීර්ෂය, ආරම්භක දෛශිකයක් හෝ නොන්ස්, සයිෆරයේ කොටස් හෝ පෙළගැස්ම සීමාව දක්වා පිරවීම, අවසන් කොටසක් සහ අඛණ්ඩතා පරීක්ෂණ අගයක් එකතු කරයි. ප්‍රොටොකෝලය සහ සයිෆරය අනුව, අභ්‍යන්තර පැකට්ටුව පටන් ගැනීමටත් පෙර එකතුව දස ගණනක් බයිට් වලට පහසුවෙන් ළඟා වේ.

පසුව අභ්‍යන්තර පැකට්ටුවේම ශීර්ෂ සඳහා නැවත අඩු කරන්න. ටනලය තුළ ඇති TCP කොටස තම 20 බයිට් IP ශීර්ෂය සහ 20 බයිට් TCP ශීර්ෂය ගෙනයන අතර, TCP හි MSS MTU වෙතින් ව්‍යුත්පන්න වේ, ටනලයේ නාමික බරෙන් නොවේ. ඒ නිසා ping කුඩා බරක් සමඟ සාර්ථක විය හැකි අතර ගොනු සම්ප්‍රේෂණය නතර වේ: මෙවලම් විවිධ දේ පරීක්ෂා කරන අතර, ඒවායින් එකක් පමණක් පූර්ණ ප්‍රමාණයේ TCP කොටසක් භාවිත කරයි.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

පළමු විධානය සකසා ඇති ටනල MTU වාර්තා කරයි. පරීක්ෂණ දෙක 1472 බයිට් බරක් යවයි, එය IPv4 සහ ICMP ශීර්ෂවල බයිට් 28 සමඟ 1500 බයිට් පැකට්ටුවක් වන අතර, පසුව කුඩා එකක්. විශාල පරීක්ෂණය සම්පූර්ණයෙන් අසාර්ථක වී කුඩා එක සාර්ථක නම්, ඔබට ප්‍රමාණය මත රඳා පවතින දෝෂයක් ඇත, සාමාන්‍ය මාර්ගගත කිරීමේ ගැටලුවක් නොවේ.

තෙවන මිථ්‍යාව: PPPoE තවමත් ඔබට පිරිසිදු 1500 ලබා දෙයි

සාම්ප්‍රදායික PPPoE ප්‍රවේශ සබැඳියක් 1500 බයිට් IP පැකට්ටුවක් ගෙනයන්නේ නැත. PPPoE ශීර්ෂය සහ PPP ප්‍රොටොකෝල ක්ෂේත්‍රය Ethernet රාමුව තුළ බයිට් 8ක් ගන්නා අතර, එය IP පැකට්ටුවට 1492ක් ඉතිරි කරයි. එය RFC 2516 හි විස්තර කර ඇති සාම්ප්‍රදායික සීමාවයි. එවැනි සබැඳියක් මත VPN ධාවනය කරන්නේ නම්, ටනලයේ අතිරික්තය එම 1492 වෙතින් එයි, 1500 වෙතින් නොවේ.

RFC 4638 විශාල PPP බරක් සාකච්ඡා කිරීමේ ක්‍රමයක් නිර්වචනය කරයි, ප්‍රවේශ සාන්ද්‍රකය සහ පාරිභෝගික උපකරණ දෙකම එයට සහාය දෙන විට, එබැවින් "මෙම සම්බන්ධතාවය PPPoE භාවිත කරයි" යන්න පමණක් නිශ්චිත අංකයක් ඔප්පු නොකරයි. දේශීය සැකසුමකට මධ්‍යස්ථ උපාංගයකට එය සඳහා කිසිදා වින්‍යාස නොකළ පැකට්ටුවක් පිළිගැනීමට බල කළ නොහැක, එබැවින් ප්‍රයෝජනවත් ප්‍රශ්නය වන්නේ සබැඳිය ඇත්තෙන්ම කුමක් සාකච්ඡා කළේද යන්නය, ලේබලය කුමක් පවසයිද යන්න නොවේ.

අසාර්ථකත්වය තෝරාගත් ලෙස පෙනෙන්නේ ඇයි

කුඩා ඉල්ලීම් සාර්ථක වී විශාල සම්ප්‍රේෂණ නතර වීම මාර්ග-MTU කළු කුහරයක සම්භාව්‍ය ලක්ෂණයයි. අත්ලාන්තිය, DNS ප්‍රශ්නය සහ API ඇමතුම සියල්ල ගැලපේ; තොග සම්ප්‍රේෂණය එක් සබැඳියක මිය යන පූර්ණ ප්‍රමාණයේ කොටස් නිපදවන අතර, ගැටලුව වාර්තා කළ යුතුව තිබූ ICMP පණිවිඩය කිසිදා නොපැමිණේ. සම්බන්ධතාවය හොඳින් පෙනෙන අතර බාගැනීම එල්ලී යයි, එය මිනිසුන් මාර්ගය වෙනුවට සේවාදායකය දෙස බැලීමට යවයි.

දෙවන, අදාළ වැරැද්ද වන්නේ අංක තුනක් මිශ්‍ර කිරීමයි: අතුරුමුහුණතේ MTU, TCP හි MSS සහ ප්‍රොටොකෝලයේම කැබලි කිරීම හෝ පිරවීම සැකසුම. රවුටරයක MSS තෙරපීම ප්‍රකාශිත MSS නැවත ලියන අතර, එවිට යවන්නා කුඩා කොටස් ගොඩනඟයි; එය ටනල MTU වෙනස් නොකරන අතර UDP රහස්‍ය ගමනාගමනයට උදව් නොකරයි. සම්බන්ධ ලෙස පෙනෙන නිසා තුනටම එකම අංකය දීම යනු හොඳ අභිප්‍රායක වෙනසක් ක්‍රියා කරන සැකසුමක් බිඳ දමන ක්‍රමයයි.

කුමක් වෙනස් කළ යුතුද, කුමන අනුපිළිවෙලකටද

සාක්ෂිවලින් පටන් ගන්න. ඉහත පරීක්ෂණ සමඟ දෝෂය ප්‍රමාණය මත රඳා පවතින බව තහවුරු කරන්න, පසුව සමත් වන කුඩාම ප්‍රමාණය සහ අසාර්ථක වන විශාලතම ප්‍රමාණය සොයාගන්න. ටනලයට දොස් පැවරීමට පෙර ප්‍රවේශ සබැඳියේ සැබෑ MTU පරීක්ෂා කරන්න; PPPoE සබැඳියක් ඔබේ VPN එය ස්පර්ශ කිරීමට පෙරම අයවැය සීමා කරයි. වෙනස ආපසු හැරවිය හැකි වන පරිදි මුල් අගයන් සටහන් කරන්න.

පසුව සේවාලාභියා ලේඛනගත කරන කුඩාම සකස් කිරීම යොදන්න. බොහෝ සේවාලාභීන් ටනල MTU සමඟ MSS අලුත්වැඩියා විකල්පයක් ලබා දෙන අතර, MSS විකල්පය බොහෝ විට TCP සඳහා වඩා හොඳ ලීවරය වන්නේ එය සෑම පැකට්ටුවක්ම කුඩා නොකර යවන්නා වෙත ළඟා වන බැවිනි. එම ගමනාන්තය සහ එම සම්ප්‍රේෂණය නැවත පරීක්ෂා කරන්න, සහ ඔබ නතර වූ අංක සටහන් කරන්න. එක් ප්‍රවේශ ජාලයක ක්‍රියා කරන ටනල අගයක් විශ්වීය නියතයක් නොවේ, ඊළඟ අඩවියට එහිම අයවැයක් ඇත.