Network Admin

Сетевой пакет может потеряться ещё внутри NIC В tcpdump нет пакета - легко сделать вывод, что он не пришёл на сервер. Но между физическим портом и tcpdump находится сама сетевой карта. У NIC есть собственные RX ring buffers. Драйвер забирает из них дескрипторы и передаёт полученные данные ядру. При перегрузке очередь может не успеть обработать входящие пакеты:

NIC
 ↓
RX ring
 ↓
driver
 ↓
kernel
 ↓
tcpdump

Если проблема возникает на уровне NIC/driver, пакет может исчезнуть до того, как станет виден обычному packet capture. Поэтому при странных потерях полезно смотреть не только:

ip -s link show eth0

но и аппаратную статистику:

ethtool -S eth0

А размеры RX/TX ring:

ethtool -g eth0

Можно увидеть отдельные counters вроде rx_missed_errors, rx_no_buffer или специфичные для конкретного драйвера drops. Это важный момент при диагностике: если пакет не попал в tcpdump, это ещё не доказывает, что его не получила сетевая карта. N.A.

📂 Linux bridge учит MAC-адреса почти как обычный коммутатор Когда Linux работает как bridge, он не просто механически пересылает Ethernet-кадры между интерфейсами. У него есть собственная forwarding database - FDB. Когда кадр приходит на bridge, ядро смотрит на его source MAC и запоминает, откуда он пришёл:

aa:bb:cc:dd:ee:01 → eth0
aa:bb:cc:dd:ee:02 → eth1

Посмотреть таблицу можно:

bridge fdb show

После этого кадр для aa:bb:cc:dd:ee:02 уже не нужно отправлять на все порты - bridge знает, что destination находится за eth1. Если destination MAC неизвестен, кадр будет flood’иться по подходящим портам. После получения ответа bridge снова обновит FDB. У записей есть timeout, поэтому старый MAC постепенно исчезает:

bridge fdb show br br0

Особенно интересно это проявляется при миграции VM. Было:

VM → eth0

После миграции:

VM → eth1

MAC тот же, но source frames начинают приходить с другого интерфейса. Bridge переучивает запись:

old MAC → eth0
        ↓
new MAC → eth1

Если MAC начинает постоянно перемещаться между портами, можно получить MAC flapping - и тогда проблема уже не в IP-маршрутизации. Linux bridge в таком режиме фактически выполняет ту же базовую функцию, что и физический L2-коммутатор: строит таблицу MAC → порт на основании уже увиденного трафика. N.A.

Пока все работает, о хорошей инженерной работе обычно не говорят Заметят обычно обратное: когда система легла, когда бизнес встал, когда инфраструктура не выдержала. И вот тогда все резко вспоминают, что где-то есть инженер, от которого это все зависело. Именно поэтому в рамках конференции IT Elements 2026 пройдет первая профессиональная премия «Инженерное искусство». Она посвящена людям, которые каждый день создают, защищают и развивают корпоративное ИТ. Шесть номинаций – и в каждой свой герой: 🔹Архитектор системы 🔹Инженер инноваций 🔹Инженер восстановления 🔹Инженер инфраструктуры 🔹Инженер безопасности 🔹Лидер инженерной команды Если вам есть чем гордиться – или вы знаете проект, который заслужил, чтобы о нем узнали, – расскажите об этом профессиональному сообществу. Заявки принимаются до 31 августа по ссылке.

Пакет можно отбросить до создания skb Обычно сетевой пакет проходит довольно длинный путь внутри Linux:

NIC → driver → skb → network stack → socket → application

Но skb создаётся не в самом начале. XDP может выполнить программу прямо на раннем этапе обработки пакета, когда драйвер уже получил его из NIC, но обычный sk_buff ещё не создан. Поэтому решение можно принять буквально на входе:

NIC
 ↓
driver
 ↓
XDP
 ├── DROP
 ├── PASS → обычный network stack
 ├── TX
 └── REDIRECT

Например, простой XDP-программе достаточно проверить destination IP и сразу отбросить пакет:

SEC("xdp")
int drop_packet(struct xdp_md *ctx)
{
    return XDP_DROP;
}

