Шифрование данных при передаче: TLS, SSH, IPsec и VPN. Настройка, конфиги и типичные ошибки

Что такое шифрование данных при передаче и зачем оно нужно

Шифрование при передаче закрывает три практические угрозы: чтение трафика посторонним, подмену данных или узла на маршруте, анализ соединений для блокировок. Пока данные идут открытым текстом, любой, кто получил доступ к каналу, видит пароли, сессионные токены, содержимое запросов и метаданные сессий.

Пассивный перехват. Достаточно запустить tcpdump на промежуточном хосте или включить зеркалирование порта (SPAN) на коммутаторе, чтобы получить полный дамп чужого трафика. Ни один пакет при этом не уходит в сторону цели, поэтому факт съёма данных заметить сложно.

Атака "человек посередине" (MITM). ARP-spoofing в локальном сегменте, подмена DNS-ответа, подмена сертификата на недоверенном шлюзе дают возможность читать и править данные на лету. Защита строится на проверке сертификата или ключа, а не на самом факте шифрования.

DPI и фильтрация. Системы глубокого анализа пакетов распознают протокол по отпечатку, прерывают или замедляют соединение и накапливают сигнатуры для будущих блокировок. Для инженера это означает простую вещь: выбор протокола зависит от криптостойкости и от того, как трафик выглядит снаружи.

Шифрование канала не отменяет аутентификацию и контроль доступа. Трафик, зашифрованный до чужого узла, защищает лишь от наблюдателя. Открытые админ-панели и веб-интерфейсы закрывают отдельно: базовый набор мер собран в руководстве по защите веб-интерфейсов роутера, сервера и сетевых устройств.

Дальше четыре механизма разобраны по зонам ответственности. TLS отвечает за веб-трафик, API и почтовые сессии. SSH закрывает удалённое администрирование и туннели. IPsec шифрует трафик между шлюзами на сетевом уровне. WireGuard и OpenVPN дают удалённый доступ и связывают площадки. Для каждого приведены рабочие конфиги и ошибки, которые снижают защиту незаметно.

Как работает TLS: рукопожатие, обмен ключами и алгоритмы шифрования

TLS работает поверх TCP (в HTTP/3 поверх QUIC) и защищает отдельное соединение между клиентом и сервером. Протокол решает три задачи: согласование алгоритмов, аутентификация сервера или обеих сторон, шифрование и проверка целостности данных.

Рукопожатие TLS 1.3 занимает один round-trip до отправки первых байтов прикладных данных:

1. ClientHello. Клиент перечисляет версии, наборы шифров, поддерживаемые группы для обмена ключами и сразу отправляет публичный ключ (key_share) для X25519 или secp256r1. Туда же уходят SNI с именем хоста и список алгоритмов подписи.
2. ServerHello. Сервер выбирает набор шифров и группу, присылает свой key_share. В том же полёте идут EncryptedExtensions, Certificate с цепочкой, CertificateVerify с подписью и Finished. Всё, начиная с ServerHello, зашифровано.
3. Клиент проверяет цепочку сертификатов и подпись, подтверждает завершение. После этого идут прикладные данные.

Обмен ключами строится на ECDHE: обе стороны вырабатывают общий секрет из эфемерных приватных ключей и удаляют их после сессии. Отсюда Perfect Forward Secrecy (PFS): компрометация долговременного ключа сертификата не раскрывает ранее записанный трафик.

Симметричное шифрование после рукопожатия: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305. Это AEAD-шифры, они шифруют данные и проверяют целостность одной операцией. Хеш SHA-256 или SHA-384 выводит ключи из общего секрета.

Сертификаты образуют цепочку доверия: лист, промежуточный и корневой. Сертификаты Let's Encrypt выдаются на 90 дней и продлеваются автоматически, wildcard закрывает произвольные поддомены, поле SAN перечисляет все имена, для которых сертификат действителен. TLS 1.0 и 1.1 отключены в Chrome и Firefox с 2020 года, включать их в 2026 году нет причин.

Проверка согласованных параметров на живом хосте:

openssl s_client -connect example.com:443 -tls1_3 -servername example.com

...
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Verify return code: 0 (ok)

