Pagdadala ng Nakapirming 1,500-Byte na Panloob na Packet sa VPN

May pangangailangan kang hindi yumuyuko: dapat matanggap ng kabilang dulo ang parehong 1,500-byte IP packet na inilalabas ng nagpadala, kasama ang mga header. Hindi maaaring ibalot ng tunnel ang packet na iyon kasama ang sarili nitong framing sa loob ng pangalawang 1,500-byte IP packet, kaya may dapat bumigay sa disenyo. Ang pagkakasunod-sunod sa ibaba ang ginagamit ko sa isang window ng pagbabago: isulat ang badyet sa byte, patunayang kaya talagang dalhin ng underlay, pagkatapos ay pumili ng eksaktong isang mekanismo ng pagdadala at kumpirmahin ang panloob na packet sa kabilang dulo.

Isulat ang badyet sa byte bago mag-edit ng profile

Nagdadagdag ng byte ang encapsulation sa maraming layer, at ang kabuuan ay katangian ng iyong profile at hindi konstante na mahahanap mo. Ang pamilya ng address, pagpili ng cipher, protocol ng transport at anumang opsyon sa compression o framing ay nagbabago ng bilang, kaya ang subtraction na kinopya mula sa ibang deployment ay walang halaga bilang badyet. Magsimula sa panloob na pangangailangan, idagdag ang sinusukat na overhead bawat packet ng sarili mong configuration, at isulat ang resultang panlabas na sukat sa ticket ng pagbabago bago may mag-edit ng file.

Dalawang bilang ang nagpapasya sa disenyo: ang pinakamalaking panlabas na packet na dinadala ng ruta nang walang fragmentation, at ang karagdagang byte na kailangan ng iyong encapsulation. Kapag ang una ay mas maliit kaysa sa pangalawa dagdagan ng 1,500, dapat magbago ang isa sa kanila. Nagiging makitid ang pagpili at hindi malikhain, kaya isinusulat ko ang dalawang bilang bago pag-usapan ang mga opsyon. Wala sa layer ng tunnel ang nagko-compress ng mga byte na iyon, at walang isang integer na MTU ang nag-aalis ng pangangailangang ibinigay sa iyo.

Sukatin ang underlay gamit ang do-not-fragment ping

Sukatin ang ruta sa halip na magtiwala sa MTU ng interface, dahil ang pinakamaliit na link sa panlabas na ruta ang mahalaga. Sa Linux, -M do nagtatakda ng do-not-fragment bit at -s kumukuha ng ICMP payload, kaya ang 1,500-byte frame ay sumasagot sa 1,472 byte na payload kapag ibinawas ang 20-byte IP header at 8-byte ICMP header. Itaas ang payload hanggang mabigo ang pagsubok, pagkatapos ay tumalon sa jumbo na sukat upang tingnan kung dinadala ito ng ruta.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Ang rutang pumapasa sa 1,472 at nabibigo sa 8,972 ay hindi kayang magdala ng 1,500-byte na panloob na packet kasama ang overhead sa isang panlabas na packet. Iyon ang sagot na kailangan mo bago buksan ang configuration ng VPN. Ito rin ang nagpapasya kung alin sa dalawang susunod na seksyon ang naaangkop sa iyo, kaya itago ang dalawang resulta ng pagsubok sa tabi ng ticket. Ang manghula dito ay nagkakahalaga ng isang window ng maintenance, dahil ang tunnel na nag-uulat ng sarili bilang up ay walang sinasabi tungkol sa pinakamalaking packet na tatanggapin ng ruta.

Itaas ang MTU ng ruta lamang kung saan sumasang-ayon ang bawat hop

Ang mga jumbo frame ay katangiang end-to-end, hindi setting na binubuksan mo sa dalawang endpoint na nagkataong kinokontrol mo. Bawat switch, router at paglipat ng provider sa panlabas na ruta ay dapat sumang-ayon sa mas malaking sukat, at ang isang 1,500-byte na hop ay tahimik na itatapon ang packet na pinalaki mo lang. Ang pagtataas lamang ng lokal na interface ang klasikong kalahating pagbabago na nagpapakita ng sirang tunnel habang tahimik na nagbabagsak ang underlay.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Palitan ang interface, pagkatapos ay subukan muli ang parehong ruta bago palitan ang anupaman. Kung nabibigo pa rin ang pagsubok, ibalik gamit ang ip link set dev eth1 mtu 1500 at lumipat sa fragmentation sa halip na makipagtalo sa provider tungkol sa link na hindi sa iyo.

Gamitin ang fragmentation ng tunnel kapag hindi kayang lumaki ang underlay

Ang suportadong mekanismo ng fragmentation sa ilalim ng panloob na packet ay nagpapahintulot sa maraming panlabas na packet na magdala ng isang panloob na packet, at muling pinagsasama ito ng kabilang tunnel endpoint bago ibigay ang orihinal sa stack. Ang opsyon na UDP fragment ng Community OpenVPN ay isang implementasyon ng ideyang iyon at hindi kapareho ng ordinaryong IP fragmentation ng panlabas na packet. Dapat tumakbo ang dalawang peer ng bersyon na sumusuporta sa format, at ang data path ay dapat ang inaasahan mo: ang mga OpenVPN 3 client at kernel-accelerated data channel ay may magkaibang limitasyon, kaya ang profile na gumagana sa isang client ay maaaring mabigo sa iba.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Ang ordinaryong panlabas na fragmentation ang ibang opsyon, at ito ang mas mahina. Hindi nagsasagawa ng fragmentation ang mga IPv6 router sa isang forwarded packet, kaya ang sobrang laking panlabas na packet ay namamatay lang at malalaman lang ito ng nagpadala kung ang kaugnay na ICMPv6 message ay makaligtas sa ruta. Inaanyayahan din ng mga fragment ang filtering at pagpapalaki ng pagkalugi, kaya itinuturing ko itong fallback at hindi plano.

Ang stream-based na panlabas na carrier ay umiiwas sa usapin ng sukat sa pamamagitan ng pagsegment ng sarili nitong byte stream, at ang muling nabuong panloob na packet ay maaari pa ring 1,500 byte. Ito ay desisyon sa transport na may sariling gastos, kasama ang kilalang pag-uugali ng TCP sa loob ng TCP, kaya gawin ito nang sinasadya at hindi bilang side effect ng pagtatalo sa MTU.

Kumpirmahin na dumarating nang hindi nagbabago ang panloob na packet

Ang verification ay hindi isang matagumpay na handshake. Kunin sa tunnel interface sa dalawang dulo at ihambing ang sukat at nilalaman ng packet na aktwal na ipinadala ng aplikasyon sa natanggap ng kabilang dulo.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Kung ipinapakita ng capture ang buong sukat na panloob na packet sa kabilang dulo, gumagana ang pagpili ng pagdadala at ang natitirang gawain ay itala ito. Kung wala itong ipinapakita habang nag-uulat ang tunnel bilang up, itinatapon ang panlabas na packet sa isang lugar sa pagitan ng mga endpoint, na nagbabalik sa iyo sa pagsubok at hindi sa mga setting ng cipher.

Itala ang tatlong bagay sa ticket ng pagbabago bago ito isara: ang sinusukat na panlabas na badyet, ang mekanismong pinili mo, at ang command na nagpatunay na nakaligtas ang panloob na packet. Kakailanganin ng susunod na taong hahawak sa tunnel na ito ang tatlo, at wala sa kanila ang maaaring buuin muli mula sa configuration file lamang.