При XDP_DROP пакет вообще не доходит до обычного kernel networking stack. Это важно под большой нагрузкой: если отбросить ненужный трафик после создания skb, часть работы ядро уже успело выполнить. XDP позволяет перенести фильтрацию значительно раньше. Проверить, загружена ли XDP-программа:

ip -details link show dev eth0

И посмотреть статистику:

ip -s link show dev eth0

Поэтому «firewall на сервере» - не всегда означает, что пакет сначала проходит весь сетевой стек, а потом его фильтруют. В Linux точка принятия решения может находиться практически сразу после получения кадра сетевой картой. N.A.

Почему ss показывает тысячи соединений, а netstat - другую картину На одном сервере можно запустить:

ss -ant

и получить тысячи TCP-соединений, а затем: netstat -ant и увидеть совсем другое количество. Это не обязательно означает, что один из инструментов врёт. ss работает через современный интерфейс ядра Linux - NETLINK_INET_DIAG.

Ядро отдаёт ему информацию о сокетах напрямую, поэтому ss может получать состояние соединений без перебора /proc и без старого механизма netstat.

netstat из пакета net-tools - устаревший инструмент. Его возможности и способ получения данных отличаются, а часть информации может отображаться иначе. Особенно заметна разница на серверах с большим количеством ephemeral connections и быстро меняющимся состоянием TCP. Для диагностики лучше смотреть не просто количество строк:

ss -s

а разбивку состояний:

ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c

Например:

ESTAB      18420
TIME-WAIT   7312
SYN-RECV    428

И отдельно проверить конкретный listener: ss -lntp Важный момент: TIME-WAIT, SYN-RECV, ESTAB и listening sockets - это разные состояния kernel socket state. Поэтому простое сравнение «сколько строк показывает утилита» может давать совершенно разные выводы. ss сегодня является основным инструментом для анализа TCP/UDP-сокетов в Linux, а netstat в новых системах обычно оставляют только ради совместимости со старыми привычками и скриптами. N.A.

Один VLAN может проходить через несколько коммутаторов без единого L3-интерфейса VLAN не привязан к конкретному коммутатору. Если между устройствами настроен trunk, один и тот же broadcast domain может растянуться через несколько физических узлов. Например:

PC ── SW1 ══ SW2 ══ SW3 ── Server
      VLAN 30   VLAN 30   VLAN 30

На trunk-портах кадр VLAN 30 идёт с тегом 802.1Q. Проверка на Linux:

ip -d link show eth0.30

На Cisco:

show interfaces trunk
show vlan id 30

При этом шлюз VLAN может находиться вообще на другом устройстве:

PC → SW1 → SW2 → SW3 → Router
                         VLAN 30

Коммутаторы между ними работают только на L2 и не принимают решение о маршрутизации. Но есть важный нюанс: чем дальше растянут L2-домен, тем больше устройств получают его broadcast и unknown-unicast traffic. Поэтому проблема иногда выглядит как «сеть внезапно стала шумной», хотя IP-маршрутизация при этом вообще не менялась. N.A.

Ping 1 мс не всегда означает, что сеть работает быстро (но почему?) Можно получить RTT в 1–2 мс и при этом иметь очень плохую передачу данных. ping проверяет только время прохождения ICMP-пакета туда и обратно.

Он почти ничего не говорит о том, сколько пакетов реально теряется, насколько забит канал и что происходит с TCP при передаче.

Например, при потере даже небольшого процента TCP-пакетов скорость может резко просесть. Потерянный сегмент приходится передавать заново, а TCP дополнительно уменьшает congestion window. В итоге:

RTT = 2 ms
packet loss = 1%

может оказаться намного хуже для TCP, чем:

RTT = 50 ms
packet loss = 0%

Проверять нужно не только задержку:

ping -c 100 <server-ip>

но и реальные потери при передаче:

iperf3 -c <server-ip> -t 30

А на Linux посмотреть retransmissions:

ss -ti

Если в выводе растёт retrans, проблема уже не в том, что «ping маленький». Низкий RTT показывает, насколько быстро пакет возвращается. Он не показывает, насколько хорошо сеть передаёт поток данных. N.A.

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ Проект «Terminal» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков: • Практические курсы и задания • Книги и статьи известных авторов • Полезные инструменты и ресурсы • IT-новости и инсайды Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, Git, Linux, QA, Java, Vibe-coding, InfoSec и др. ⌨️ подписаться

