Kubeba Pakiti ya Ndani Isiyobadilika ya Baiti 1,500 Kupitia VPN

Una sharti lisilonyumbulika: upande wa mbali lazima upokee pakiti ile ile ya IP ya baiti 1,500 ambayo mtumaji hutoa, pamoja na vichwa. Tunnel haiwezi kufunga pakiti hiyo pamoja na fremu yake mwenyewe ndani ya pakiti ya pili ya IP ya baiti 1,500, kwa hivyo kitu katika muundo lazima kikubali kubadilika. Mpangilio ulio hapa chini ndio ninaotumia katika dirisha la mabadiliko: andika bajeti ya baiti, thibitisha kile underlay inaweza kubeba kwa kweli, kisha chagua utaratibu mmoja tu wa usafirishaji na uthibitishe pakiti ya ndani upande wa pili.

Andika bajeti ya baiti kabla ya kuhariri wasifu

Encapsulation inaongeza baiti katika tabaka kadhaa, na jumla ni sifa ya wasifu wako na si thabiti unayoweza kuipata. Familia ya anwani, uchaguzi wa cipher, itifaki ya usafirishaji na chaguo lolote la ukandamizaji au fremu huhamisha nambari, kwa hivyo kutoa kunakopakuliwa kutoka usanidi mwingine hakuna thamani kama bajeti. Anza na sharti la ndani, ongeza overhead iliyopimwa kwa kila pakiti ya usanidi wako, na andika ukubwa wa nje unaotokana na tiketi ya mabadiliko kabla ya mtu yeyote kuhariri faili.

Nambari mbili huamua muundo: pakiti kubwa zaidi ya nje ambayo njia hubeba bila fragmentesheni, na baiti za ziada ambazo encapsulation yako inahitaji. Wakati ya kwanza ni ndogo kuliko ya pili pamoja na 1,500, moja yao lazima ibadilike. Uchaguzi basi huwa mwembamba na si wa ubunifu, kwa hivyo ninaandika nambari zote mbili kabla ya kujadili chaguo. Hakuna kitu kwenye tabaka la tunnel kinachokandamiza baiti hizo, na hakuna nambari kamili moja ya MTU inayoondoa sharti ulilopewa.

Chunguza underlay kwa ping do-not-fragment

Pima njia badala ya kuamini MTU ya kiolesura, kwa sababu kiungo kidogo zaidi katika njia ya nje ndicho cha muhimu. Kwenye Linux, -M do huweka biti do-not-fragment na -s huchukua payload ya ICMP, kwa hivyo fremu ya baiti 1,500 hujibu kwa baiti 1,472 za payload baada ya kutoa kichwa cha IP cha baiti 20 na kichwa cha ICMP cha baiti 8. Ongeza payload hadi jaribio lishindwe, kisha ruka hadi ukubwa wa jumbo kuona kama njia inaibeba kabisa.

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

Njia inayopita 1,472 na kushindwa kwa 8,972 haiwezi kubeba pakiti ya ndani ya baiti 1,500 pamoja na overhead katika pakiti moja ya nje. Hilo ni jibu ulilohitaji kabla ya kufungua usanidi wa VPN. Pia huamua ni sehemu ipi kati ya mbili zinazofuata inakuhusu, kwa hivyo weka matokeo yote mawili ya uchunguzi karibu na tiketi. Kukisia hapa hugharimu dirisha moja la matengenezo, kwa sababu tunnel inayojiripoti kuwa up haikwambii chochote kuhusu pakiti kubwa zaidi ambayo njia itakubali.

Pandisha MTU ya njia tu pale kila hop inakubali

