Bakit bumabara ang VPN sa malalaking paglilipat pero hindi sa maliliit

Naglo-load ang isang pahina, nagtagumpay ang ping, at bumabara ang kopya ng file sa parehong punto tuwing gagawin. Ang pattern na iyon ay tumuturo sa laki ng packet, hindi sa bandwidth o mga kredensyal. Nagdadagdag ng byte ang encapsulation sa bawat packet, kaya ang payload na kasya sa orihinal na ruta ay maaaring lumampas sa limitasyon kapag dumaan sa tunnel. Sa mga usapang ito, tatlong magkaibang numero ang tinatawag na MTU, at ang pagkalito sa kanila ay humahantong sa setting na nag-aayos ng isang app at sumisira ng iba.

Tatlong numero na tinatawag ng mga tao na MTU

Ang MTU ng interface ay ang naka-configure na limitasyon para sa packet sa link na iyon. Ang MTU ng ruta ay ang pinakamaliit na limitasyon sa buong ruta, at ito ay natutuklasan sa halip na naka-configure. Ang TCP MSS ay ang laki ng payload na inaanunsyo ng kabilang dulo na kaya nitong tanggapin, at nagmumula ito sa dalawa pang numero, hindi hiwalay na pisikal na limitasyon.

May panloob at panlabas na pananaw ang isang tunnel. Dinadala ng panlabas na packet ang naka-encapsulate at ang mga header na kailangan ng protocol, kaya ang magagamit na panloob na laki ay mas maliit kaysa pinapayagan ng panlabas na ruta. Iba rin ang ruta patungo sa server ng VPN kaysa ruta ng server patungo sa destinasyon.

Ang pagtuklas ng MTU ng ruta ay nagbibigay-daan sa sender na malaman ang gumaganang laki, ngunit umaasa ito sa pagdating ng feedback. Kapag sinasala ng isang intermediate na aparato ang mga kaugnay na mensahe ng ICMP, patuloy na nagpapadala ang sender ng mga packet na hindi natatapos, at iyon ang klasikong itim na butas. Kitang-kita ang sintomas kapag alam mo ito: nagtagumpay ang handshake, nawawala ang unang payload na buong laki, at sa huli nagre-reset o bumabara ang koneksyon. Walang anuman sa log ng app na mukhang problema sa network.

Subukan ang ruta gamit ang payload na kontrolado mo

Ang isang pagsubok ay ebidensya tungkol sa isang ruta at isang laki, hindi inirerekomendang setting. Gumamit ng host na sumasagot, at baguhin lamang ang laki ng payload.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

Ang unang utos ay nagpapadala ng Linux test na naka-off ang fragmentation at may payload na 1372 byte, at ang pangalawa ay ganoon din sa Windows kung saan itinakda ang payload gamit ang -l. Ang sagot ay nangangahulugang nakalampas ang laking iyon sa ruta. Ang mensaheng kailangan ng fragmentation ay nagbibigay-impormasyon, samantalang ang timeout ay malabo dahil maaaring itapon lang ng host o ng intermediate na aparato ang ICMP.

Ibaba ang laki sa ilang hakbang sa halip na binary search hanggang sa byte. Sinusubukan mong tiyakin kung may pinakamataas na laki, hindi maglathala ng numero para sa bawat network. Ang numerong makikita mo ay para sa rutang ito, protocol na ito at pamilyang ito ng address.

Iba ang fragmentation ng IPv4 at IPv6, kaya walang sinasabi ang resulta ng isang pamilya tungkol sa isa pa. Subukan ang pamilyang aktwal na ginagamit ng app.

Ang MSS clamping ay tumutulong lamang sa TCP

Sa TCP, ang epektibong payload ay pinag-uusapan sa handshake, at maaaring isulat pababa ng router sa ruta ang halagang iyon upang mas maliliit na segment ang ipadala ng dalawang dulo. Iyon ang ginagawa ng MSS clamping, at gumagana ito nang hindi hinahawakan ang client.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

Ang unang tuntunin ay naglalapat ng inanunsyong MSS sa MTU ng ruta para sa mga ipinapasa na TCP handshake, at ang pangalawa ay nagpapakita ng sariling MTU ng tunnel interface upang maihambing mo ito sa pinapayagan ng ruta. Ang clamping ang pinakamaliit na panghihimasok na pag-aayos para sa app na TCP na bumabara pagkatapos ng handshake.

Sa UDP ay wala itong ginagawa. Ang voice o game client na nagpapadala ng malalaking datagram ay ganap na babalewalain ang setting ng MSS, dahil walang handshake na muling isusulat. Kung UDP ang app na bumabagsak, tingnan sa halip ang sariling mga opsyon sa laki ng packet ng client. Magkaiba ang pagbagsak ng dalawang protocol at magkaibang tool ang nag-aayos, kaya nararapat ang protocol sa unang pangungusap ng ticket.

OpenVPN ay naglalabas ng mga opsyon gaya ng tun-mtu, mssfix at mga setting na may kaugnayan sa fragmentation, at ang pag-uugali nila ay nakasalalay sa bersyon at kung ang data channel ay AEAD. Basahin ang manwal para sa bersyong ginagamit, at baguhin ang isang opsyon sa bawat pagkakataon.

Baguhin ang isang sinusuportahang setting at ulitin ang dalawang pagsubok

Panatilihin ang orihinal na profile, baguhin ang isang sinusuportahang halaga, at ulitin kapwa ang maliit na kahilingang gumana at ang malaking paglilipat na nabigo. Kung ang malaki lamang ang nagbago, hinahabol mo ang laki. Kung nagbago ang dalawa, may ibang gumalaw kasama nito.

Ang mas mababang halaga ay maaaring magpababa ng sintomas habang nagdadagdag ng overhead, kaya hindi layunin ang pinakamaliit na posibleng numero. Ang layunin ay laking dinadala ng ruta nang mapagkakatiwalaan at may pinakamaliit na sayang. Itala ang halaga, ruta at bersyon ng client sa ticket, dahil ang parehong numero na ilalapat sa ibang lugar ay haka-haka.

Kung gumagana ang parehong profile mula sa ibang pinagkakatiwalaang network, panatilihin ang pagkakaibang iyon sa diagnosis sa halip na ideklarang naayos ang client. Ang variable na nagbago ay ang ruta, at ang ruta ang sinukat ng pagsubok.