Почему TCP-порт 443 - это не обязательно один TCP-порт? Когда говорят «сервер слушает 443 порт», легко представить один socket, который принимает все HTTPS-соединения. Но TCP идентифицирует соединение не только по порту назначения. Для него важна комбинация:

src IP + src port + dst IP + dst port

Например, сервер слушает:

10.0.0.10:443

А клиенты создают:

10.0.1.20:49152 → 10.0.0.10:443
10.0.1.21:49153 → 10.0.0.10:443
10.0.1.22:49154 → 10.0.0.10:443

Все три соединения приходят на один :443, но TCP воспринимает их как разные соединения. И именно поэтому веб-сервер может одновременно обслуживать тысячи клиентов через один порт. Но есть ещё интереснее. Один и тот же порт 443 могут одновременно слушать несколько процессов, если используется SO_REUSEPORT. Например:

ss -lntp | grep :443

несколько worker-процессов могут иметь собственные listening sockets на одном IP:443. Ядро само распределяет новые соединения между ними.

При этом уже установленное соединение не прыгает между процессами: выбранный socket становится владельцем конкретного TCP-потока.

Поэтому фраза «порт 443 занят веб-сервером» на практике скрывает сразу несколько уровней: 443 - номер порта IP:443 - endpoint 4-tuple - конкретное TCP-соединение socket - объект, через который процесс работает с этим соединением Именно поэтому один:443 способен обслуживать огромное количество независимых TCP-соединений одновременно. N.A.

📂 Почему Linux иногда отбрасывает корректный пакет из-за rp_filter Ситуация выглядит странно: маршрут до сервера есть, интерфейс поднят, tcpdump показывает входящие пакеты, но соединение не устанавливается. Одна из причин - Reverse Path Filtering. 1️⃣Что происходит Linux получает пакет от 10.20.30.50 на eth1 и проверяет, через какой интерфейс он сам отправил бы трафик обратно к 10.20.30.50. Если маршрут указывает на eth0, а пакет пришёл через eth1, ядро может решить, что источник подозрительный, и отбросить пакет. Проверить настройку:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

2️⃣Почему это часто ломается Особенно заметно при: • нескольких uplink • ECMP • Policy-Based Routing • VRF • асимметричной маршрутизации • балансировщиках и firewall-кластерах Например:

Internet → eth1 → server
server → eth0 → Internet

Маршрутизация работает, но обратный путь отличается от входящего. 3️⃣Как увидеть проблему Сначала смотрим, куда ядро отправит ответ:

ip route get 10.20.30.50

Затем проверяем фактический входящий трафик:

tcpdump -ni eth1 host 10.20.30.50

Если пакет виден на интерфейсе, но приложение его не получает, стоит проверить фильтрацию на уровне ядра. 4️⃣Какие значения бывают

rp_filter=0 — проверка отключена

rp_filter=1 — strict mode, обратный маршрут должен совпадать с входящим интерфейсом

rp_filter=2 — loose mode, достаточно существования маршрута до источника

Для сложной маршрутизации strict mode часто становится источником трудноуловимых проблем. 5️⃣Что важно проверить перед изменением

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

И обязательно смотреть не только all, но и параметры конкретного интерфейса - итоговое поведение зависит от них. N.A.

Default route из нескольких источников На маршрутизаторе одновременно живут default route из BGP, OSPF и static.

Все протоколы говорят, что выход есть, но трафик стабильно уходит через один uplink.

Смотреть только show ip route мало. Сначала интересно понять, что именно BGP считает лучшим кандидатом:

show ip bgp 0.0.0.0

А затем сравнить это с тем, что OSPF держит у себя:

show ip ospf rib 0.0.0.0

Здесь уже может выясниться, что оба протокола имеют рабочий default, но в общую RIB попадает только один. Дальше можно проверить конкретный поток:

show ip cef exact-route <src> <dst>

И увидеть, через какой интерфейс и next-hop он реально будет отправлен. Самый интересный случай - когда выбранный маршрут не устанавливается в FIB из-за проблем с recursive next-hop, и forwarding продолжает использовать другой доступный путь.

