කූඩු කළ VPN උමං: විශාල පැකට්වලදී ඇතුළත එක නතර වන්නේ ඇයි
සෑම උමඟක්ම ඊළඟ එක ආරම්භ වීමට පෙර මාර්ගයේ පැකට් අයවැයෙන් කොටසක් වැය කරයි. ශීර්ෂ එකතු කරන්න, විශාල පැකට්වලදී ඇතුළත සැසිය අසාර්ථක වේ.
DNS විසඳේ, SSH සැසිය පවතී, පසුව විශාල උඩුගත කිරීමක් සිරවේ, එම ධාරකයට ping තවමත් පිළිතුරු දෙයි. එම වෙන්වීම බිඳුණු උමඟක් නොව පැකට් ප්‍රමාණයට යොමු කරයි. කූඩු කළ උමං එයට ළඟා වන්නේ එකම උමඟකින් තනිව ළඟා නොවන ප්‍රමාණවලට ය. ඇතුළත සැසිය හොඳයි; එයට තවදුරටත් නොගැළපෙන පැකට් ලබා දෙයි.
මාර්ගයේ MTU ඇත්තටම යන්නේ කොහේද
සෑම ආවරණයක්ම ඊළඟ ස්තරයට වාරය ලැබෙන්නට පෙර බයිට් වැය කරයි. Ethernet මාර්ගයක් පිටත පැකට්ටුවට 1500 බයිට් ලබා දෙයි, පිටත උමඟ එහි ඇතුළත කිසිවක් ලිපිනගත කළ නොහැකිව තම කොටස ගනී. අනුමාන කළ එක් වැය අගයක් වැදගත් වන තරමටම වැරදි වනු ඇත.
ස්තර පිළිවෙලට ලැයිස්තුගත කරන්න: ප්‍රවේශ මාර්ගය, පිටත ප්‍රවාහනය, පිටත උමඟ, ඇතුළත ප්‍රවාහනය, ඇතුළත උමඟ, යෙදුම. සෑම ශීර්ෂයක්ම එක් වරක් ගණන් කරන්න, UDP උමඟේම ශීර්ෂයෙන් හා ටැගයෙන් වෙන් කර තබන්න.
WireGuard ස්තර දෙකක්, එක් වරක් ගණන් කර ඇත
IPv4 ප්‍රවේශ මාර්ගයක් ගන්න, එහි ඇතුළත තවත් WireGuard උමඟක් සහිතව. පිටත ස්තරයට IPv4 බයිට් 20ක්, UDP බයිට් 8ක් සහ 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 පිළිතුරකට සැබෑ සීමාව සැඟවිය හැක, එබැවින් පරීක්ෂාව තර්කයට වඩා වැදගත් වේ.
ඊළඟ පුද්ගලයාට එය හමුවන තැන අයවැය ලියන්න
සෑම ස්තරයකටම එක් පේළියක් සහිත වගුවක් මහපටැඟිලි රීතියකට වඩා කල් පවතී. එය උමඟ රේඛා සටහන අසල තබන්න, එවිට ආතතිය යටතේ කිසිවෙකු ගණනය නැවත නොකරයි.
වැඩි උමං යනු වැඩි යැපීම්, එබැවින් ආපසු හැරවීමේ සැලැස්ම අයවැය අසල තම ස්ථානය දිනා ගනී. සංඛ්‍යා තවමත් නොගැළපෙන්නේ නම්, නැවත අනුමාන කරනවාට වඩා මාර්ගය මැන බලන්න. ඉලක්කය වන්නේ ඔබට ආරක්ෂා කළ හැකි සංඛ්‍යාවක් මිස මතක තබා ගැනීමට එකක් නොවේ.