VPN ping veikia, bet svetainė stringa: patikrinkite dydį

Aido atsakymai ateina, nuotolinis darbalaukis veikia, o naršyklė lieka tuščiame puslapyje, kol pasiduoda. Šiam modeliui tinka du paaiškinimai, ir jie nėra vienos problemos variantai: politika, kuri niekada neleido paslaugos, arba paketai, kurie nustoja tilpti, kai perdavimas padidėja. Aido atsakas nei vieno iš jų neatmeta.

Eikite nuo mažiausio klausimo prie didžiausio ir užrašykite, ką kiekvienas žingsnis iš tikrųjų įrodė.

Aido atsakas atsako į daug mažesnį klausimą

Aido atsakas sako, kad paskirties IP kamienas atsakė į ICMP užklausą iš jūsų šaltinio. Jis nieko nesako apie tai, ar reikiamame porte yra TCP klausytojas, ar politika leidžia tą portą, ar paskirties mazgas filtruoja srautą nepriklausomai nuo tinklo vartų. Vartai, leidžiantys vieną paslaugą, gali atmesti kitą, nors abu taikiniai atsako į ping. Skaitykite atsakymą kaip vieną faktą apie vieną paketą ir vieną kryptį.

Prieš ką nors kita aiškindami, patvirtinkite paskirtį ir paslaugos portą. Adresas, kurį išbandėte, ir adresas, kurį naudoja programa, kartais būna skirtingi įrašai, o vardas, kuris sprendžiamas į du adresus, tai daro tikėtina.

Išsiaiškinkite, ar ryšys prasidėjo

Iš karto atmestas ryšys yra klausytojo arba politikos atsakymas: kažkas atsakė ir pasakė ne. Ryšys, kuris atsiveria ir tada stringa, kai duomenys pradeda judėti, rodo į dydį. Ryšys, kuris visai neužbaigia rankos paspaudimo, paprastai yra politikos arba maršrutizavimo klausimas ir atrodo kaip laukimo limitas, o ne kaip atmetimas.

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

Užrašykite, kurį iš tų trijų atvejų pastebėjote, prieš liesdami MTU nustatymus. Tunelio dydžio keitimas, siekiant sutaisyti atmestą ryšį, eikvoja pakeitimą ir kuriam laikui paslepia tikrąją priežastį.

Išmatuokite dydį nurodytu skaičiumi

Kai strigimas pasireiškia esant apkrovai, išbandykite vieną paketo dydį su draudimo skaidyti bitu ir nurodykite aritmetiką, kad rezultatas ką nors reikštų. Linux su iputils atveju 1392 baitų naudingoji apkrova plius 8 baitų ICMP antraštė ir 20 baitų IPv4 antraštė sukuria vidinį paketą, lygų lygiai 1420 baitų. Nurodykite šią aritmetiką biliete, nes plikas ping, pasiekiantis vartus, nieko neįrodo apie programą.

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

Abu bandymai yra matavimo taškai, o ne tunelio dydžio rekomendacijos. Jei ICMP filtruojamas bet kur kelyje, laukimo limitas nieko nesako apie dydį, nes filtravimas ir per didelis paketas kliento pusėje atrodo vienodai. Sėkmė taip pat nieko nesako apie priešingą kryptį ar kitą paskirtį.

Atsižvelkite į išorinį kelią

Inkapsuliavimas prideda savo antraštes, todėl paketas laide yra didesnis už tą, kurį išmatavote tunelio viduje. Būtent skirtumas tarp jų leidžia vienu metu egzistuoti veikiančiam mažam prašymui ir nepavykstančiam dideliam.

IPv4 kelio MTU nustatymas priklauso nuo grįžtamojo ryšio apie paketus, kurių negalima persiųsti be skaidymo, o IPv6 naudoja Packet Too Big pranešimus. IPv4 specifikacija aprašo tą mechanizmą. Grįžtamojo ryšio filtravimas sugriauna siuntėjo gebėjimą mokytis ir palieka jį siųsti iš naujo paketus, kurie niekada netilps. Štai kodėl veikiantis mažas prašymas ir nepavykstantis didelis taip patogiai sugyvena.

Pakeiskite vieną skaičių ir iš naujo išbandykite programą

Sumažinkite tunelio MTU arba apribokite didžiausią TCP segmento dydį, tada pakartokite pirminį programos bandymą, o ne zondą. Zondas, kuris po pakeitimo pavyksta, ir programa, kuri vis dar stringa, yra kita panašios formos problema, ir tik programos bandymas jas atskiria.

Laikykite aritmetiką pakeitimo įraše: išmatuotą dydį, priimtą papildomą sąnaudą ir nustatytą reikšmę. Kas nors vėliau tai peržiūrėjęs gali patikrinti prielaidą, o ne iš naujo išvesti ją iš ping ekrano kopijos.

Jei programa veikia su kiekvienu išbandytu dydžiu, nustokite derinti skaičius ir pažiūrėkite į politiką, kuri atskiria veikiančią paslaugą nuo nepavykstančios.