show ip cef 0.0.0.0 internal

👀 Получается несколько независимых решений: BGP выбирает свой best path, OSPF - свой, RIB выбирает источник, а FIB в итоге решает, куда уйдёт пакет. Именно на стыке этих уровней и появляются самые неприятные сюрпризы.

📘 DevOps-инженер: от основ до продакшена — новый курс на Mentorix Пишете код, но деплой и прод — чёрный ящик? Курс про инженерию эксплуатации: от первого сервера до автоматизированной CI/CD-инфраструктуры, которая держит нагрузку и не падает. ⚙️ Стек: Docker, Kubernetes, Ansible, Terraform, CI/CD, Prometheus + Grafana, логи ELK 🧩 Задания с автопроверкой + лабы в настоящем терминале 💻 Финальный проект в портфолио 🎓 Сертификат · доступ навсегда 🏷 −35% по промокоду DEVOPS35 — только 48 часов 13 990 ₽ → 9 094 ₽ ➜ Забрать курс со скидкой ━━━━━━━━━━━━━━ 🎁 А ещё на платформе — бесплатные курсы: Языки программирования ⚡ Golang — основы языка 🦀 Rust — основы языка 🐍 Основы Python Инфраструктура и DevOps 🖥 Основы DevOps 🐳 Docker: первые шаги 🔧 Git для начинающих Базы данных • SQL с нуля • MongoDB с нуля 📚 Все бесплатные курсы Mentorix

Cross-zone traffic и неожиданный latency Сервис вроде бы находится в одной VPC, но запросы между двумя компонентами внезапно становятся заметно медленнее. Особенно часто это всплывает после масштабирования: backend поднялся в другой зоне, а клиент продолжил ходить к нему через балансировщик или другой региональный компонент. Посмотреть, куда реально уходит соединение:

ss -tnp

Если адреса backend’ов принадлежат разным зонам, следующий вопрос - действительно ли трафик идёт напрямую между ними.

traceroute -T -p 443 <backend-ip>

Но одного маршрута мало. Интереснее сравнить latency до backend’ов в разных зонах:

mtr -T -P 443 <backend-ip>

Иногда разница небольшая на одном запросе, но начинает сильно влиять на p95/p99, когда сервис делает несколько последовательных обращений к другим компонентам.

Ещё неприятнее, когда frontend находится в одной зоне, application - в другой, а database - снова в первой. Один пользовательский запрос превращается в несколько cross-zone переходов.

⚡️В итоге проблема может выглядеть как “медленный backend”, хотя приложение просто постоянно гоняет данные между зонами. При масштабировании такие вещи легко пропустить, если смотреть только на CPU, RPS и средний latency. N.A.

netdev_budget и обработка большого потока пакетов При большом PPS сервер может начать терять пакеты, хотя канал ещё далеко не забит. Один из интересных параметров здесь - netdev_budget: сколько пакетов kernel может обработать за один проход NAPI. Посмотреть текущее значение:

sysctl net.core.netdev_budget

Если входящий поток постоянно превышает этот лимит, обработка переносится на следующие проходы. В результате растут очереди и latency, а CPU может выглядеть вполне нормально. Посмотреть, есть ли проблема именно на уровне softnet:

cat /proc/net/softnet_stat

Особенно интересны drops и количество обработанных пакетов. Если счётчики начинают быстро расти, проблема уже ближе к обработке пакетов ядром, а не к приложению. Ещё один параметр связан со временем, которое kernel готов потратить на один такой проход:

sysctl net.core.netdev_budget_usecs

И вот здесь начинается интересный баланс: слишком маленький budget может оставить пакеты ждать следующего прохода, а слишком большой - позволить сетевой обработке надолго занять CPU и повлиять на остальные задачи. На загруженном сервере поэтому полезно смотреть не только bandwidth, но и PPS, softirq, softnet drops и NAPI budget. N.A.

Один backend получает почти весь трафик

На графике LB всё выглядит подозрительно: три backend’а работают, healthcheck зелёный, но один получает 80–90% запросов.

Проверять сам алгоритм балансировки недостаточно. В L4 балансировке решение часто принимается для соединения, а не для каждого запроса. Для начала можно посмотреть распределение TCP-сессий на backend’ах:

