Les pàgines carreguen però les pujades s'encallen a la VPN: quina causa guanya
Un encallament que depèn de la mida encaixa amb una fallada d'MTU del camí, i també amb DNS, un límit de l'aplicació o un túnel inestable. Quatre observacions decideixen quin és.
Les pàgines carreguen, la VPN diu que està connectada i una pujada de fitxer es congela sempre al mateix punt. Quatre explicacions encaixen amb aquesta descripció: un problema de mida de paquet, un problema de resolució de noms, un límit de l'aplicació i un túnel que es reinicia constantment. Cadascuna es pot confirmar o descartar amb una observació diferent, així que la decisió és qüestió d'escollir la prova adequada i no d'endevinar la causa.
Quatre candidats i una forma
Comença per la forma de la fallada, perquè elimina la major part de la llista abans que s'obri cap eina. Un encallament que passa a una mida constant és un problema de mida fins que es demostri el contrari. Un encallament en punts aleatoris és un problema de pèrdua o d'estabilitat. Una fallada abans que s'obri la connexió és un problema de noms.
El quart candidat és l'aplicació. Els límits de pujada, els temps d'espera de les sol·licituds i els topalls de mida del cos del proxy produeixen fallades que, des del navegador, semblen errors de xarxa, i normalment arriben com un rebuig i no com un penjament.
Anota la forma observada abans de provar res. «S'atura a aproximadament el mateix nombre de bytes, cada vegada, amb el túnel aixecat» és un punt de partida molt més fort que «les pujades no funcionen».
Després mantén el camí fix mentre proves. Canviar la sortida, el protocol i el servidor alhora produeix un resultat que no pots atribuir a cap d'ells. Una variable per execució, i anota-la.
Divideix la mida abans de tocar la política
El discriminador més barat és una sonda que varia un sol número. Envia pings sense fragmentació de mida creixent cap a la destinació, puja un fitxer que controlis al mateix servei i compara on s'atura cadascun.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadLa primera ordre informa si un paquet de mida completa sobreviu al camí. Amb una MTU de 1500 bytes, la càrrega ICMP més gran que no es fragmenta és de 1472 bytes, i un túnel en treu encara més d'aquest pressupost abans que comenci el paquet interior. La segona et dona una mida i una durada per a una transferència a nivell d'aplicació, que és el número que realment importa.
| 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 |
Llegeix la parella juntament. Sondes que fallen per sobre d'un llindar i una pujada que s'atura prop del mateix llindar és una història coherent. Sondes que tenen èxit totes mentre la pujada s'encalla en un nombre de bytes que el camí clarament transporta apunten a l'aplicació o al servidor, i cap treball d'MTU ho canviarà. Aquest resultat negatiu val tant com un de positiu. Elimina la branca més cara de la investigació.
Després comprova l'estabilitat durant la transferència, perquè un túnel que renova la clau al bell mig d'una pujada gran produeix una fallada que sembla dependre de la mida sense fer-ho. La lectura del temps de funcionament és la manera més barata de confirmar-ho.
Decideix entre una reparació i una solució provisional
Si les proves apunten a la mida, hi ha dues respostes honestes i una de deshonesta. Les honestes són restaurar el descobriment d'MTU del camí permetent la retroalimentació ICMP necessària, o fixar la mida de segment anunciada perquè els parells enviïn segments més petits. La deshonesta és baixar l'MTU d'una interfície a un valor copiat d'un fòrum i no verificar mai què ha canviat.
L'elecció depèn del que controles. En una xarxa que operes, permetre els missatges ICMP és la solució més neta perquè manté el mecanisme funcionant per a cada protocol. En un camí que no controles, fixar la mida és l'opció pràctica, i cal aplicar-la de manera estreta i no a tot el servidor.
Si les proves apunten a l'aplicació, repara l'aplicació o la seva configuració de proxy. Una resposta 413 i una connexió penjada són fallades diferents, i la segona sol ser un temps d'espera en algun punt d'una cadena que inclou un proxy amb els seus propis límits.
De qualsevol manera, conserva els valors originals i torna a provar després de revertir. Un canvi que coincideix amb una transferència correcta no és prova que l'hagi causada, i la capacitat de desfer-lo és el que separa un diagnòstic d'una coincidència.
Registra la decisió perquè sobrevisqui al proper incident
Quatre fets són suficients: la forma observada de la fallada, els resultats de les sondes, el canvi que has fet i el resultat de la repetició de la prova. Amb ells, la propera persona pot dir si el problema és el mateix o un de nou amb el mateix símptoma.
Anota també el context del camí, perquè una troballa d'MTU és específica d'un enllaç. Un portàtil que funciona a casa i falla en un hotel té dos camins, i una solució aplicada a un d'ells no diu res de l'altre.
Finalment, resisteix el resum que «la VPN va trencar les pujades». El túnel era present tant en el cas que funcionava com en el que fallava; el que va canviar va ser la mida del paquet que el camí havia de transportar, o on es va aturar la transferència. Anomenar el mecanisme real és el que fa útil la nota.