Ping prek VPN deluje, a stran se ustavi: preverite velikost

Odgovori odmeva prihajajo, oddaljeno namizje deluje, brskalnik pa ostane na prazni strani, dokler ne obupa. Temu vzorcu ustrezata dve razlagi in nista različici iste težave: politika, ki storitve ni nikoli dovolila, ali paketi, ki se prenehajo prilegati, ko prenos zraste. Odgovor odmeva ne izključi nobene od obeh.

Pojdite od najmanjšega vprašanja k največjemu in zapišite, kaj je vsak korak v resnici dokazal.

Odgovor odmeva odgovarja na veliko manjše vprašanje

Odgovor odmeva pove, da je IP sklad cilja odgovoril na zahtevo ICMP iz vašega vira. Ne pove ničesar o tem, ali na vratih, ki jih potrebujete, obstaja poslušalec TCP, ali politika ta vrata dovoljuje, ali ciljni gostitelj filtrira promet neodvisno od prehoda. Prehod, ki dovoli eno storitev, lahko drugo zavrže, medtem ko oba cilja odgovarjata na ping. Berite odgovor kot eno dejstvo o enem paketu in eni smeri.

Potrdite cilj in vrata storitve, preden razlagate karkoli drugega. Naslov, ki ste ga preizkusili, in naslov, ki ga uporablja aplikacija, sta včasih različna zapisa, ime, ki se razreši v dva naslova, pa to naredi verjetno.

Ugotovite, ali se je povezava začela

Povezava, ki je takoj zavrnjena, je odgovor poslušalca ali politike: nekaj je odgovorilo in reklo ne. Povezava, ki se odpre in nato obtiči, ko se podatki začnejo premikati, kaže na velikost. Povezava, ki rokovanja sploh ne dokonča, je običajno stvar politike ali usmerjanja in je videti kot potek časa, ne kot zavrnitev.

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

Zapišite, katero od teh treh situacij ste opazili, preden se dotaknete nastavitev MTU. Spreminjanje velikosti tunela za popravljanje zavrnjene povezave zapravi to spremembo in za nekaj časa skrije pravi vzrok.

Izmerite velikost z navedenim številom

Ko se zastoj pojavi pod obremenitvijo, preizkusite eno velikost paketa z nastavljenim bitom prepovedi razdrobljenosti in navedite aritmetiko, da bo rezultat nekaj pomenil. V Linuxu z iputils uporabna obremenitev 1392 bajtov plus 8-bajtna glava ICMP in 20-bajtna glava IPv4 ustvari notranji paket natanko 1420 bajtov. Navedite to aritmetiko v zahtevku, ker goli ping, ki doseže prehod, o aplikaciji ničesar ne dokaže.

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

Obe sondi sta merilni točki, ne priporočili za velikost tunela. Če je ICMP kjer koli na poti filtriran, potek časa ne pove ničesar o velikosti, ker sta filtriranje in prevelik paket s strani odjemalca videti enako. Tudi uspeh ne pove ničesar o nasprotni smeri ali o drugem cilju.

Upoštevajte zunanjo pot

Enkapsulacija doda svoje glave, zato je paket na žici večji od paketa, ki ste ga izmerili znotraj tunela. Prav razlika med njima omogoča hkrati delujočo majhno zahtevo in neuspešno veliko.

Odkrivanje MTU poti v IPv4 je odvisno od povratnih informacij o paketih, ki jih ni mogoče posredovati brez razdrobljenosti, IPv6 pa uporablja sporočila Packet Too Big. Specifikacija IPv4 opisuje ta mehanizem. Filtriranje povratnih informacij zlomi sposobnost pošiljatelja, da se uči, in ga pusti pri ponovnem pošiljanju paketov, ki se ne bodo nikoli prilegali. Zato delujoča majhna zahteva in neuspešna velika tako udobno soobstajata.

Spremenite eno število in znova preizkusite aplikacijo

Znižajte MTU tunela ali omejite največjo velikost segmenta za TCP, nato ponovite prvotni preizkus aplikacije namesto sonde. Sonda, ki po spremembi uspe, in aplikacija, ki še vedno obtiči, sta druga težava podobne oblike, in samo preizkus aplikacije ju razlikuje.

Aritmetiko hranite v zapisu spremembe: izmerjeno velikost, predpostavljene dodatne stroške in nastavljeno vrednost. Kdor to pozneje pregleda, lahko predpostavko preveri, namesto da bi jo znova izpeljal iz posnetka zaslona s pingom.

Če aplikacija deluje pri vsaki preizkušeni velikosti, prenehajte prilagajati števila in poglejte politiko, ki ločuje delujočo storitev od neuspešne.