Quin salt NAT deixa caure el mapatge VPN inactiu i com saber-ho
Un flux VPN inactiu pot morir en qualsevol salt amb estat. Repetiu una prova, compareu què ha vist cada frontera i informeu del resultat acotat en lloc d’un culpable suposat.
Després d’un període de calma el túnel es reconnecta, cap registre no assenyala cap culpable, i el moviment obvi és triar el dispositiu amb la documentació de temps d’espera més impressionant. Això és una conjectura disfressada de diagnòstic. L’estat pot sobreviure una estona en un encaminador domèstic, en un traductor de l’operadora i a la vora del núvol, i qualsevol d’ells pot deixar caure un flux que s’atura. El que sí que podeu fer és mapar el camí, marcar quins dispositius realment podeu observar i fer una prova d’inactivitat que pugueu repetir.
Una prova repetible converteix una anècdota en un mesurament. Tot el que segueix assumeix un client, un servidor i un protocol, i assumeix que us resistiu a canviar dues variables alhora. La idea és fer que la propera ocurrència surti més barata que aquesta.
Feu la mateixa prova d’inactivitat cada vegada
Anoteu quan el flux va ser bo per última vegada, quant de temps va estar inactiu després i si un sol paquet nou el va recuperar. Aquests tres fets són el mesurament; sense ells teniu una història sobre un portàtil que va caure. Feu servir el mateix client, el mateix servidor i el mateix protocol a cada repetició, i anoteu el moment en què es va enviar el primer paquet després del silenci.
Després compareu què ha vist realment cada frontera que poseeix. La distinció que decideix la investigació és si el servidor no va veure res de cap mena després de la pausa, o bé va veure la petició i va respondre cap a un camí que ja no portava les respostes.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Comparar camins sense canviar cinc coses
Una segona xarxa d’accés aprovada és una comparació legítima, perquè la cadena NAT és diferent. També difereix en proveïdor, condicions de ràdio i potser família d’adreces, així que el resultat és una frontera i no una atribució. Registreu les limitacions amb el resultat en lloc de deixar-les caure en silenci quan informeu. De passada, anoteu el camí: dispositiu, paper i si el seu estat es pot llegir.
El que us compra comparar camins és una pregunta acotada: el flux sobreviu en un i mor en l’altre després d’un silenci similar, així que la variable viu en algun punt de les parts que difereixen. És un resultat real encara que no s’anomeni cap dispositiu, i diu al proper enginyer on gastar una tarda i on no.
Val la pena llegir l’estat local abans de especular sobre les operadores. En una passarel·la Linux, conntrack -L llista els fluxos seguits amb la seva vida restant, cosa que converteix una conjectura sobre un temporitzador en un número que podeu veure expirar. Llegiu-lo abans i després del període d’inactivitat, no només després.
Què aguantarà un senyal de manteniment i què no
Un senyal de manteniment suportat manté un mapatge obert, i mantenir un mapatge obert no demostra res sobre el servei que hi ha darrere. El túnel pot quedar mapejat mentre l’aplicació que porta ha deixat de respondre, i des d’un llum d’estat aquestes dues situacions semblen iguals. Tracteu el senyal de manteniment com una assegurança contra el venciment per inactivitat, no com una comprovació de salut.
Fixeu l’interval segons el temps d’espera més curt que hàgiu mesurat de veritat, no segons un número copiat d’un fòrum. Un senyal de manteniment ajustat per sota de qualsevol temporitzador plausible és trànsit que ningú no necessitava, i també elimina el símptoma que us hauria dit quina frontera venç primer. Trieu l’interval a partir del número mesurat i deixeu la resta en pau.
Un canvi, i després torneu a mesurar
Resistiu la temptació d’apujar tots els temps d’espera i buidar totes les passarel·les durant una prova en viu. Això esborra l’evidència per la qual heu vingut i interromp fluxos d’altres persones, cosa que és un mal intercanvi per una hipòtesi que no heu provat. Canvieu un paràmetre suportat en un sol dispositiu, i després repetiu el període d’inactivitat i la recuperació de l’aplicació.
Anoteu quina observació de frontera s’ha mogut, i anoteu-ho fins i tot quan no ha millorat res. Un paràmetre que no ha arreglat res és informació, i és més barat adonar-se’n un cop que no pas escampar-ho per tota la instal·lació.
Escriure una troballa que pugueu defensar
Quan un traductor aigües amunt no es pot inspeccionar, digueu només el que l’evidència sosté: l’intercanvi mor en algun punt d’aquest tram del camí després d’aquesta estona de calma, i el salt responsable queda sense atribuir. Una afirmació acotada sobreviu a la revisió i adreça la propera persona al segment correcte. Anomenar un encaminador ocult com a causa no fa ni una cosa ni l’altra. Lliureu la troballa acotada a qui posseeix el segment no observable, amb l’interval adjunt.
RFC 4787 descriu per què els temporitzadors de mapatge UDP són difícils d’inferir des d’un sol extrem, i aquesta dificultat és la raó per la qual la troballa acotada és l’honesta. Els temporitzadors són reals, i també ho és la incertesa que els envolta.