Строка Cipher показывает симметричный алгоритм, Protocol версию протокола, Verify return code результат проверки цепочки. Код 0 означает, что сертификат валиден и цепочка собрана полностью.

Разница между TLS 1.2 и TLS 1.3 на практике

Основное отличие в числе round-trip: TLS 1.3 тратит один RTT на рукопожатие, TLS 1.2 два. При типичном RTT 40-60 мс между клиентом и сервером экономия составляет те же 40-60 мс на каждое новое соединение. Повторное подключение по session resumption в TLS 1.3 работает в режиме 0-RTT, и у него есть цена: ранние данные можно воспроизвести, поэтому их не применяют для операций, чувствительных к повторам.

Из TLS 1.3 убрали статические схемы обмена ключами RSA и DH, а вместе с ними RC4, 3DES, CBC-режимы и компрессию. PFS стал обязательным для всех наборов. Список шифров сократился до пяти AEAD-комбинаций, ошибиться в конфигурации стало сложнее. Побочный эффект: попытка downgrade до 1.2 видна в логах, чего не было при переходе с 1.1 на 1.2.

Nginx поддерживает TLS 1.3 с версии 1.13.0 при сборке с OpenSSL 1.1.1 или новее. Проверить сборку: nginx -V 2>&1 | grep -o 'OpenSSL [0-9.]*'.

Какие алгоритмы шифрования использует TLS и что выбрать

Для TLS 1.3 набор задаётся отдельно от ssl_ciphers. Рабочий список из трёх наборов:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Для TLS 1.2 оставьте только схемы с ECDHE и AEAD:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

Выбор между AES-GCM и ChaCha20 зависит от железа. На x86_64 с AES-NI аппаратное ускорение даёт AES-GCM заметный перевес. На мобильных ARM без AES-NI и на старых ядрах ChaCha20-Poly1305 быстрее и меньше расходует батарею. В TLS 1.2 порядок в ssl_ciphers действует при включённом ssl_prefer_server_ciphers, для 1.3 применяется директива ssl_conf_command Ciphersuites.

SSH: аутентификация по ключам и шифрование туннелей

SSH шифрует весь сеанс: обмен ключами, аутентификацию, каналы данных и служебный трафик. Протокол разбит на три слоя: транспортный (KEX, шифр, целостность), аутентификация пользователя и мультиплексирование каналов для сессий, проброса портов и SFTP.

Типы ключей. Ed25519 даёт около 128 бит стойкости при ключе в 32 байта и работает быстрее RSA. RSA 4096 нужен для совместимости со старыми системами. ECDSA на кривых NIST применяют реже из-за вопросов доверия к параметрам. Генерация ключа:

ssh-keygen -t ed25519 -a 100 -C "admin@laptop"

Флаг -a задаёт число проходов KDF для пароля приватного ключа: сто проходов заметно замедляют перебор.

Рабочий фрагмент sshd_config с закрытой политикой доступа:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy admin
ClientAliveInterval 300
ClientAliveCountMax 2
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Для обмена ключами используется curve25519-sha256 или ecdh-sha2-nistp256, для шифрования chacha20-poly1305@openssh.com и aes256-gcm@openssh.com. Устаревшие ssh-rsa с SHA-1 и diffie-hellman-group1-sha1 отключены в OpenSSH по умолчанию, но остаются прописанными в конфигах, которые переносят между серверами годами.

SSH-порт, открытый в интернет, ежедневно получает тысячи попыток входа. Помогают fail2ban с баном после 3-5 неудач, доступ только с известных адресов через AllowUsers и Match Address, port knocking или перенос порта за VPN. Смена порта защитой не считается: сканирование находит SSH на любом порту за минуты.

Настройка SSH-туннеля: локальный, удалённый и динамический

Локальный туннель (-L) пробрасывает порт с вашей машины на удалённый хост через SSH-сервер. Пример доступа к PostgreSQL, который слушает только localhost:

ssh -N -L 5432:localhost:5432 user@db-server

После этого psql -h localhost -p 5432 подключается к базе так, будто она локальная. Флаг -N отключает запуск shell, туннель остаётся единственной задачей сессии.

