VPN:n ping toimii, mutta verkkosivu jumittuu: tarkista koko

Kaikuvastaukset saapuvat, etätyöpöytä toimii ja selain istuu tyhjällä sivulla, kunnes antaa periksi. Kaksi selitystä sopii tuohon kuvioon, eivätkä ne ole yhden ongelman muunnelmia: käytäntö, joka ei koskaan sallinut palvelua, tai paketit, jotka lakkaavat mahtumasta, kun siirto kasvaa. Kaikuvastaus ei sulje pois kumpaakaan.

Etene pienimmästä kysymyksestä suurimpaan ja kirjaa, mitä kukin vaihe todella todisti.

Kaikuvastaus vastaa paljon pienempään kysymykseen

Kaikuvastaus kertoo, että kohteen IP-pino vastasi lähteestäsi tulleeseen ICMP-pyyntöön. Se ei kerro, onko tarvitsemassasi portissa TCP-kuuntelijaa, salliiko käytäntö tuon portin vai suodattaako kohdeisäntä liikennettä yhdyskäytävästä riippumatta. Yhdyskäytävä, joka sallii yhden palvelun, voi pudottaa toisen, vaikka molemmat kohteet vastaavat pingiin. Lue vastaus yhtenä tosiasiana yhdestä paketista ja yhdestä suunnasta.

Vahvista kohde ja palvelun portti ennen kuin tulkitset mitään muuta. Testaamasi osoite ja sovelluksen käyttämä osoite ovat joskus eri tietueita, ja nimi, joka ratkeaa kahdeksi osoitteeksi, tekee siitä todennäköistä.

Selvitä, alkoiko yhteys

Heti hylätty yhteys on kuuntelijan tai käytännön vastaus: jokin vastasi ja sanoi ei. Yhteys, joka avautuu ja sitten juuttuu, kun tiedot alkavat liikkua, viittaa kokoon. Yhteys, joka ei koskaan suorita kättelyä loppuun, johtuu yleensä käytännöstä tai reitityksestä ja näyttää aikakatkaisulta eikä hylkäykseltä.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Kirjaa, minkä noista kolmesta havaitsit, ennen kuin kosket MTU-asetuksiin. Tunnelin koon muuttaminen hylätyn yhteyden korjaamiseksi tuhlaa muutoksen ja piilottaa todellisen syyn jonkin aikaa.

Mittaa koko ilmoitetulla luvulla

Kun juuttuminen ilmenee kuormituksessa, testaa yksi pakettikoko pirstomisen estävällä bitillä ja esitä laskutoimitus, jotta tulos merkitsee jotain. Linuxissa iputilsin kanssa 1392 tavun hyötykuorma plus 8 tavun ICMP-otsake ja 20 tavun IPv4-otsake tuottaa sisäisen paketin, joka on täsmälleen 1420 tavua. Esitä tuo laskutoimitus tiketissä, koska paljas ping, joka saavuttaa yhdyskäytävän, ei todista sovelluksesta mitään.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Molemmat kokeet ovat mittapisteitä, eivät suosituksia tunnelin koosta. Jos ICMP suodatetaan jossain reitillä, aikakatkaisu ei kerro koosta mitään, koska suodatus ja liian suuri paketti näyttävät asiakkaan puolelta samalta. Onnistuminenkaan ei kerro mitään vastakkaisesta suunnasta tai toisesta kohteesta.

Ota ulompi reitti huomioon

Kapselointi lisää omat otsakkeensa, joten johdolla oleva paketti on suurempi kuin tunnelin sisällä mittaamasi paketti. Juuri näiden välinen ero tekee mahdolliseksi samanaikaisesti toimivan pienen pyynnön ja epäonnistuvan suuren.

IPv4:n reitin MTU:n selvitys riippuu palautteesta paketeista, joita ei voi välittää ilman pirstomista, ja IPv6 käyttää Packet Too Big -viestejä. IPv4-määrittely kuvaa tämän mekanismin. Palautteen suodattaminen rikkoo lähettäjän kyvyn oppia ja jättää sen lähettämään uudelleen paketteja, jotka eivät koskaan mahdu. Siksi toimiva pieni pyyntö ja epäonnistuva suuri ovat niin mukavasti rinnakkain.

Muuta yhtä lukua ja testaa sovellus uudelleen

Laske tunnelin MTU:ta tai rajoita TCP:n suurin segmenttikoko, ja toista sitten alkuperäinen sovellustesti kokeen sijaan. Muutoksen jälkeen onnistuva koe ja yhä jumittuva sovellus ovat eri ongelma, jolla on samanlainen muoto, ja vain sovellustesti erottaa ne.

Pidä laskutoimitus muutostietueessa: mitattu koko, olettamasi lisäkustannus ja asetettu arvo. Joka sen myöhemmin tarkistaa, voi tarkistaa oletuksen sen sijaan, että johtaisi sen uudelleen pingin kuvakaappauksesta.

Jos sovellus toimii jokaisella kokeilemallasi koolla, lopeta lukujen säätäminen ja katso käytäntöä, joka erottaa toimivan palvelun epäonnistuvasta.