Observador d'estat d'OpenVPN en C#: vigila la sessió, no la targeta de xarxa

La teva aplicació continua funcionant mentre el túnel mor. El Wi-Fi encara és actiu, la internet encara respon, i l'API privada de la qual depèn l'aplicació ha esdevingut inabastable. L'esdeveniment de .NET al qual la gent sol recórrer aquí, NetworkAvailabilityChanged, no descriu gens aquesta situació. Informa d'un canvi en la condició agregada de la màquina, i aquesta condició pot continuar sent certa durant una desconnexió i reconnexió de VPN. Un observador ha de vigilar el client que posseeix el túnel, no el resum de la pila de xarxa.

La disponibilitat és un agregat, no el teu túnel

NetworkAvailabilityChanged s'activa quan canvia la resposta agregada de disponibilitat de la màquina, i aquesta resposta compta qualsevol interfície activa que no sigui loopback ni un túnel.

Una caiguda de la VPN mentre el Wi-Fi és actiu no canvia res del que mesura, i per això l'esdeveniment pot quedar silenciós just durant la fallada que t'importa.

El flux d'estat pertany al client que posseeix el túnel

Identifica quin component posseeix la connexió: la GUI o el servei d'OpenVPN, OpenVPN Connect, o un procés que la teva aplicació ha iniciat i controla. Són propietaris diferents amb interfícies compatibles diferents, i l'observador ha d'usar la que correspongui al desplegament. Per a un procés d'OpenVPN amb el qual estàs autoritzat a integrar-te, la interfície de gestió informa de l'estat actual, un historial i notificacions en temps real. Analitza els missatges estructurats documentats en lloc de buscar la paraula connected en un títol de GUI localitzat.

El canal de gestió és una superfície de control privilegiada, així que no obris un nou oient ni discuteixis amb la GUI per un canal que ja té.

Les proteccions de generació aturen els resultats obsolets

Cada observació pertany a un intent de connexió concret. Incrementa un comptador de generació quan comença un intent nou, quan es perd el canal i quan el client informa de la sortida.

Considera una sonda iniciada durant la connexió A. El túnel cau, comença la connexió B, i després arriba l'èxit HTTP endarrerit d'A. Sense una protecció, aquell resultat antic posa la pantalla en verd mentre B encara s'autentica. La cancel·lació redueix la feina malgastada, i la comprovació de generació és el que impedeix que una finalització obsoleta es converteixi en estat actual:

var generation = _generation;
var reachable = await ProbeAsync(token);
if (generation != _generation) return;
Publish(reachable);

Aplica la mateixa regla al voltant de l'enviament a la UI, perquè l'actualització empaquetada pot arribar després que la generació hagi avançat.

La inicialització i la reconnexió són un sol cicle de vida

Tracta la primera connexió, la reconnexió i la pèrdua de canal com un sol cicle de vida amb un conjunt de regles:

• Llegeix l'estat actual i subscriu-te a les notificacions en un sol pas on la interfície ho permeti.
• Etiqueta cada observació amb la identitat de la connexió i la generació.
• Invalida la disponibilitat en la reconnexió, la sortida o un canal d'observació perdut.
• Sondeja el recurs privat només després que el propietari informi que la inicialització s'ha completat.
• Publica només els resultats que encara pertanyen a la generació actual.

Un canal perdut significa desconegut, no desconnectat. Informar de desconegut és més honest que informar d'una desconnexió que no pots demostrar, i evita que la lògica de reintents actuï sobre una conjectura.

Informa d'evidència, no d'un booleà

Retorna l'estat de sessió anomenat i la disponibilitat del recurs com a valors separats, cadascun amb una edat. Un consumidor que ha de decidir alguna cosa pot veure llavors que l'última sonda reeixida té quaranta segons, que és una informació diferent d'una de fresca.

Una consulta d'IP pública no és evidència que una API privada hagi usat la ruta requerida, així que no ho presentis com si ho fos.

Mantén l'aplicació fora de l'observador

Una devolució de trucada s'executa després del fet. No pot garantir que cap paquet hagi sortit de la màquina entre l'esdeveniment i el gestor. Si el disseny requereix bloqueig, la política de xarxa l'ha de proporcionar, i la feina de l'observador és explicar l'evidència al seu cridador. Barrejar les dues coses produeix codi que creu que és un tallafoc perquè té un booleà. Mantén la capa d'aplicació avorrida i provable, i deixa que l'observador segueixi sent un lector.

Aleshores la qüestió de la UI esdevé simple: mostra què se sap, amb la seva edat, i digues desconegut quan ho sigui.