Удалённый туннель (-R) работает в обратную сторону и публикует локальный сервис на удалённом хосте. Команда ssh -N -R 8080:localhost:3000 user@public-server сделает приложение на порту 3000 доступным на порту 8080 удалённой машины. По умолчанию такие порты слушают только loopback. Чтобы открыть их наружу, на сервере нужен GatewayPorts yes, а вместе с ним и осознанное решение: сервис окажется доступен всем, кто дотянется до порта.

Динамический туннель (-D) поднимает SOCKS5-прокси: ssh -N -D 1080 user@jump-host. Браузер с настройкой socks5://localhost:1080 начнёт ходить через jump-host, а трафик между вами и сервером будет зашифрован. Разбор сценариев, автозапуска и диагностики собран в руководстве по настройке SSH-туннеля.

Флаги для стабильной работы: -o ServerAliveInterval=60 отправляет keepalive каждую минуту, -o ExitOnForwardFailure=yes завершает сессию, если проброс порта не удался, -o TCPKeepAlive=yes. Без ExitOnForwardFailure туннель поднимается без проброса и молча не работает.

Типичные ошибки в конфигурации SSH

Список, который стоит проверить на каждом сервере:

• PasswordAuthentication yes. Пароль подбирается, ключ практически нет. Отключайте директиву после того, как ключи розданы.
• PermitRootLogin yes. Прямой вход под root лишает вас следов в аудите и обходит политики sudo.
• Нет ограничения по адресам. AllowUsers с привязкой к подсети или Match Address сужают поверхность атаки.
• Устаревшие алгоритмы: ssh-rsa (SHA-1), diffie-hellman-group1-sha1, aes128-cbc, hmac-md5.
• OpenSSH не обновляется. Уязвимости в KEX и обработке ключей закрывают в минорных релизах.

Проверить, что реально согласовалось при подключении: ssh -vvv user@host. В выводе ищите строки debug1: kex: algorithm и debug1: kex: cipher. Если там появился ssh-rsa или CBC-шифр, конфиг тянет устаревшие параметры. Список поддерживаемых алгоритмов локального клиента выводится командами ssh -Q kex и ssh -Q cipher.

IPsec и VPN: шифрование на сетевом уровне

IPsec шифрует IP-пакеты целиком и работает на сетевом уровне, поэтому приложения о нём не знают. В Linux обработка ESP идёт в ядре через подсистему XFRM, а демоны strongSwan или Libreswan управляют политиками и ключами.

Два режима. Transport шифрует только полезную нагрузку и подходит для связи двух хостов. Tunnel инкапсулирует исходный пакет в новый и применяется на шлюзах, это режим любого site-to-site VPN.

Протоколы. AH (номер 51) даёт аутентификацию и целостность без шифрования, с NAT несовместим, поэтому в новых проектах не используется. ESP (номер 50) шифрует и аутентифицирует данные, поддерживает NAT-T через инкапсуляцию в UDP 4500. IKEv2 по UDP 500 и 4500 отвечает за аутентификацию сторон и обмен ключами, PFS обеспечивает новый обмен Диффи-Хеллмана на каждый реkey.

Отличие от TLS по зоне ответственности: IPsec прозрачен для приложений и настраивается на обеих сторонах шлюза, TLS привязан к конкретному соединению и приложению. Для межсетевого взаимодействия выбирают IPsec, для защиты веб-трафика TLS.

Настройка IPsec VPN: базовый сценарий site-to-site

Пример конфига strongSwan для связи двух офисов. Файл /etc/ipsec.conf:

conn %default
    keyexchange=ikev2
    ike=aes256-sha256-modp2048
    esp=aes256-sha256
    dpdaction=restart
    dpddelay=30s
    ikelifetime=8h
    lifetime=1h

conn office-to-office
    left=203.0.113.10
    leftsubnet=192.168.10.0/24
    right=198.51.100.20
    rightsubnet=192.168.20.0/24
    leftauth=pubkey
    rightauth=pubkey
    auto=start

Аутентификация через сертификаты предпочтительнее PSK: общий секрет на двух шлюзах придётся менять при уходе любого инженера, а компрометация PSK раскрывает весь трафик. Если хотя бы одна сторона за NAT, нужен encap=yes, чтобы strongSwan применял NAT-T принудительно.