Fremu za jumbo ni sifa ya end-to-end, si mpangilio unaowasha kwenye vituo viwili vya mwisho ambavyo unavidhibiti kwa bahati. Kila swichi, ruta na makabidhiano ya mtoa huduma kwenye njia ya nje lazima zikubali ukubwa mkubwa, na hop moja ya baiti 1,500 itatupa kimya pakiti uliyoipandisha ukubwa. Kupandisha kiolesura cha ndani pekee ndio mabadiliko ya nusu ya kawaida yanayofanya tunnel ionekane imeharibika wakati underlay inatupa kimya.

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

Badilisha kiolesura, kisha chunguza tena njia hiyo hiyo kabla ya kubadilisha kitu kingine chochote. Ikiwa jaribio bado linashindwa, rudi kwa ip link set dev eth1 mtu 1500 na nenda kwenye fragmentesheni badala ya kugombana na mtoa huduma kuhusu kiungo ambacho si chako.

Tumia fragmentesheni ya tunnel wakati underlay haiwezi kukua

Utaratibu wa fragmentesheni unaotumika chini ya pakiti ya ndani huruhusu pakiti kadhaa za nje kubeba pakiti moja ya ndani, na kituo cha mwisho cha tunnel upande wa pili huziunganisha tena kabla ya kukabidhi asili kwa stack. Chaguo la UDP fragment la Community OpenVPN ni utekelezaji mmoja wa wazo hilo, na si kitu kile kile kama fragmentesheni ya kawaida ya IP ya pakiti ya nje. Peer wote wawili lazima waendeshe toleo linalotumia umbizo hilo, na njia ya data lazima iwe ile unayofikiria: wateja wa OpenVPN 3 na njia za data zinazoongezwa kasi na kernel zina mipaka tofauti, kwa hivyo wasifu unaofanya kazi kwa mteja mmoja unaweza kushindwa kwa mwingine.

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

Fragmentesheni ya kawaida ya nje ni chaguo lingine, na ndilo dhaifu. Ruta za IPv6 hazifragmenteshi kabisa pakiti inayosambazwa, kwa hivyo pakiti kubwa mno ya nje hufa tu na mtumaji hujua tu ikiwa ujumbe husika wa ICMPv6 utaokoka njia. Vipande pia hukaribisha uchujaji na kuongeza upotevu, kwa hivyo ninaichukulia hii kama njia mbadala na si mpango.

Mtoa huduma wa nje unaotegemea mtiririko hukwepa swali la ukubwa kwa kugawanya mtiririko wake wa baiti, na pakiti ya ndani iliyoundwa upya inaweza bado kuwa baiti 1,500. Hiyo ni uamuzi wa usafirishaji wenye gharama yake mwenyewe, ikiwa ni pamoja na tabia inayojulikana ya TCP ndani ya TCP, kwa hivyo chukua kwa makusudi na si kama athari ya pembeni ya mjadala wa MTU.

Thibitisha kwamba pakiti ya ndani inafika bila kubadilika

Uthibitishaji si handshake iliyofanikiwa. Nasa kwenye kiolesura cha tunnel katika ncha zote mbili na linganisha ukubwa na yaliyomo ya pakiti ambayo programu ilituma kwa kweli na ile ambayo upande wa pili ulipokea.

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'

Ikiwa nasa inaonyesha pakiti ya ndani ya ukubwa kamili kwenye ncha nyingine, uchaguzi wa usafirishaji unafanya kazi na kazi iliyobaki ni kuandika hilo. Ikiwa haionyeshi chochote wakati tunnel inajiripoti kuwa up, pakiti ya nje inatupwa mahali fulani kati ya vituo vya mwisho, jambo ambalo linakurudisha kwenye uchunguzi na si kwenye mipangilio ya cipher.

Andika mambo matatu kwenye tiketi ya mabadiliko kabla ya kuifunga: bajeti ya nje iliyopimwa, utaratibu uliochagua, na amri iliyothibitisha kwamba pakiti ya ndani ilinusurika. Mtu anayefuata kugusa tunnel hii atahitaji yote matatu, na hakuna hata moja inayoweza kujengwa upya kutoka faili ya usanidi pekee.