OpenVPN PPPoE-yhteydellä: pienennä link-mtu, tun-mtu vai mssfix?
Ping toimii, mutta suuret sivut jumiutuvat PPPoE- tai DS-Lite-yhteydellä. Valitse link-mtu, tun-mtu ja mssfix välillä mittaamalla reitti, ei arvaamalla.
Pingit vastaavat, DNS selvittää nimet ja jokainen sivu, joka tarvitsee täysikokoisen segmentin, jumittuu. Yhteydellä, joka lisää oman kapselointinsa, reitti menettää hiljaa muutaman kymmenen tavua budjetistaan, ja puhtaalle Ethernetille kirjoitettu profiili pyytää edelleen paketteja, joita linja ei kanna. Yhteys ei ole hidas; se hylkää juuri ne paketit, joilla on merkitystä.
Kolme vaihtoehtoa voi korjata tämän, ja ne vaikuttavat eri kerroksissa. Väärän valitseminen joko ei tee mitään tai tekee tunnelista uudella tavalla hauraan, joten valinta alkaa siitä, mitä reitti todella tukee.
Kolme säätöruuvia, kolme eri kerrosta
link-mtu on ulkoinen budjetti: salattu hyötykuorma plus OpenVPN-otsake, UDP-otsake ja ulkoinen IP-otsake. Se kuvaa, mitä koneesta lähtee, ja siksi se on luku, jota fyysinen reitti rajoittaa.
tun-mtu on sisäinen budjetti: rajapinta, jonka liikenteesi näkee. Se on täsmälleen tunnelin ylikuorman verran suurempi kuin mitä reitti voi kantaa, ja OpenVPN yleensä johtaa sen sen sijaan, että pakottaisi sinut asettamaan sen.
mssfix on kokonaan toinen mekanismi. Se kirjoittaa uudelleen TCP-kättelyjen aikana ilmoitetun suurimman segmenttikoon, jotta TCP-vertaiset valitsevat segmentit, jotka mahtuvat kapseloinnin jälkeen. Se ei muuta rajapinnan MTU:ta eikä vaikuta UDP:hen lainkaan.
Jos asetat link-mtu -arvon eksplisiittisesti, OpenVPN vähentää oman ylikuormansa sisäisen MTU:n johtamiseksi. Tämä ylikuorma ei ole kiinteä vakio; se riippuu salauksesta ja todennuksesta, minkä vuoksi foorumilta kopioitu arvo voi olla väärä eri profiilissa. Molempien, link-mtu ja tun-mtu, asettaminen antaa asiakkaalle kaksi ristiriitaista ohjetta.
Mittaa reitti ennen minkään luvun valitsemista
Mittaa fyysiseltä rajapinnalta, älä tunnelin sisältä, ja muista, että ping ilmoittaa hyötykuorman, ei paketin kokoa. Lisää 28 tavua IPv4- ja ICMP-otsakkeille ennen kuin vertaat hyötykuormaa 1500 tavun kehykseen, ja pidä tämä korjaus mielessä, kun vertainen ilmoittaa eri luvun.
Linux-asiakkaassa ping -M do -s 1472 kieltää pirstoutumisen ja epäonnistuu, jos paketti on liian suuri. Pienennä hyötykuormaa, kunnes se menee läpi, ja lisää sitten 28 saadaksesi reitin MTU:n. PPPoE maksaa 8 tavua, joten 1492 on DSL:llä normaali. DS-Lite ja eräät mobiiliyhteydet maksavat 40 tai enemmän, ja vastaus on yleensä pienempi kuin nimellinen linkkinopeus antaa ymmärtää.
Jos jokainen ping-koko onnistuu mutta suuret siirrot jumiutuvat silti, epäile mustaa aukkoa etkä yksinkertaista kokorajaa. ICMP-viesti tarvittavasta pirstoutumisesta suodatetaan jossain reitin varrella, joten lähettäjä ei koskaan opi pienentämään, ja vain suurta segmenttiä tarvitsevat vuot huomaavat sen.
Rajoita ensin TCP, kutista sitten tunnelia
TCP-kättelyt ovat ainoa asia, johon mssfix koskee, ja siksi se on yleensä vähiten häiritsevä säädin, jota kannattaa kokeilla ensimmäisenä. Aseta se hieman reitin todellisen budjetin alle, lähetä sama arvo palvelimelta, jotta molemmat päät ovat samaa mieltä, ja testaa suuri lataus uudelleen. Jos jumitus poistuu, ongelma oli TCP-segmentin koko, eikä mitään muuta tarvitse muuttaa.
Pienennä sisäistä MTU:ta, kun kyseessä oleva liikenne ei ole TCP:tä. UDP-palvelu, tunneli tunnelin sisällä tai sovellus, joka lähettää täysikokoisia datagrammeja, epäonnistuu edelleen MSS-rajoituksen jälkeen, koska mikään ei kirjoita sen pakettikokoa uudelleen. Pienennä silloin tun-mtu, tai aseta link-mtu ja anna asiakkaan johtaa sisäinen arvo, mutta ei koskaan molempia.
Älä tartu vanhaan pirstoutumisvaihtoehtoon. Se jakoi paketteja tunnelin sisällä, lisäsi ylikuormaa ja on vanhentunut hyvistä syistä; nykyaikainen OpenVPN odottaa, että reitti kuvataan tarkasti.
Miksi pienet tunnustelut toimivat edelleen
DNS-kyselyt, ICMP-kaikuja ja TCP-kättelyt ovat kaikki paljon epäonnistuvaa kokoa pienempiä. Tunneli näyttää siksi terveeltä jokaisessa pikatestissä, samalla kun TLS-kättelyt ja HTTP-vastaukset epäonnistuvat hiljaa. Juuri tämä yhdistelmä, toimiva traceroute ja selain, joka jumiutuu ensimmäisestä suuresta vastauksesta, on merkki, jota etsiä. Tartu täysikokoiseen tunnusteluun ennen kuin tartut uuteen profiiliin.
Varmista sen liikenteen avulla, joka epäonnistui. Hae suuri sivu, lähetä täysikokoinen UDP-datagrammi, jos se on kyseessä oleva palvelu, ja toista toiselta asiakkaalta toisella yhteydellä. Kirjaa mitattu reitin MTU ja valitsemasi arvo, sillä muuten seuraava profiiliin koskeva pitää lukua mielivaltaisena.
Älä koskaan vie sisäistä MTU:ta alle 1280, kun IPv6 kulkee tunnelin yli, sillä se on vähimmäisarvo, joka jokaisen IPv6-linkin on kannettava. Pienempi MTU on tosiasia reitistä, ei suorituskykyasetus, jota hienosäädetään tuntuman mukaan.