Mga mito ng MTU sa VPN: bakit lumiit ang iyong mga pakete at saan napupunta ang espasyo

May nagsasabi sa iyo na ang VPN ay "nawawalan ng pakete dahil sa MTU", itinakda mo ang tunnel sa 1400, at gumagana muli ang paglilipat. Ang resultang iyon ay parang diagnosis. Kadalasan ito ay isang pagkakataon sa aritmetika: pumili ka ng bilang na sapat na maliit upang umangkop sa ilalim ng hangganang hindi mo kailanman natukoy, at makikita mo muli ang parehong hangganan sa susunod na network na may ibang badyet.

Dalawang mito ang sanhi ng karamihan nito. Ang una ay ang MTU ng interface ng tunnel ay ang MTU ng landas. Ang pangalawa ay ang encapsulation ay nagkakahalaga ng "isang header" at ang PPPoE ay walang halaga na sulit bilangin. Pareho silang mali sa paraang nagpapakita ng arbitraryong bilang na pinili mo bagaman ito ay aktuwal na tinutukoy.

Mito isa: ang MTU ng tunnel ay ang MTU ng landas

Ang halagang itinatakda mo sa isang interface ng tunnel ay isang lokal na pangako tungkol sa pinakamalaking panloob na pakete na ibibigay ng implementasyon pababa. Ang tunay na kapasidad ng landas ay katangian ng bawat link sa pagitan mo at ng malayong dulo, at maaari itong magbago kapag nagbago ang ruta, kapag inilipat ang mobile na koneksyon, o kapag kumuha ang trapiko ng ibang peering. Ang itinakdang 1500 ay nagsasabi kung ano ang itatayo ng iyong host, hindi kung ano ang dadalhin ng network.

Ang pagtuklas ng MTU ng landas ay umiiral upang pagsamahin ang dalawa, at nakadepende ito sa feedback. Sa IPv4, isang router na hindi makapagpadala ng paketeng buong laki ay dapat magpadala ng mensaheng ICMP "fragmentation needed", at ibinababa ng nagpadala ang kanyang tantiya. Sa IPv6, ang katumbas ay mensaheng Packet Too Big, at ang mga router ay hindi nagfragment sa transit. Kapag ang feedback na iyon ay sinasalang, patuloy na gumagawa ang nagpadala ng mga paketeng hindi kayang dalhin ng landas, at walang nagsasabi sa kanya kung bakit.

Mito dalawa: ang encapsulation ay nagkakahalaga ng isang header

Bilangin ang mga panlabas na layer nang tapat. Ang panlabas na header ng IP ay 20 byte sa IPv4 o 40 sa IPv6. Ang encapsulation ng UDP para sa pagdaan sa NAT ay nagdadagdag ng 8. Ang protocol ng tunnel ay nagdadagdag ng sarili nitong header, isang initialization vector o nonce, padding hanggang sa hangganan ng block o alignment ng cipher, isang trailer at isang halaga ng pagsusuri ng integridad. Depende sa protocol at cipher, ang kabuuan ay komportableng nasa sampung byte bago pa man magsimula ang panloob na pakete.

Pagkatapos ibawas muli ang mga header ng panloob na pakete mismo. Ang isang segment ng TCP sa loob ng tunnel ay may sariling header ng IP na 20 byte at header ng TCP na 20 byte, at ang MSS ng TCP ay nagmumula sa MTU, hindi sa nominal na payload ng tunnel. Iyon ang dahilan kung bakit ang ping na may mas maliit na payload ay maaaring magtagumpay habang ang paglilipat ng file ay natigil: ang mga tool ay sumusubok ng iba't ibang bagay, at isa lamang sa kanila ang gumagamit ng segment ng TCP na buong laki.

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

Ang unang utos ay nag-uulat ng itinakdang MTU ng tunnel. Ang dalawang probe ay nagpapadala ng payload na 1472 byte, na kasama ng 28 byte na header ng IPv4 at ICMP ay isang paketeng 1500 byte, at pagkatapos ay mas maliit. Kung ang malaking probe ay ganap na nabigo at ang maliit ay nagtagumpay, mayroon kang depektong nakadepende sa laki, hindi pangkalahatang problema sa routing.

