Запретили доступ к БД — существующее соединение осталось рабочим. Разбор типового отказа zero-trust сегментации на Linux: проверка новым TCP connect подтверждает блокировку, а приложение продолжает читать через открытый пул. Поверхностный диагноз — «политика ещё не доехала». Настоящая причина может лежать прямо в порядке правил. В транзитной цепочке nftables общий ct state established,related accept расположен раньше запрета между сегментами. Пакет существующей сессии получает accept до проверки этого запрета. WireGuard шифрует транспорт, но отзыв доступа за firewall не исполняет. Граница разбора: Linux с conntrack и фильтрацией через nftables; для eBPF datapath нужен разбор его собственной реализации политик. Проверка: nft -a list ruleset показывает цепочки, приоритеты и handles; conntrack -L -p tcp — учтённые соединения; tcpdump -ni wg0 'host 10.42.1.17 and tcp port 5432' — продолжающийся обмен. Если у правил есть counter, сопоставляем прирост packets/bytes у раннего accept и запрета. nfconntrackcount и nfconntrackmax проверяют версию о заполнении таблицы: сами по себе они не доказывают отзыв доступа. Исправление в этой схеме: проверять аварийный запрет раньше общего разрешения established в соответствующей цепочке. Тестировать одновременно новый connect и передачу данных по заранее открытой сессии, на всех узлах пути. Удаление записи conntrack не заменяет правильную политику. Kubernetes не превращает созданный объект в доказанный запрет: это всё ещё ваша работа. https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=zero-trust-setevaya-segmentatsiya-v-ra