Miksi OpenConnect-sivut jumittuvat, kunnes lasket tunnelin MTU:ta

Kirjautuminen onnistuu, portaalin etusivu piirtyy, ja sitten kojelaudan widget tai raportti jää tilaan waiting for host, kunnes selain antaa periksi. Julkiset sivustot latautuvat normaalisti koko ajan, eikä mikään tunnistetieto ole muuttunut. Se, että pienet vastaukset tulevat perille suurten juuttuessa, on pakettikoon katon eikä käyttösäännön tunnusmerkki. Vahvista tämä tulkinta ennen kuin muutat profiilista mitään muuta.

Erottele kokoon liittyvä ongelma käytäntöongelmasta

Aloita sulkemalla pois hylkäys. Jos yhdyskäytävä olisi hylännyt sinut, yhteys olisi epäonnistunut heti sen sijaan, että sivu olisi latautunut puoliksi. Tunneli, joka nousee pystyyn ja jumittuu sitten vain suuremmissa siirroissa, kertoo sinulle, ettei ulompi polku kykene kantamaan sisempää pakettia.

Mekanismi on kapselointi. Jokainen sisempi paketti saa tunnelin otsikot, joten fyysiseen linkkiin mahtuva hyötykuorma muuttuu ulommaksi paketiksi, joka ei enää mahdu, ja kaikki do-not-fragment-bittiä kantava pudotetaan ilman vastausta, jonka selain voisi tulkita.

Mittaa katto do-not-fragment-koettimilla

Mittaa katto sen sijaan, että arvaisit sen. Lähetä koettimia, jotka kieltäytyvät pirstaloinnista, ja laske hyötykuormaa askel kerrallaan, kunnes vastaus tulee takaisin, alkaen komennosta kuten ping -M do -s 1472 host. Vastaus, joka valittaa pirstaloinnin tarpeesta, vaikka DF on asetettu, tarkoittaa, että arvo on yhä liian suuri. Toista kohdassa 1462, sitten 1452, ja pysähdy ensimmäiseen kokoon, joka vastaa. Kirjaa luku yhdessä kokeillun isännän kanssa, koska vastaus kuuluu sille polulle, ei protokollalle yleisesti.

Kokeile osoitetta, johon tunneli todella lähettää liikennettä. Ulompi koe yhdyskäytävän julkista nimeä vastaan ja sisempi koe sisäistä palvelinta vastaan mittaavat eri hyppyjä, ja ICMP-suodatus kummassa tahansa voi saada terveen polun näyttämään rikkinäiseltä.

Kohdista arvo tunnelilaitteeseen

Kohdista tulos liitäntään, jonka asiakas loi, ei Wi-Fi-sovittimeen. Linux-asiakkaassa se on ip link set dev tun0 mtu 1300 ja sen jälkeen ip link show tun0 sen vahvistamiseksi, että arvo tuli voimaan. Käytä sitä laitenimeä, jonka asiakas ilmoittaa, sillä se vaihtelee toteutuksen ja tunnelin rakennustavan mukaan.

Tunnelin MTU:n laskeminen pienentää hyötykuormaa, jonka kukin paketti kantaa, joten massasiirron läpäisy laskee hieman, ja se on hinta siitä, ettei suuria vastauksia lähetetä mustaan aukkoon. Pienempi luku ei ole automaattisesti turvallisempi. Fyysisen sovittimen muuttaminen sen sijaan levittää vahingon kaikkiin kyseisen linkin yhteyksiin samalla kun liian suuret sisemmät paketit pysyvät yhtä suurina.

Käytä ensin asiakkaan omia MTU-pyyntöjä

Kun hallitset kutsua, asiakas voi pyytää kokoa sen sijaan, että sitä paikattaisiin jälkikäteen. --mtu pyytää palvelimelta tunnelin MTU:ta, ja --base-mtu ilmoittaa alla olevan polun MTU:n, jotta yhdyskäytävä voi johtaa tunnelin luvun. Molemmat ovat pyyntöjä, eikä asiakkaan käsikirja lupaa, että yhdyskäytävä noudattaa kumpaakaan.

Tämä ero määrää työjärjestyksesi. Kokeile ensin pyyntöä ja tutki liitäntää, jonka se tuottaa, ja palaa sitten laitteen paikalliseen asetukseen, jos yhdyskäytävän valitsema arvo yhä jumittuu.

Vahvista sillä siirrolla, joka epäonnistui, ja tee siitä sitten pysyvä

Paikallinen ip link muutos kestää, kunnes asiakas rakentaa tunnelin uudelleen, mikä tapahtuu seuraavassa uudelleenyhdistämisessä tai jatkamisessa. Laita arvo sinne, missä yhteys alkaa: kääre, joka käynnistää asiakkaan ja säätää sitten laitetta, systemd-yksikkö, jossa on ExecStartPost-vaihe, tai asiakkaan valitsin, kun yhdyskäytävä hyväksyy sen. Pidä se profiilin vieressä versionhallinnassa, jotta seuraava henkilö näkee, miksi luku on siinä.

Testaa pyynnöllä, joka epäonnistui, älä etusivulla. Avaa raportti, vedä liite tai suorita varaston haku, joka jumittui, ja merkitse tarkalleen, mihin se pysähtyy, jos se vielä pysähtyy. Sivu, joka piirtyy muutoksen jälkeen, todistaa vähän, koska se piirtyi myös ennen.

Jos sama siirto jumittuu samassa kohdassa, MTU-teoria on todistamaton. Kaappaa liikenne tunnelilta ja tarkista, kumpi puoli lopettaa lähettämisen, ennen kuin muutat lukua uudelleen, ja pidä edellinen arvo kirjattuna, jotta palautus pysyy yhtenä komentona.