Как проверить наличие шифрования и отвал соединения?

Например, обрывать соединение, если узел внезапно умер

Если узел внезапно умер, соединение оборвётся. Так TCP устроен.

не подключатся если шифрование не заводится

Для этого и существуют протоколы, типа TLS.

А, ну, наверно. Просто может я чего-то не понимаю, протоколы немного изучал, но не очень понял принцип разрыва соединения, просто я видел утечки трафика в openvpn, например. Также при при стандартных настройках сети если сервер умер \ завис (с любым протоколом) то сначала идут несколько несколько повторных пакетов, а потом трафик начинает идти напрямую.

То есть идея в том чтобы не шли повторные попытки подключения (и разрыв был мгновенный, что-то наподобие tcp reset), плюс трафик автоматом не перенаправлялся на другие адреса или интерфейсы.

Проще говоря, если уж шифрование точно проверяется автоматом, то хотелось бы понять как исключить утечки пакетов. У меня есть предположение, что это делается с помощью статической маршрутизации, но, может быть, есть что-то ещё?

То есть идея в том чтобы не шли повторные попытки подключения (и разрыв был мгновенный, что-то наподобие tcp reset)

Зачем? Как клиент должен отличить умерший сервер от случайно потерянного пакета?

Проще говоря, если уж шифрование точно проверяется автоматом, то хотелось бы понять как исключить утечки пакетов.

Зачем? Какая проблема в «утечке пакетов» чтобы это ни было. Утечка пакетов может быть актуальна для VPN, но как она актуальна для ssh и https, я понять не могу.

Зачем?

В каком контексте «зачем»? Чтоб прекратить слать пакеты в никуда или в обход, если сервер завис во время установленного соединения.

Как клиент должен отличить умерший сервер от случайно потерянного пакета?

Этого я не знаю, может быть, по таймеру или проверке флагов tcp.

Зачем? Какая проблема в «утечке пакетов» чтобы это ни было. Утечка пакетов может быть актуальна для VPN, но как она актуальна для ssh и https, я понять не могу.

Ну, наверно, я немного криво привел пример. Естественно я имею в виду туннели и наиболее актуальны утечки для них.

Можно взять простой пример утечки (утечки с точки зрения пользователя). У мобильных операторов актуальна проверка TTL пакета, как только будет обнаружен пакет с неугодным числом, вам приходит смс c просьбой подключить раздачу. Можно на уровне фаервола сделать так, чтоб пакеты со стандартным временем жизни не слались клиентом.

Соответственно, в моем случае я пытаюсь понять как реализовать проверку зависания сервера \ прохождение пакетов только через сервер \ исключение повторных попыток слать пакеты через стандартный маршрут, если сервер завис.

То что ты хочешь принято называть «vpn killswitch». Конкретные решения гугли применительно к своему протоколу.

Например для Windows и Android клиента Wireguard есть прямо такая галочка в настройках.

Для любого протокола в общем случае это решается через фаерволл и роутинг на клиенте:

1. Разрешить исходящий UDP трафик на порт 1194 сервера VPN через eth0
2. Разрешить любой трафик внутри tun0 интерфейса
3. Запретить любой исходящий трафик на eth0 (кроме п.1)
4. Прописать most specific роут до твоего сервера VPN через провайдерский шлюз/домашний роутер
5. Удалить default gw до провайдера/домашнего роутера
6. Добавить default gw через IP VPN сервера через tun0

Спасибо, попробую. По идее, как я и думал, в своей базе все через роутинг идет.