MTU согласовывать обязательно. Заголовки ESP и внешнего IP добавляют к пакету 50-73 байта, поэтому при MTU 1500 полезная нагрузка должна укладываться примерно в 1400 байт. Без MSS clamping крупные пакеты молча теряются: TCP-сессия открывается, а скачивание файлов зависает. Директива на шлюзе:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

WireGuard и OpenVPN: современные VPN-решения

WireGuard вошёл в ядро Linux в версии 5.6 и использует фиксированный набор криптографии: Curve25519 для обмена ключами и подписей, ChaCha20 для шифрования, Poly1305 для аутентификации, BLAKE2s для хеширования. Объём кода около 4000 строк, поэтому аудит реален. Data plane работает в ядре, пропускная способность близка к линейной скорости интерфейса, нагрузка на CPU ниже, чем у userspace-решений.

Минимальный серверный конфиг /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = [приватный ключ сервера]
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = [публичный ключ клиента]
AllowedIPs = 10.8.0.2/32

OpenVPN работает в userspace и строит туннель поверх TLS, поэтому поддерживает TCP и UDP, мосты, плагины и гибкие схемы маршрутизации. Цена гибкости: дополнительные копирования данных между ядром и приложением, выше нагрузка на CPU, стандартный порт 1194 часто закрыт провайдерами и системами фильтрации. WireGuard выигрывает на скоростях выше 1 Гбит/с и на слабом железе, OpenVPN остаётся вариантом для сложных схем доступа.

В сетях с фильтрацией скорость перестаёт быть единственным критерием. Системы DPI научились выявлять отпечатки WireGuard и Shadowsocks и прерывать соединение на лету. В России работает ТСПУ: прослойка между провайдерами и магистральными каналами, которая централизованно фильтрует трафик по единым правилам, замедляет подозрительные соединения и накапливает сигнатуры. Блокируются стандартный порт OpenVPN 1194, альтернативные порты и целые диапазоны облачных провайдеров, включая AWS, Google Cloud и DigitalOcean. Часть сервисов маскирует VPN-трафик под обычный HTTPS-поток именно для обхода DPI.

Когда нужен доступ к API нейросетей из сети с фильтрацией, задачу решают иначе: берут агрегаторы с оплатой в рублях, например AiTunnel, который даёт единый интерфейс к более 200 моделям и не требует VPN.

Корпоративный пример другого подхода, шлюзы ViPNet Coordinator из линейки ViPNet Network Security. Они совмещают роли маршрутизатора VPN-пакетов, VPN-шлюза, межсетевого экрана, транспортного сервера и сервера IP-адресов, выполняют шифрование и имитозащиту IP-пакетов, поддерживают защиту соединений сетевого (L3) и канального (L2) уровней OSI. Маскирование структуры трафика достигается инкапсуляцией в UDP и TCP, что сохраняет совместимость с DHCP, WINS, DNS, NAT/PAT и мультимедийными протоколами SIP, H323, SCCP. Типовые сценарии: каналы между офисами (site-to-site и multi site-to-site), доступ удалённых и мобильных пользователей, защита магистральных каналов между ЦОД, сегментирование локальных сетей с выделением DMZ. Аппаратные координаторы разворачивают в кластере горячего резервирования, а специальная архитектура файловой системы не даёт испортить образ ОС и ПО при сбоях питания. Центр генерации ключей вынесен в отдельное ПО ViPNet Administrator.

Пошаговая настройка шифрования: Nginx, SSH-туннель, VPN

Настройка TLS на Nginx: конфиг и проверка

Сертификат Let's Encrypt для домена и www-алиаса:

certbot --nginx -d example.com -d www.example.com --agree-tos -m admin@example.com --redirect

Флаг --redirect добавляет постоянный редирект с HTTP на HTTPS, certbot сам создаёт таймер systemd для обновления. Готовый server block:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;
    ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Что здесь важно. ssl_session_tickets off закрывает риск расшифровки прошлых сессий при утечке тикет-ключа, ssl_stapling on ускоряет проверку отзыва сертификата, ssl_dhparam не нужен, потому что DHE-шифры исключены из списка. После правки конфигурации: nginx -t, затем systemctl reload nginx.

