VPN-ping funkcias, sed la retejo haltas: kontrolu la grandecon

Eĥaj respondoj alvenas, la fora labortablo funkcias, kaj la retumilo restas sur malplena paĝo ĝis ĝi rezignas. Du klarigoj konvenas al tiu ŝablono, kaj ili ne estas variantoj de unu problemo: politiko, kiu neniam permesis la servon, aŭ pakaĵoj, kiuj ĉesas taŭgi kiam la transdono kreskas. La eĥa respondo ekskludas nek unu nek la alian.

Iru de la plej malgranda demando al la plej granda, kaj notu, kion ĉiu paŝo efektive pruvis.

Eĥa respondo respondas al multe pli malgranda demando

Eĥa respondo diras, ke la IP-stako de la celo respondis al ICMP-peto de via fonto. Ĝi diras nenion pri tio, ĉu ekzistas TCP-auskultanto sur la bezonata pordo, ĉu politiko permesas tiun pordon, aŭ ĉu la cela gastiganto filtradas trafikon sendepende de la enirejo. Enirejo, kiu permesas unu servon, povas forĵeti alian dum ambaŭ celoj respondas al ping. Legu la respondon kiel unu fakton pri unu pakaĵo kaj unu direkto.

Konfirmu la celon kaj la servan pordon antaŭ ol interpreti ion ajn alian. La adreso, kiun vi testis, kaj la adreso, kiun la aplikaĵo uzas, estas foje malsamaj rikordoj, kaj nomo, kiu solviĝas al du adresoj, tion probable igas.

Elkomprenu, ĉu la konekto komenciĝis

Konekto tuj rifuzita estas respondo de la auskultanto aŭ de la politiko: io respondis kaj diris ne. Konekto, kiu malfermiĝas kaj poste haltas kiam datumoj komencas moviĝi, indikas grandecon. Konekto, kiu tute ne finas la manpremon, kutime estas afero de politiko aŭ enkursigo, kaj aspektas kiel tempolimo prefere ol rifuzo.

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

Notu, kiun el tiuj tri vi observis, antaŭ ol tuŝi MTU-agordojn. Ŝanĝi tunelan grandecon por ripari rifuzitan konekton malŝparas la ŝanĝon kaj dumtempe kaŝas la veran kaŭzon.

Mezuru grandecon per deklarita nombro

Kiam la halto aperas sub ŝarĝo, testu unu pakaĵan grandecon kun la bito de malpermeso de fragmentado agordita kaj deklaru la aritmetikon, por ke la rezulto signifu ion. En Linux kun iputils, utila ŝarĝo de 1392 bajtoj plus la 8-bajta ICMP-kapo kaj la 20-bajta IPv4-kapo produktas internan pakaĵon de ekzakte 1420 bajtoj. Deklaru tiun aritmetikon en la bileto, ĉar nuda ping, kiu atingas la enirejon, pruvas nenion pri aplikaĵo.

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

Ambaŭ provoj estas mezurpunktoj, ne rekomendoj pri tunela grandeco. Se ICMP estas filtrita ie ajn sur la vojo, tempolimo diras al vi nenion pri grandeco, ĉar filtrado kaj tro granda pakaĵo aspektas identaj de la klienta flanko. Sukceso ankaŭ diras nenion pri la kontraŭa direkto aŭ pri alia celo.

Kalkulu la eksteran vojon

Enkapsuligo aldonas proprajn kapojn, do la pakaĵo sur la drato estas pli granda ol la pakaĵo, kiun vi mezuris ene de la tunelo. La breĉo inter la du estas tio, kio ebligas samtempe funkciantan malgrandan peton kaj malsukcesantan grandan.

IPv4-malkovro de la voja MTU dependas de retrokuplo pri pakaĵoj, kiuj ne povas esti plusenditaj sen fragmentado, kaj IPv6 uzas Packet Too Big-mesaĝojn. La IPv4-specifiko priskribas tiun mekanismon. Filtrado de la retrokuplo rompas la kapablon de la sendanto lerni, kaj lasas ĝin retranssendi pakaĵojn, kiuj neniam taŭgos. Tial funkcianta malgranda peto kaj malsukcesanta granda tiel komforte kunekzistas.

Ŝanĝu unu nombron kaj retestu la aplikaĵon

Malaltigu la MTU de la tunelo, aŭ limigu la maksimuman segmentan grandecon por TCP, poste ripetu la originalan aplikaĵan teston anstataŭ la provon. Provo, kiu sukcesas post la ŝanĝo, kaj aplikaĵo, kiu ankoraŭ haltas, estas malsama problemo kun simila formo, kaj nur la aplikaĵa testo distingas ilin.

Konservu la aritmetikon en la ŝanĝa rikordo: la mezuritan grandecon, la supozitan superkoston kaj la valoron, kiun vi agordis. Iu ajn, kiu revizios tion poste, povas kontroli la supozon anstataŭ reellabori ĝin el ekrankopio de ping.

Se la aplikaĵo funkcias je ĉiu grandeco, kiun vi provis, ĉesu alĝustigi nombrojn kaj rigardu la politikon, kiu apartigas la funkciantan servon de la malsukcesanta.