ss -Htn state established '( sport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

Если перекос уже здесь, проблема появилась до уровня HTTP. Дальше интересно посмотреть, как LB выбирает backend для разных потоков. При ECMP или L4 hashing одинаковые параметры потока могут постоянно попадать в один и тот же bucket.

ipvsadm -Ln --stats

Для IPVS здесь хорошо видны реальные counters по backend’ам, а не только состояние healthcheck. Ещё одна ловушка - connection reuse. Несколько тысяч HTTP-запросов могут ехать внутри небольшого количества долгоживущих TCP-соединений.

ss -Htn state established | awk '{print $4}' | sort | uniq -c | sort -nr | head

Поэтому RPS между backend’ами может отличаться в разы даже при идеально работающем алгоритме распределения соединений. Если используется persistence, sticky sessions или hash по source IP, перекос становится ещё сильнее: несколько крупных клиентов фактически могут “забрать” один backend целиком. И тогда проблема выглядит как сломанный балансировщик, хотя LB честно выполняет выбранную ему стратегию. N.A.

RIB vs FIB: маршрут существует, но пакет идёт иначе Маршрут есть в RIB, но пакет всё равно уходит не туда. Особенно неприятно это становится после изменений BGP, ECMP или policy routing. В Linux полезно сразу смотреть не только таблицу маршрутов, а конкретное решение forwarding для нужного адреса:

ip route get <ip> from <source-ip>

Здесь уже учитываются source address и выбранная таблица маршрутизации. Результат может отличаться от того, что вы видите обычным ip route. Для нескольких routing tables:

ip rule

Потому что маршрут в main может быть абсолютно правильным, но пакет до неё вообще не дойдёт. А дальше начинается интересное: control plane может считать маршрут лучшим, а dataplane уже использовать другую запись. На сетевом оборудовании это удобно проверять отдельно:

show ip route <prefix>
show ip cef <destination>

Первая команда показывает решение routing process, вторая - что реально установлено в forwarding table.

Если между ними есть расхождение, искать проблему уже нужно не в самом маршруте, а в процессе установки маршрутов в FIB, ECMP, next-hop resolution или policy routing.

Именно поэтому “маршрут есть” ещё не означает, что пакет пойдёт по этому маршруту. N.A.

Как поймать внезапный ARP-resolve timeout Когда «всё работает… но периодически что-то замирает», очень часто виноват ARP.

Хост просто не может быстро получить MAC адрес - и весь трафик встаёт на паузу. Особенно больно это бьёт по VoIP, SSH и интерактивным сервисам.

Обычно такие таймауты не видны в обычных логах, поэтому отлавливать их нужно вручную. 1️⃣Проверяем, как часто хост делает ARP-запросы Если сосед «теряется», хост начнёт усиленно спрашивать его MAC. Linux:

tcpdump -ni eth0 arp

Если видишь 2–3 повторяющихся ARP Requests подряд → проблема. Cisco:

debug arp

или

show arp

Если запись в ARP-таблице часто «флапает», это ненормально. 2️⃣Смотрим, что происходит в момент задержки Отслеживаем, пропадают ли ответы:

tcpdump -ni eth0 "arp or icmp"

Если ping висит, а в дампе есть ARP Requests без ARP Reply → таймаут найден. 3️⃣Проверяем ARP-таблицу на переполнения и expiry Если ARP-таблица забилась или записи слишком быстро удаляются → будут постоянные timeouts. Linux:

ip -s neigh

Подозрительные признаки: • состояние FAILED • резкий рост timeouts • записи часто переходят FAILED → REACHABLE → FAILED 4️⃣Проверяем ARP кэш на коммутаторе Иногда виноват L2 — коммутатор забывает MAC или шлёт фреймы не туда. Cisco:

show mac address-table dynamic | include <MAC>

Если MAC постоянно пропадает → проблема на сегменте. N.A.

Разбор странных MTU-проблем через PMTUD

Пинг проходит, TCP-соединение устанавливается, но большие файлы не скачиваются, HTTPS периодически зависает, а часть API-запросов просто уходит в таймаут.

