OpenVPN sa PPPoE: babaan ang link-mtu, tun-mtu o mssfix?

Sumasagot ang ping, nagre-resolve ang DNS, at bumabara ang bawat pahina na nangangailangan ng buong segment. Sa isang uplink na nagdadagdag ng sarili nitong encapsulation, tahimik na nawawalan ang landas ng ilang dosenang byte ng badyet, at ang profile na isinulat para sa malinis na Ethernet ay patuloy na humihingi ng mga packet na hindi kayang dalhin ng linya. Hindi mabagal ang koneksyon; itinatapon nito nang eksakto ang mga packet na mahalaga.

Tatlong opsyon ang makakapag-ayos nito, at gumagana sila sa magkaibang layer. Ang maling pagpili ay walang ginagawa o ginagawang marupok ang tunnel sa bagong paraan, kaya ang pagpili ay nagsisimula sa kung ano talaga ang sinusuportahan ng landas.

Tatlong knob, tatlong magkaibang layer

link-mtu ang panlabas na badyet: ang naka-encrypt na payload kasama ang OpenVPN header, UDP header at panlabas na IP header. Inilalarawan nito ang lumalabas sa makina, at iyon ang dahilan kung bakit ito ang bilang na nililimitahan ng pisikal na landas.

tun-mtu ang panloob na badyet: ang interface na nakikita ng iyong trapiko. Mas malaki ito kaysa sa kayang dalhin ng landas nang eksakto sa overhead ng tunnel, at ang OpenVPN ay karaniwang nagde-derive nito sa halip na pilitin kang itakda ito.

mssfix ay ganap na ibang mekanismo. Muling isinusulat nito ang pinakamataas na laki ng segment na inaanunsyo sa mga handshake ng TCP, upang pumili ang mga kapares na TCP ng mga segment na kasya pagkatapos ng encapsulation. Hindi nito binabago ang MTU ng interface, at wala itong epekto sa UDP.

Kung tahasan mong itatakda ang link-mtu, ibinabawas ng OpenVPN ang sarili nitong overhead upang makuha ang panloob na MTU. Ang overhead na iyon ay hindi fixed na constant; nakadepende ito sa cipher at authentication, kaya ang value na kinopya mula sa forum ay maaaring mali sa ibang profile. Ang pagtatakda ng parehong link-mtu at tun-mtu ay nagbibigay sa client ng dalawang magkasalungat na tagubilin.

Sukatin ang landas bago pumili ng anumang bilang

Sukatin mula sa pisikal na interface, hindi mula sa loob ng tunnel, at tandaan na ang ping ay nag-uulat ng payload, hindi ng laki ng packet. Magdagdag ng 28 byte para sa IPv4 at ICMP header bago ihambing ang payload sa isang 1500-byte na frame, at isaisip ang pagwawasto na iyon kapag may kapares na nag-uulat ng ibang bilang.

Sa isang Linux client, ipinagbabawal ng ping -M do -s 1472 ang fragmentation at nabigo kung masyadong malaki ang packet. Bawasan ang payload hanggang makalusot, pagkatapos ay magdagdag ng 28 upang makuha ang MTU ng landas. Ang PPPoE ay kumakain ng 8 byte, kaya normal ang 1492 sa DSL. Ang DS-Lite at ilang mobile na landas ay kumakain ng 40 o higit pa, at ang sagot ay karaniwang mas mababa kaysa sa iminumungkahi ng nominal na bilis ng link.

Kung nagtagumpay ang bawat laki ng ping ngunit bumabara pa rin ang malalaking transfer, maghinala ng black hole sa halip na simpleng limitasyon sa laki. Ang ICMP na mensahe tungkol sa kinakailangang fragmentation ay sinasala sa isang lugar sa landas, kaya hindi natututo ang nagpapadala na magpaliit, at ang mga daloy lamang na nangangailangan ng malaking segment ang nakakapansin.

Limitahan muna ang TCP, pagkatapos ay paliitin ang tunnel

Ang mga handshake ng TCP ang tanging bagay na hinahawakan ng mssfix, na kadalasang ginagawa itong pinakamaliit na nakikialam na kontrol na dapat subukan muna. Itakda ito nang bahagya sa ilalim ng tunay na badyet ng landas, ipadala ang parehong value mula sa server upang magkasundo ang dalawang dulo, at muling subukan ang malaking download. Kung mawala ang pagbara, ang problema ay ang laki ng segment ng TCP, at wala nang ibang kailangang baguhin.

Babaan ang panloob na MTU kapag ang apektadong trapiko ay hindi TCP. Ang isang serbisyong UDP, isang tunnel sa loob ng tunnel o isang application na nagpapadala ng buong-laki na datagram ay patuloy na mabibigo pagkatapos ng limitasyon sa MSS dahil walang muling nagsusulat ng laki ng packet nito. Bawasan ang tun-mtu para sa kasong iyon, o itakda ang link-mtu at hayaang kunin ng client ang panloob na value, ngunit hinding-hindi pareho.

Huwag abutin ang lumang opsyon sa fragmentation. Hinahati nito ang mga packet sa loob ng tunnel, nagdadagdag ng overhead, at inalis dahil sa magagandang dahilan; inaasahan ng modernong OpenVPN na tumpak na inilalarawan ang landas.

Bakit patuloy na gumagana ang maliliit na pagsubok

Ang mga query ng DNS, echo ng ICMP at handshake ng TCP ay pawang malayo sa ilalim ng laking nabibigo. Kaya mukhang malusog ang tunnel sa bawat mabilis na pagsubok habang tahimik na nabibigo ang mga handshake ng TLS at mga tugon ng HTTP. Iyon mismong kombinasyon, isang gumaganang traceroute at isang browser na bumabara sa unang malaking tugon, ang tandang dapat hanapin. Abutin ang isang buong-laki na pagsubok bago abutin ang isang bagong profile.

I-verify gamit ang trapikong nabigo. Kumuha ng malaking pahina, magpadala ng buong-laki na UDP datagram kung iyon ang apektadong serbisyo, at ulitin mula sa pangalawang client sa ibang uplink. Itala ang sinukat na MTU ng landas at ang value na pinili mo, dahil kung hindi ay ituturing ng susunod na taong hihawak sa profile ang bilang na iyon na arbitraryo.

Huwag kailanman ibaba ang panloob na MTU sa ilalim ng 1280 kapag tumatakbo ang IPv6 sa tunnel, dahil iyon ang pinakamababang dapat dalhin ng bawat link ng IPv6. Ang mas maliit na MTU ay katotohanan tungkol sa landas, hindi isang setting ng performance na iniayon sa pakiramdam.