Estoy en mi BTGuard VPN y, aleatoriamente, apareció una ventana emergente de denegación de conexión de parte de Little Snitch. Las notas de la entrada en LS son:
El 29 de mayo de 2019, vpn.btguard.com intentó establecer una conexión entrante con openvpn. La solicitud fue denegada automáticamente porque este tipo de conexión no se puede retrasar.
Respuesta1
Probablemente sea algo así como un paquete perdido de la última vez que estuvo conectado. Por ejemplo, el cliente OpenVPN se reinició, pero el servidor aún intentó enviar datos durante la sesión anterior.
OpenVPN (por defecto y en la configuración de BTGuard) se ejecuta sobre UDP, que es un protocolo de transporte sin estado en el que hayNopaquetes explícitos de 'establecer conexión' o 'desconectar', sin números de secuencia, nada excepto un par de números de puerto.
En TCP, los hosts y los firewalls comienzan a rastrear una conexión tan pronto como ven los paquetes SYN (handshake). Pero en UDP, debido a que no hay ningún paquete de "conexión" de ningún tipo (sólo paquetes de datos), los cortafuegos simplemente comienzan a rastrear las "conexiones" después decualquierpaquete que ven.
En TCP, los hosts y los firewalls olvidan una conexión tan pronto como ven los paquetes FIN (desconexión). Pero en UDP, debido a que no hay ningún paquete de 'desconexión' de ningún tipo, los firewalls deben usar tiempos de espera para expirar las "conexiones" antiguas (por ejemplo, la entrada se elimina cada vez que está inactiva durante 60 segundos, 180 segundos, 10 minutos o similar).
Los programas como OpenVPN, por supuesto, pueden tener comandos de 'conectar'/'desconectar' en su protocolo de capa de aplicación, pero un firewall no sabe nada sobre eso: solo ve UDP con algunos datos dentro.
Entonces lo que sucede a veces es:
O OpenVPN se reinicia/sale y el firewall olvida todas las entradas asociadas con el proceso anterior, o la conexión VPN permanece inactiva durante tanto tiempo que el firewall se olvida debido a que llega al tiempo de vencimiento.
Sin embargo, el servidor BTGuard no ha recibido el paquete de "desconexión" de OpenVPN y tampoco ha olvidado la conexión debido al tiempo de espera, por lo que intenta enviarle algunos datos a través de la sesión anterior.
El firewall ve el paquete entrante y tieneno hay forma de saberloya sea una nueva "conexión" o si pertenece a una previamente establecida. (Y tampoco tiene forma de saber si se estableció originalmente hacia afuera o hacia adentro).
Debido a que el firewall no recuerda este par de puertos (debido a que lo olvidó en la parte 1), simplemente asume que tiene que ser nuevo. Y como es un paquete entrante, el firewall muestra una advertencia sobre "conexión entrante".
Es una suposición, pero es una suposición decente.