Во многих случаях причина оказывается не в самом MTU, а в том, что Path MTU Discovery (PMTUD) перестал работать где-то по пути. Проверить, какой максимальный размер пакета реально проходит без фрагментации, можно так:

ping -M do -s 1472 <ip>

Если пакет не проходит, постепенно уменьшайте размер. Это позволяет быстро найти реальный MTU на маршруте. Полезно посмотреть и сам маршрут пакетов.

tracepath <ip>

В отличие от обычного traceroute, tracepath умеет определять PMTU и показывает, где он изменился. Если используется TCP, можно проверить MSS, который стороны согласовали при установке соединения.

tcpdump -i <iface> 'tcp[tcpflags] & tcp-syn != 0'

Иногда именно здесь видно, что MSS неожиданно уменьшился или вообще не соответствует ожидаемому MTU. Ещё один частый сценарий - ICMP Fragmentation Needed где-то фильтруется firewall’ом. В итоге PMTUD перестаёт работать, а соединение начинает “зависать” только на больших пакетах. 🔥Поэтому симптомы могут быть очень разными: открывается главная страница сайта, но не загружаются изображения, работает SSH, но зависает SCP, API отвечает на маленькие запросы и молчит на больших. Когда проблема проявляется настолько выборочно, проверка PMTUD обычно экономит часы поиска “неисправной сети”. N.A.

Firewall rule ordering: почему одно правило ломает всё ниже Добавили всего одно правило в firewall - и часть сервисов перестала работать.

При этом сами правила выглядят правильными, а нужные allow вообще присутствуют в конфигурации.

Во многих firewall обработка идёт сверху вниз, и первое совпавшее правило завершает проверку. Всё, что находится ниже, уже не участвует.

iptables -L INPUT --line-numbers -n -v

Сразу видно порядок правил и счётчики срабатываний. Нередко оказывается, что трафик вообще не доходит до нужного ACCEPT. Если используется nftables, полезнее смотреть итоговый ruleset, а не отдельные таблицы.

nft list ruleset

Так проще заметить цепочки, jump’ы и правила, которые перехватывают трафик раньше ожидаемого. Когда причина всё ещё неочевидна, помогает трассировка обработки пакета.

nft monitor trace

Она показывает, через какие цепочки проходит пакет и на каком именно правиле обработка заканчивается. Ещё один полезный приём - посмотреть, какое правило действительно набирает счётчики.

iptables -L -v -n

Иногда именно здесь выясняется, что проблема не в “неправильном” правиле, а в том, что до нужного правила пакет никогда не доходит. В больших конфигурациях порядок правил зачастую важнее их содержания. Одно слишком общее DROP, REJECT или широкое условие в начале цепочки способно незаметно перечеркнуть десятки корректных правил ниже. N.A.

PrivateLink / VPC Peering: скрытые ограничения

Две VPC связаны, маршруты настроены, Security Groups выглядят правильно, но часть сервисов всё равно не может обмениваться трафиком.

Похожая картина возникает, когда путают возможности VPC Peering и PrivateLink - внешне они решают похожую задачу, но работают совершенно по-разному. Если используется Peering, сначала стоит убедиться, что маршрут действительно существует.

ip route

Но даже при корректной маршрутизации может оказаться, что нужная сеть недоступна из-за отсутствия transitive routing. Через Peering нельзя “пройти транзитом” в третью VPC - каждая связь строится напрямую. Если используется PrivateLink, полезно проверить, к какому Endpoint вообще подключён сервис.

aws ec2 describe-vpc-endpoints

Здесь часто выясняется, что доступ есть только к опубликованному сервису, а не ко всей сети. PrivateLink вообще не предназначен для полноценного сетевого взаимодействия между VPC. Ещё один момент - DNS.

dig <service-endpoint>

При отключённом Private DNS часть клиентов продолжает обращаться по публичному имени, даже находясь внутри VPC, и диагностика начинает выглядеть очень запутанной. В итоге обе технологии соединяют VPC, но с разной логикой: VPC Peering даёт сетевую связность между подсетями без транзитной маршрутизации, а PrivateLink публикует конкретный сервис, вообще не открывая доступ к остальной сети. Именно из-за этого ограничения чаще всего всплывают уже в проде, а не на этапе настройки. N.A.