Lapa ielādējas, mazs API izsaukums atgriežas, un tad faila augšupielāde karājas, līdz klients padodas. Servera žurnālā nekas to neizskaidro, jo paketes tika nomestas ceļa vidū, nenosūtot atpakaļ lietderīgu atbildi. Šis modelis ir MTU melnais caurums: šaurāks nekā sūtītājs pieņem savienojums, plus klusa atteikšanās to pateikt. Neizdevušais lielums ir atkārtojams, un tieši tas padara to diagnosticējamu.

Kas padara caurumu melnu

Katrai saitei ir maksimālā pārraides vienība, un pakaitei, kas lielāka par nākamā lēciena ierobežojumu, jābūt vai nu sadalītai, vai noraidītai ar ICMP ziņojumu, kas to pasaka. Ceļa MTU atklāšana ir atkarīga no tā, vai šis ziņojums pienāk un tiek ievērots. Tā filtrēšana vai ignorēšana liek sūtītājam atkārtot pakaidi, kas nekad neiederas.

Iekapsulēšana padara to par parastu VPN apkārtnē, jo tunelis pievieno ārēju galveni pakaitei, kas jau bija izmērīta fiziskajai saitei. Iekšējā pakaite ir likumīga pie 1500 baitiem, bet iekapsulētā nav, tāpēc tā mirst pie robežas, kamēr mazas paketes izslīd cauri. Pabeigta rokasspiediena un strādājoša pieteikšanās lapa pierāda tikai to, ka mazas paketes strādā. Lielākā pakaite, ko lietotne mēģina nosūtīt, ir tā, kurai ir nozīme.

Atrodiet lielumu, kur tas lūzt

Bināri meklējiet lietderīgās kravas lielumu ar testu bez sadalīšanas, no resursdatora vienā tuneļa pusē uz resursdatoru otrā pusē. Lielākā krava, kas iziet, ir jūsu izmantojamais ceļa MTU mīnus galvenes izmaksas.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

1472 baitu krava iziet pa tīru 1500 baitu Ethernet ceļu, kad pievieno 28 baitu IPv4 un ICMP galveņu. Kad tas pats tests pēc tuneļa pacelšanas izdodas tikai ar mazāku kravu, starpība ir iekapsulēšanas izmaksas, un tuneļa robeža ir vieta, kur vajadzēja ģenerēt noraidījuma ziņojumu. Pierakstiet abus skaitļus, pirms un pēc savienojuma, jo šis pāris ir pierādījums. Atkārtojiet testu IPv6, kad lietotne to izmanto, jo galvene ir lielāka un kļūmes slieksnis pārvietojas.

Izlasiet pierādījumus, pirms vainojat tuneli

Attālinātu lietotņu kļūdas, sastrēgumi un parastie zudumi arī aptur augšupielādes, tāpēc viens neizdevies pārsūtījums neatpazīst melno caurumu. Tos atšķir lielumu attiecība: atkārtojams panākums pie 1200 baitiem un atkārtojama apstāšanās pie 1400 baitiem, tajā pašā virzienā, caur to pašu galapunktu.

Ieraksts abos galos parāda lielās paketes izejam un nekad neierodamies, bez noraidījuma starp tām. Tas ir brīdis, kad jāskatās uz robežierīci, nevis serveri, kas atbild uz katru faktiski saņemto pieprasījumu. Sastrēgumi arī aptur, bet tie aptur dažādus lielumus dažādos laikos, un tā ir cita paraksts.

Pārbaudiet labojumu abos transportos

Atbalstītais labojums ir ļaut robežai ziņot par īsto ierobežojumu vai tur savilkt TCP maksimālo segmenta lielumu, lai netiktu mēģināts pārāk liels segments. Katra MTU pazemināšana tīklā vai ugunsmūra izslēgšana slēpj simptomu un atstāj konfigurāciju, par kuru vēlāk neviens nevarēs spriest.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Pārbaudiet ar to pašu lieluma testu, tad ar lietotni, kas neizdevās, un pārbaudiet otru protokolu, jo UDP lietotnes nekad nesaņem TCP segmenta lieluma korekciju. Saglabājiet sākotnējās vērtības biļetenā, jo neatgriezenisks labojums ir otra problēma, kas gaida notikšanu. Ja lieluma tests iztur un augšupielāde joprojām apstājas, melnais caurums nebija iemesls, un izmeklēšanai jāturpinās, nevis jāpaplašina izmaiņas.

Saistītie raksti