Проверка: openssl s_client -connect example.com:443 -tls1_3, sslyze --regular example.com, testssl.sh --fast example.com. Ожидаемый результат: доступны только TLS 1.2 и 1.3, все наборы с ECDHE и AEAD, включены HSTS и OCSP stapling. Разбор выпуска сертификатов и ошибок цепочки с примерами для Nginx и Apache есть в руководстве по ручной установке SSL-сертификата на Nginx и Apache.

SSH-туннель: команда и автозапуск через systemd

ssh -N -L 5432:localhost:5432 user@db-server -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes

Автозапуск через unit-файл /etc/systemd/system/ssh-tunnel-db.service:

[Unit]
Description=SSH tunnel to PostgreSQL
After=network-online.target
Wants=network-online.target

[Service]
User=tunnel
ExecStart=/usr/bin/ssh -N -L 5432:localhost:5432 user@db-server -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o BatchMode=yes
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Дальше systemctl daemon-reload и systemctl enable --now ssh-tunnel-db. BatchMode=yes запрещает запрос пароля и гарантирует, что сервис не зависнет на приглашении ввода. Ключ для пользователя tunnel кладут без пароля, а на сервере ограничивают права через authorized_keys с опциями: command="", no-pty, no-agent-forwarding, permitopen="localhost:5432". Такая запись даёт доступ ровно к одному порту.

WireGuard: генерация ключей и запуск

umask 077
wg genkey | tee privatekey | wg pubkey > publickey
chmod 600 privatekey publickey

Серверный конфиг /etc/wireguard/wg0.conf с маршрутизацией трафика клиентов:

[Interface]
PrivateKey = [приватный ключ сервера]
Address = 10.8.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = [публичный ключ клиента]
AllowedIPs = 10.8.0.2/32

Конфиг клиента:

[Interface]
PrivateKey = [приватный ключ клиента]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = [публичный ключ сервера]
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

AllowedIPs 0.0.0.0/0 отправляет весь трафик в туннель, 10.8.0.0/24 оставляет только внутреннюю сеть, это split tunneling. На сервере нужен net.ipv4.ip_forward=1 в /etc/sysctl.d/99-wireguard.conf. Запуск и автозагрузка: wg-quick up wg0, systemctl enable wg-quick@wg0. Проверка: wg show показывает время последнего handshake и объём переданных байт. Отсутствие свежего handshake через 2-3 минуты означает, что пакеты не доходят.

Публичному VPN-шлюзу нужен сервер с белым IP и запасом по трафику: подойдёт, например, Timeweb Cloud, где машина с публичным адресом поднимается за пару минут, а ресурсы меняются по нагрузке. Маршрутизацию и NAT на таком шлюзе удобнее держать на nftables, тонкости собраны в руководстве по маршрутизации VPN на Linux с iptables, nftables и eBPF.

Типичные ошибки конфигурации, которые снижают защиту

Большинство инцидентов с шифрованием связано не со взломом криптографии, а с конфигурацией, которая тихо откатывает защиту на уровень десятилетней давности. Ниже ошибки по протоколам, способ проверки и исправление.

Ошибки конфигурации TLS: как найти и исправить

• Поддержка TLS 1.0 и 1.1. Проверка: nmap --script ssl-enum-ciphers -p 443 example.com. Исправление: ssl_protocols TLSv1.2 TLSv1.3.
• Слабые шифры RC4, 3DES, CBC и экспортные наборы. Проверка: testssl.sh --fast example.com. Исправление: только ECDHE и AEAD в ssl_ciphers.
• Самоподписанный сертификат в продакшене. Браузеры показывают предупреждение, пользователи привыкают его игнорировать, и MITM проходит незамеченным. Исправление: сертификат от центра сертификации.
• Неполная цепочка: лист отдаётся без промежуточного сертификата. Проверка: openssl s_client -connect example.com:443 -showcerts, код возврата 20 или 21. Исправление: fullchain.pem вместо cert.pem.
• Отсутствие HSTS. Первый запрос по HTTP уходит открытым и уязвим к SSL-strip. Исправление: add_header Strict-Transport-Security.
• Отключённый OCSP stapling. Браузер сам идёт к центру сертификации, проверка замедляется и зависит от доступности чужого сервиса.

Ошибки в SSH и VPN: чек-лист для аудита

