Az oldalak betöltenek, de a feltöltések megakadnak a VPN-en: melyik ok nyer
A mérettől függő megakadás illik az útvonal-MTU hibájához, de a DNS-hez, egy alkalmazáskorláthoz vagy egy ingadozó alagúthoz is. Négy megfigyelés dönti el, melyik.
Az oldalak betöltenek, a VPN kapcsolódott állapotot jelent, és egy fájlfeltöltés minden alkalommal ugyanazon a ponton fagy meg. Négy magyarázat illik erre a leírásra: a csomagméret problémája, a névfeloldás problémája, egy alkalmazáskorlát és egy alagút, amely folyamatosan újraindul. Mindegyikük más-más megfigyeléssel igazolható vagy zárható ki, ezért a döntés a megfelelő teszt kiválasztása, nem pedig az ok kitalálása.
Négy jelölt és egy alak
Kezdd a hiba alakjával, mert az a lista nagy részét kiszűri, mielőtt bármilyen eszközt megnyitnál. Az állandó méretnél fellépő megakadás méretprobléma mindaddig, amíg az ellenkezője be nem bizonyosodik. A véletlenszerű pontokon fellépő megakadás veszteség- vagy stabilitási probléma. A kapcsolat megnyílása előtti hiba névprobléma.
A negyedik jelölt az alkalmazás. A feltöltési korlátok, a kérések időtúllépései és a proxy testméret-plafonjai olyan hibákat okoznak, amelyek a böngészőből hálózati hibának látszanak, és általában elutasításként érkeznek, nem megakadásként.
Írd fel a megfigyelt alakot, mielőtt bármit tesztelnél. „Nagyjából ugyanannyi bájtnál áll meg, minden alkalommal, az alagút fennállása mellett“ sokkal erősebb kiindulópont, mint hogy „a feltöltések nem működnek“.
Utána tartsd az útvonalat változatlanul a tesztelés alatt. A kimenet, a protokoll és a szerver egyidejű cseréje olyan eredményt ad, amelyet egyikükhöz sem tudsz hozzárendelni. Egy változó futásonként, és írd fel.
Felezd a méretet, mielőtt a szabályzathoz nyúlnál
A legolcsóbb megkülönböztető egy próba, amely egyetlen számot változtat. Küldj növekvő méretű, töredezést tiltó pingeket a cél felé, tölts fel egy általad ellenőrzött fájlt ugyanarra a szolgáltatásra, majd hasonlítsd össze, hol áll meg mindegyik.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadAz első parancs jelzi, hogy egy teljes méretű csomag egyáltalán átjut-e az útvonalon. 1500 bájtos MTU esetén a legnagyobb nem töredező ICMP-hasznos teher 1472 bájt, és az alagút még ennél is többet vesz el ebből a keretből, mielőtt a belső csomag elkezdődik. A második méretet és időtartamot ad egy alkalmazásszintű átvitelhez, és ez az a szám, amely valóban számít.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Olvasd együtt a párt. A küszöb felett meghiúsuló próbák és a ugyanazon küszöb közelében megálló feltöltés összefüggő történet. A próbák mind sikeresek, miközben a feltöltés olyan bájtszámnál akad meg, amelyet az útvonal egyértelműen elvisz, az alkalmazásra vagy a szerverre mutat, és semmilyen MTU-munka nem változtat rajta. Ez a negatív eredmény annyit ér, mint egy pozitív. Eltávolítja a vizsgálat legdrágább ágát.
Utána ellenőrizd a stabilitást az átvitel alatt, mert az alagút, amely egy nagy feltöltés közepén megújítja a kulcsot, méretfüggőnek látszó hibát okoz anélkül, hogy az lenne. Az üzemidő-leolvasás a legolcsóbb módja ennek igazolására.
Válassz a javítás és a kerülő megoldás között
Ha a bizonyítékok a méretre mutatnak, két őszinte válasz és egy tisztességtelen van. Az őszinték: helyreállítani az útvonal-MTU felderítését a szükséges ICMP-visszajelzés engedélyezésével, vagy korlátozni a hirdetett szegmensméretet, hogy a partnerek kisebb szegmenseket küldjenek. A tisztességtelen: egy interfész MTU-ját egy fórumról másolt értékre csökkenteni, és soha nem ellenőrizni, mit változtatott.
A választás attól függ, mit irányítasz. Egy általad üzemeltetett hálózaton az ICMP-üzenetek engedélyezése a tisztább javítás, mert minden protokoll számára működőképesen tartja a mechanizmust. Egy nem általad irányított útvonalon a korlátozás a gyakorlati lehetőség, és szűken kell alkalmazni, nem az egész szerverre.
Ha a bizonyítékok az alkalmazásra mutatnak, javítsd az alkalmazást vagy annak proxy-konfigurációját. A 413-as válasz és a megakadt kapcsolat különböző hibák, és a második általában időtúllépés valahol egy láncban, amely saját korlátokkal rendelkező proxyt is tartalmaz.
Akárhogy is, tartsd meg az eredeti értékeket, és a visszaállítás után tesztelj újra. Az átvitellel egybeeső változás nem bizonyíték arra, hogy az okozta, és a visszafordítás képessége az, ami megkülönbözteti a diagnózist a véletlentől.
Rögzítsd a döntést, hogy túlélje a következő esetet
Négy tény elég: a megfigyelt hibaalak, a próbák eredményei, az általad tett változtatás és az újrateszt eredménye. Ezekkel a következő ember meg tudja mondani, ugyanaz-e a probléma, vagy egy új ugyanazzal a tünettel.
Jegyezd fel az útvonal kontextusát is, mert az MTU-megállapítás egy adott kapcsolatra érvényes. Egy laptop, amely otthon működik és egy szállodában meghibásodik, két útvonallal rendelkezik, és az egyiken alkalmazott javítás semmit sem mond a másikról.
Végül ellenállj annak az összefoglalásnak, hogy „a VPN elrontotta a feltöltéseket“. Az alagút jelen volt mind a működő, mind a hibás esetben; ami változott, az a csomag mérete volt, amelyet az útvonalnak szállítania kellett, vagy az a pont, ahol az átvitelt leállították. A tényleges mechanizmus megnevezése teszi hasznossá a jegyzetet.