VPN ping darbojas, bet vietne iesprūst: pārbaudiet izmēru

Atbalss atbildes nāk, attālinātā darbvirsma darbojas, un pārlūks paliek tukšā lapā, līdz padodas. Šim modelim atbilst divi skaidrojumi, un tie nav vienas problēmas varianti: politika, kas nekad nav atļāvusi pakalpojumu, vai paketes, kas pārstāj ietilpt, tiklīdz pārsūtīšana pieaug. Atbalss atbilde neizslēdz nevienu no tiem.

Ejiet no mazākā jautājuma uz lielāko un pierakstiet, ko katrs solis patiešām pierādīja.

Atbalss atbilde atbild uz daudz mazāku jautājumu

Atbalss atbilde saka, ka galamērķa IP steks atbildēja uz ICMP pieprasījumu no jūsu avota. Tā neko nepasaka par to, vai vajadzīgajā portā ir TCP klausītājs, vai politika atļauj šo portu, vai galamērķa resursdators filtrē datu plūsmu neatkarīgi no vārtejas. Vārteja, kas atļauj vienu pakalpojumu, var nomest citu, kamēr abi mērķi atbild uz ping. Lasiet atbildi kā vienu faktu par vienu paketi un vienu virzienu.

Pirms interpretējat ko citu, apstipriniet galamērķi un pakalpojuma portu. Adrese, kuru pārbaudījāt, un adrese, kuru izmanto lietojumprogramma, dažkārt ir dažādi ieraksti, un vārds, kas atrisinās divās adresēs, padara to iespējamu.

Noskaidrojiet, vai savienojums sākās

Uzreiz noraidīts savienojums ir klausītāja vai politikas atbilde: kaut kas atbildēja un pateica nē. Savienojums, kas atveras un pēc tam iestrēgst, kad dati sāk kustēties, norāda uz izmēru. Savienojums, kas nemaz nepabeidz rokasspiedienu, parasti ir politikas vai maršrutēšanas jautājums un izskatās kā taimauts, nevis kā noraidījums.

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

Pierakstiet, kuru no šiem trim gadījumiem novērojāt, pirms aiztiekat MTU iestatījumus. Tuneļa izmēra maiņa, lai salabotu noraidītu savienojumu, izšķiež šo izmaiņu un uz laiku noslēpj patieso cēloni.

Izmēriet izmēru ar norādītu skaitli

Kad iestrēgšana parādās slodzes laikā, pārbaudiet vienu paketes izmēru ar aizlieguma sadalīt bitu un norādiet aritmētiku, lai rezultātam būtu nozīme. Linux ar iputils 1392 baitu derīgā slodze plus 8 baitu ICMP galvene un 20 baitu IPv4 galvene rada iekšēju paketi, kas ir tieši 1420 baitu. Norādiet šo aritmētiku biļetenā, jo kails ping, kas sasniedz vārteju, neko nepierāda par lietojumprogrammu.

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

Abas pārbaudes ir mērījumu punkti, nevis tuneļa izmēra ieteikumi. Ja ICMP tiek filtrēts kaut kur ceļā, taimauts neko nepasaka par izmēru, jo filtrēšana un pārāk liela pakete klienta pusē izskatās vienādi. Arī veiksme neko nepasaka par pretējo virzienu vai citu galamērķi.

Ņemiet vērā ārējo ceļu

Iekapsulēšana pievieno savas galvenes, tāpēc pakete uz vada ir lielāka par to, kuru izmērījāt tuneļa iekšpusē. Tieši starpība starp abām ļauj vienlaikus pastāvēt strādājošam mazam pieprasījumam un neizdevušamies lielam.

IPv4 ceļa MTU noteikšana ir atkarīga no atgriezeniskās saites par paketēm, kuras nevar pārsūtīt bez sadalīšanas, un IPv6 izmanto Packet Too Big ziņojumus. IPv4 specifikācija apraksta šo mehānismu. Atgriezeniskās saites filtrēšana salauž sūtītāja spēju mācīties un liek tam atkārtoti sūtīt paketes, kas nekad neietilps. Tāpēc strādājošs mazs pieprasījums un neizdevies liels tik ērti pastāv līdzās.

Mainiet vienu skaitli un vēlreiz pārbaudiet lietojumprogrammu

Samaziniet tuneļa MTU vai ierobežojiet TCP maksimālo segmenta izmēru, pēc tam atkārtojiet sākotnējo lietojumprogrammas testu, nevis zondi. Zonde, kas pēc izmaiņām izdodas, un lietojumprogramma, kas joprojām iestrēgst, ir cita līdzīgas formas problēma, un tikai lietojumprogrammas tests tās atšķir.

Glabājiet aritmētiku izmaiņu ierakstā: izmērīto izmēru, pieņemtās papildu izmaksas un iestatīto vērtību. Ikviens, kas to vēlāk pārskatīs, var pārbaudīt pieņēmumu, nevis no jauna to atvasināt no ping ekrānuzņēmuma.

Ja lietojumprogramma darbojas ar katru izmēģināto izmēru, pārtrauciet skaitļu pielāgošanu un apskatiet politiku, kas atdala strādājošo pakalpojumu no neizdevušā.