• sshd_config: PasswordAuthentication yes, PermitRootLogin yes, MaxAuthTries без ограничения, пустой AllowUsers.
• Устаревшие алгоритмы: ssh-rsa, diffie-hellman-group1-sha1, aes128-cbc, hmac-md5. Проверка: ssh -Q kex, ssh -Q cipher и ssh -vvv к серверу.
• SSH-порт открыт в интернет без fail2ban и ограничений по адресам.
• IPsec на PSK вместо сертификатов и без PFS. Проверка: ipsec statusall, в выводе должна быть указана DH-группа для каждого реkey.
• Неправильный MTU. Туннель поднялся, ping проходит, крупные пакеты теряются. Проверка: ping -M do -s 1400 через туннель, затем уменьшайте размер до первого успеха.
• Ротация ключей не настроена: один и тот же ключ WireGuard живёт годами, при утечке конфига доступ получает посторонний. Исправление: ikelifetime и lifetime в IPsec, плановая смена ключей и перевыпуск peer-конфигов в WireGuard.
• DNS-утечки при split tunneling: клиент ходит во внутренние ресурсы через туннель, а запросы имён уходят провайдеру. Проверка: tcpdump -i wg0 port 53 и контроль DNS в конфиге клиента.

Общая ошибка, которая перекрывает остальные: уверенность, что шифрование само по себе даёт безопасность. Без аутентификации сторон, контроля доступа и аудита ключей канал защищает от наблюдателя и не защищает от активного противника.

Шифрование канала работает в паре с защитой данных при хранении: если файлы лежат на диске открыто, перехват трафика уже не главная проблема. Схемы шифрования документов, аудита доступа и предотвращения утечек разобраны в руководстве по защите документов при хранении.

Как проверить, что шифрование работает корректно

Проверка строится на трёх вопросах: какой протокол и шифр согласовались, есть ли PFS, не видно ли открытых данных в дампе трафика.

• TLS: openssl s_client -connect example.com:443 -tls1_3 -servername example.com, затем sslyze --regular example.com и nmap --script ssl-enum-ciphers -p 443. Смотрите строки Protocol, Cipher и отметку о поддержке PFS в отчёте sslyze.
• SSH: ssh -vvv user@host, строки kex: algorithm, kex: host key algorithm, kex: cipher. Убедитесь, что нет CBC и ssh-rsa с SHA-1.
• Трафик: tcpdump -i eth0 -A port 80 и tcpdump -i eth0 -A port 443. В первом случае видны заголовки и полезная нагрузка, во втором только зашифрованный поток. Это самая быстрая демонстрация, что шифрование включено.
• WireGuard: wg show, поле latest handshake не старше двух минут, счётчики transfer растут.
• IPsec: ipsec statusall, состояние ESTABLISHED для нужных туннелей и список активных SA.
• Маршрутизация и DNS: проверьте, что внутренние адреса идут через туннель, а запросы имён не уходят провайдеру, на клиенте посмотрите ip route get 10.8.0.1.

Минимальный чек-лист после настройки: версия протокола не ниже TLS 1.2 или IKEv2, все шифры с AEAD и ECDHE, PFS включён, сертификаты валидны и обновляются автоматически, приватные ключи хранятся с правами 600, доступ ограничен по адресам, в дампе трафика нет читаемых данных.

Что выбрать: сравнение TLS, SSH, IPsec и VPN

Таблица по критериям, которые влияют на выбор в рабочей инфраструктуре.

Как выбирать по задаче. Защита сайта или API: TLS 1.2 и 1.3 с сертификатом от центра сертификации. Управление серверами и доступ к внутренним сервисам без VPN: SSH-ключи и туннели. Связка двух офисов или ЦОД: IPsec с IKEv2 и сертификатами. Удалённый доступ сотрудников: WireGuard, а при жёстких требованиях к гибкости схемам маршрутизации OpenVPN.

В корпоративной среде протоколы работают вместе: TLS защищает приложения, IPsec соединяет площадки, SSH закрывает управление. Дублировать функции не нужно. Проверьте, что каждая зона закрыта своим механизмом, ключи ротируются по расписанию, а конфигурация проходит регулярный аудит командами из чек-листов выше.