Mito tatlo: ang PPPoE ay nagbibigay pa rin sa iyo ng malinis na 1500

Ang karaniwang access link ng PPPoE ay hindi nagdadala ng paketeng IP na 1500 byte. Ang header ng PPPoE kasama ang field ng protocol ng PPP ay kumukuha ng 8 byte sa loob ng frame ng Ethernet, na nag-iiwan ng 1492 para sa paketeng IP. Iyon ang tradisyonal na hangganang inilarawan sa RFC 2516. Kung magpapatakbo ka ng VPN sa ganoong link, ang overhead ng tunnel ay nagmumula sa 1492 na iyon, hindi sa 1500.

Ang RFC 4638 ay nagbibigay ng paraan upang makipagnegosasyon ng mas malaking payload ng PPP kapag parehong sinusuportahan ng access concentrator at ng kagamitan ng kliyente, kaya ang "gumagamit ng PPPoE ang koneksyong ito" lamang ay hindi nagpapatunay ng tiyak na bilang. Hindi mapipilit ng lokal na setting ang isang intermediate na aparato na tanggapin ang paketeng hindi kailanman na-configure para dito, kaya ang kapaki-pakinabang na tanong ay kung ano ang aktuwal na naipagkasundo ng link, hindi kung ano ang sinasabi ng label.

Bakit ang kabiguan ay mukhang pili

Ang maliliit na kahilingan ay nagtagumpay at ang malalaking paglilipat ay natigil ay ang klasikong tanda ng isang black hole ng MTU ng landas. Ang handshake, ang query ng DNS at ang tawag sa API ay kasya lahat; ang bulk transfer ay gumagawa ng mga segment na buong laki na namamatay sa isang link, at ang mensaheng ICMP na dapat sana ay nag-ulat ng problema ay hindi kailanman dumarating. Mukhang maayos ang koneksyon at nag-hang ang download, na nagtutulak sa mga tao na tingnan ang server sa halip na ang landas.

Ang pangalawang, kaugnay na pagkakamali ay ang paghahalo ng tatlong bilang: ang MTU ng interface, ang MSS ng TCP at ang setting ng fragmentation o padding ng protocol mismo. Ang clamping ng MSS sa isang router ay nagsusulat muli ng inihayag na MSS upang bumuo ang nagpadala ng mas maliliit na segment; hindi nito binabago ang MTU ng tunnel at hindi nito tinutulungan ang trapikong UDP. Ang pagbibigay ng parehong bilang sa tatlo dahil mukhang magkakaugnay sila ay ang paraan kung paano sinisira ng isang may mabuting hangarin na pagbabago ang isang gumaganang setup.

Ano ang babaguhin, at sa anong pagkakasunod-sunod

Magsimula sa ebidensya. Kumpirmahin sa mga probe sa itaas na ang depekto ay nakadepende sa laki, pagkatapos ay hanapin ang pinakamaliit na laki na pumapasa at ang pinakamalaki na nabibigo. Suriin ang tunay na MTU ng access link bago sisihin ang tunnel; ang link ng PPPoE ay naglilimita sa badyet bago pa man ito hawakan ng iyong VPN. Itala ang orihinal na mga halaga upang maibalik ang pagbabago.

Pagkatapos ay ilapat ang pinakamaliit na pagsasaayos na dokumentado ng kliyente. Maraming kliyente ay nag-aalok ng MTU ng tunnel at opsyon sa pag-aayos ng MSS, at ang opsyon ng MSS ay madalas na mas mabuting lever para sa TCP dahil naaabot nito ang nagpadala nang hindi pinapaliit ang bawat pakete. Subukan muli ang parehong destinasyon at parehong paglilipat, at itala ang mga bilang na kinahantungan mo. Ang halaga ng tunnel na gumagana sa isang access network ay hindi isang unibersal na konstante, at ang susunod na site ay may sariling badyet.