Zero-trust сломался на втором транспорте DNS. Типовой отказ: в распределённом K3s-кластере включили default-deny egress и разрешили до DNS только UDP/53. Короткие ответы проходили. Когда приходил ответ с флагом TC=1, резолвер переходил на TCP/53 и упирался в запрет. Снаружи — выборочные таймауты приложений. Удобный диагноз: «межплощадочная сеть тормозит». Улика — tcpdump -ni any 'port 53' в сетевом namespace проблемного pod. В захвате ищем UDP-ответ с TC=1, затем SYN на TCP/53 без SYN-ACK. Сам по себе такой захват ещё не доказывает блокировку: сопоставляем его с drop verdict или счётчиком правила на узле, где CNI применяет политику. В том же netns команда nstat -az TcpRetransSegs TcpExtTCPSynRetrans показывает накопленные ретрансляции; важен прирост за окно сбоя, а не число с момента запуска. Исправление: разрешить UDP/53 и TCP/53 до фактического DNS-резолвера, проверить маршрут и адрес назначения с учётом NodeLocal DNS, если он используется. Проверки запускаем из затронутого pod: dig +tcp проверяет TCP отдельно, а воспроизведение ответа с TC=1 — переход между транспортами. NetworkPolicy должна поддерживаться и реально исполняться выбранным CNI. Принятый YAML этого не доказывает. Покупка service mesh не допишет забытое правило. Каждый дополнительный слой политик увеличивает число мест, где ночью придётся искать потерянный пакет. Рабочая сегментация требует проверки разрешённых зависимостей и запрещённых соединений после изменения правил. Практика bare-metal эксплуатации: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=zero-trust-setevaya-segmentatsiya-v-ra.
