Зачем сетевику может понадобиться язык «C»

августа 26, 2026

Я вот очень люблю IPv6. И в своей инфраструктуре на работе мы его во всю используем. И ещё у нас на работе есть сервера, на которых мы запускаем всякие лабораторные окружения. В общем, развернули, кароче Pnetlab в Ipv6 only среде. Ну развернули и развернули - работает и вроде есть не просит. Запускаю я там всякие frr-ы и прочие Аристы и в ус не дую. Как я обычно с этим работаю? Запустил ноду виртуальную какую-то, у неё есть так называемая primary console - тот тип приложения с помощью которого ты можешь к ней подключится со своего компа Primary console в PNETLab

Ну и при нажатии на объект в web-морде у тебя появляется url типа telnet://Address_of_your_PNETLAB:PORT Ну и соответственно на компе запускается стандартное приложение, которое отвечает за телнет и ломится на ваш IPv6 адрес - дальше магическим образом это всё пробрасывается в серийную консоль эмулируемого устройства. Никогда особо не было с этим проблем, но тут появилась. Я использую стандартный объект VPC - некий контейнер с базовыми сетевыми функциями - IP там назначить, пинг проверить, трассировку. Для его настройки я обычно тоже захожу на адрес pnetlab-а через telnet, там что-то такое вот появляется Порт telnet-консоли VPC

Ну то есть - вот есть порт, и если провалится на этот порт 30102 на адрес pnetlab - то я должен попасть в серийную консоль. Но что-то идёт не так - нажимаю мышкой, ожидаемо запускается putty, но через несколько секунд выдаёт

Ошибка подключения к telnet-консоли VPC

Нажимаю тут же на Аристу, к которой этот VPC подключен, там всё хорошо:

Рабочая telnet-консоль Arista

В общем, пришлось немножк потралшутить :(

Первая мысль - pnetlab где-то проебался и не прикрутил сейриную консоль к VPC. Как проверить? Захожу в pnetlab через HTML5 и пробую чере гвакомоль, там всё хорошо, ожидамый фрейм в вебе появляется

Консоль VPC через Guacamole

Значит сам по себе механизм серийной консоли для VPC работает и проблема ЯВНО СЕТЕВАЯ (кляты сетевики!)

Иду на хост с pnetlab, смотрю дампом по моему порту:

tcpdump -ni any 'tcp port 30102'

И вижу что-то типа

ROMA_IPv6 > PNETLAB_IPv6.30123: Flags [S]
PNETLAB_IPv6.30123 > ROMA_IPv6: Flags [R.]
ROMA_IPv6 > PNETLAB_IPv6.30123: Flags [S]
PNETLAB_IPv6.30123 > ROMA_IPv6: Flags [R.]

Ну то есть я шлю SYN-ы, хост говорит - “Ну не, мне это не интересно, я в этом учавствовать не буду”

На всякий случай, во пример нормального взаимодействия (на телнет порт Аристы - 30118):

ROMA_IPv6 > PNETLAB_IPv6.30118: Flags [S]
PNETLAB_IPv6.30118 > ROMA_IPv6: Flags [S.]
ROMA_IPv6> PNETLAB_IPv6.30118: Flags [.]

Обычный такой ~~милк~~хендшшейк в общем, ну и дальше обмен трафиком as usuall

Теперь надо понять, а чё, точно хост порт 30123 (проблемный) не готов обрабатывать? Чекаем

ss -lntp4 | grep -E '30118|30123'

ss -lntp6 | grep -E '30118|30123'

Для нашей VPC видем что-то такое:

LISTEN ... 0.0.0.0:30123 ... users:(("vpcs",pid=16438,fd=5))

Тогда как для Аристы:

LISTEN ... *:30118 ... users:(("nc"...),("sh"...),("qemu_wrapper_te"...))

Ну то есть получается - что для VPC порт просто напросто не слушается на IPv6 адресе, а слушается только для Ipv4! Опять IPv6 обделили и сокета не создали! А из IPv4 адресов у меня только 127.0.0.1 - и это в целом объясняет то, что гуакамоле коннект устанавливает.

А кто вообще эти сокеты создавать то должен?

Почему одна console слушает [::], а вторая 0.0.0.0? Смотрим процессы. Для VPCS:

ps aux | grep '[v]pcs'

У меня команда примерно такого вида:

/opt/vpcsu/bin/vpcs -m 123 -N vrf-A-PC-1 -i 1 -p 30123 -e -d vunl123_0

То есть console-port 30123 передаётся не какому-то универсальному PNETLab telnet-сервису, а прямо самому VPCS:

-p 30123

И уже процесс vpcs владеет этим socket.

А у QEMU архитектура другая:

/opt/unetlab/wrappers/qemu_wrapper_telnet \
    -P 30118 \
    -t Leaf1 \
    -- nc -U /opt/unetlab/tmp/19/118/console.sock

Получаются совершенно разные схемы. Кему ещё какой-то враппер использует промежуточный. Тут главный итог какой - я думал Pnetlab чудит и косячит с “публикацией” VPC консоли, но нет, ему вообще срать - он просто выбирает какой-то свободный TCP порт и передаёт его в качестве параметра при запуске бинарника VPC - тот уже сам по себе является TCP-сервером для сервиса серийной консоли.

Гоу немножко глубже в траблшут

Ок, на этом шаге понимаем, консоль VPC слушает IPv4:

0.0.0.0:30123   users:(("vpcs",pid=...,fd=...))

Но кто и в какой момент это вообще решает? Лучше чем strace нам на этот вопрос никто не ответит. Ну либо в исходниках копаться, да. Но в кодяре я вообще ничего не шарю. Напомню, что я вообще сетевик и по-хорошему, даже strace запускать не должен. Но… Если совсем коротко, strace позволяет посмотреть системные вызовы, которые пользовательская программа делает в ядро Linux. Программулинка должна попросить батю (ядро) сделать сокет для себя, куда-то его прибиндить и начать слушать входящий трафик. (тут бы код вставить, но я сетевик, ещё раз говорю, и в код не лезу). Именно эти вызовы и хочется увидеть. Запускаем новый экземпляр VPC с strace так:

strace -f -e trace=socket,bind,listen \
  /opt/vpcsu/bin/vpcs -p 39999

-f - просто говорит что нужно ещё и за детишками присматривать, мало ли, может там кто-то шалит

-e trace=socket,bind,listen - некий фильтр того, что нам интересно - очевидно программа в линукс будет делать мильён всякого, но нам интересно только про то, как создаётся сокет, как он биндиться и как предполагается его использование вообще.

В выводе я ожидаю увидеть что нибудь типа

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)

Главное тут именно AF_INET - это явно подтвердит, что в коде программы явно зашито отутствие поддержки IPv6, и она запускает именно IPV4 сокет, иначе было бы что-то типа AF_INET6

В общем, запустили, ищем глазками полезное. Находим:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
bind(4, {
    sa_family=AF_INET,
    sin_port=htons(39999),
    sin_addr=inet_addr("0.0.0.0")
}, 16) = 0
listen(4, 5) = 0

То есть буквально socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4 - создай потоковый TCP сокет IPv4! Создало, вернуло файловый описатель (file descriptor) = 4, далее биндим его к нашему порту и вешаем на ALL-IPv4-Addreses слушать входяшщий трафик.

Я сетевик и не хочу лезть в код! Повторяю третий раз!

Ну ок, кажется нужно просто это принять - VPC реально не умеет нативно делать IPv6 сокеты. Ну подождём ещё лет 10 когда поддержку IPv6 довезут, делов-то. Но что делать сейчас? Напомню, что у нас есть некий враппер, который запускается для QEMU-машинок и заставляет их “перенаправлять” подключения в другие сокеты, то есть для Аристы это было так:

/opt/unetlab/wrappers/qemu_wrapper_telnet \
    -P 30118 \
    -t Leaf1 \
    -- nc -U /opt/unetlab/tmp/19/118/console.sock

Читаем как - хочешь пообщаться со мной по порту 30118? Общайся вон с сокетом в /opt/unetlab/tmp/19/118/console.sock . Порой это сложно осознать, но сокет - это файл, да.

В общем, если у нас VPC запустилась и “слушает”, например порт 30123, то можно рядом враппер запустить, вот так например:

/opt/unetlab/wrappers/qemu_wrapper_telnet \
    -P 39999 \
    -t "VPCS-test" \
    -- nc 127.0.0.1 30123

IPv6 сокет создаётся и даже готов принимать подключения:

ss -lntp6 | grep 39999
*:39999

Если теперь протелнетить порт 39999 по IPv6 адресу Pnetlab-а - то я ожидаем попадал в консоль VPC по IPv6 адресу. Бинго!

Бинго, да не бинго! Есть ряд проблем:

Надо модифицировать запуск VPC из пнетлаба - что бы он ещё подтягивал запуск враппера
Я не могу запустить враппер слушать тот же порт, на котором у меня висит консоль уже - сокет то уже занят!
1. 2.1. То есть надо какую-то дополнительную логику придумать - выбор НОВОГО свободного порта и маппинг его на существущий, где-то какую-то табличку хранить с маппингом
2. 2.2. Донести это как-то в web - что бы сообщать юзеру правильный, отвраппированный порт
3. 2.3. Как-то мусор за собой чистить потом ещё

Сложна, сложна, ничего не понятно

Лезу в код, короч :(

В общем, тут я сдался и решил что надо просто найти в исходнике VPC что-то типа socket(AF_INET, ...) и заменить на socket(AF_INET6, ...), хехе PNETLab запускает бинарник - /opt/vpcsu/bin/vpcs , посему просто спрашиваем его версию /opt/vpcsu/bin/vpcs -v . В ответ получаем:

Welcome to Virtual PC Simulator, version 1.3 (0.8.1)
Build time: May 7 2022 ...
...
Modified version for EVE-NG.

Вот здесь сразу появляется важная информация. Во-первых, в основе установленного бинарника лежит VPCS 0.8.1. Во-вторых:

Modified version for EVE-NG - бубубу, что ж они там модифицировали, мы конечно не узнаем. Ну лан, хер с ним. Исходники этого всего лежат тут - https://github.com/GNS3/vpcs

Немного системно-контрольно-версионной магии:

cd /root
git clone --branch v0.8.1 --depth 1 https://github.com/GNS3/vpcs.git /root/vpcs-ipv6
cd /root/vpcs-ipv6
git checkout v0.8.1

Так, у нас есть исходники, которые мы оптимистично будем считать базой для IPv6-ready модификации.

А вот что делать дальше не понятно - когда не понятно надо спросить у кого-то. Так как у меня нет друзей (лох, пидр) которые шарят - пора спрашивать у LLM :). В общем, искали мы вместе, где же может хранится кодяра, которая сокеты создаёт по ключевым словам из strace - AF_INET, SOCK_STREAM и IPPROTO_TCP Поиск привёл нас в src/daemon.c:

/* daemon socket */
sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (sock < 0) {
    perror("Daemon socket");
    goto err;
}

(void) setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
    (char *)&on, sizeof(on));

bzero((char *) &serv, sizeof(serv));
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
serv.sin_port = htons(port);

if (bind(sock, (struct sockaddr *) &serv, sizeof(serv)) < 0) {
    ...
}

listen(sock, 5);

Вот же оно! Создание сокета:

sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

и какой-то мутный бинд:

bind(sock, (struct sockaddr *) &serv, sizeof(serv))

А потом слушаем:

listen(sock, 5);

Всё один в один (ну почти) как было в выводе strace:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
bind(4, {
    sa_family=AF_INET,
    sin_port=htons(39999),
    sin_addr=inet_addr("0.0.0.0")
}, 16) = 0
listen(4, 5) = 0

Сам кусок, кода, который начинается с /* daemon socket */ - это часть функции daemonize() внутри модуля daemon.c В качестве одного из аргументов функция получает номер порта. Функция daemonize() бызывается из main()-а основного модуля запуска VPC - vpcs.c и туда передаётся номер порта, который парсится из аргумента, который передаётся бинарнику через параметр -p То есть, запускается vpcs вот так: ./vpcs -p 39999 То, что после -p записывается в переменную daemon_port, которая передаётся аргументом в daemonize()

Разобрались что к чему - кодируем!

Для начала мы заменяем тип данных для переменной serv со структуры sockaddr_in на структуру sockaddr_in6 - нам же Ipv6 адрес нужен!

то есть меняем:

struct sockaddr_in serv;

на:

struct sockaddr_in6 serv;

чуть выше в коде.

Дальше меняем сам тип создаваемого сокета. Было:

sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

Здесь AF_INET означает IPv4. Меняем на:

sock = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);

Теперь VPCS просит ядро создать уже IPv6 TCP-сокет. Но просто создать IPv6-сокет неинтересно. Важно, чтобы он при этом продолжал принимать и IPv4-подключения. Иначе мы бы просто заменили одну проблему на другую. Для этого добавляем ещё одну переменную:

int v6only = 0;

и после SO_REUSEADDR явно говорим ядру, что сокет не должен быть IPv6-only:

if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
    (char *)&v6only, sizeof(v6only)) < 0) {
    perror("Daemon IPV6_V6ONLY");
    goto err;
}

Cмысл буквально такой - это, конечно, IPv6-сокет, но и про IPv4 забывать не стоит. Дальше надо поправить адрес, который передаётся в bind().

Раньше структура serv заполнялась как IPv4:

bzero((char *) &serv, sizeof(serv));
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
serv.sin_port = htons(port);

INADDR_ANY здесь означает - 0.0.0.0. То есть «слушать на всех IPv4-адресах сервера». Но теперь-то у нас IPv6, поэтому и поля у неё другие! Меняем этот кусок на:

bzero((char *) &serv, sizeof(serv));
serv.sin6_family = AF_INET6;
serv.sin6_addr = in6addr_any;
serv.sin6_port = htons(port);

Здесь in6addr_any - это IPv6-аналог INADDR_ANY, то есть адрес ::

В итоге раньше мы готовили для bind() адрес: 0.0.0.0:<port>, а теперь готовим: [::]:<port>

Такие вот сетевые C-дела, Кариночка.

Всё? Нет, не всё!

Сокет-то мы создали, биндинги сделали, даже повесили что бы слушал трафик входящий. А что дальше-то будет, когда трафик то придёт? Нада ещё accept() для трафика править, значит. А что такое этот наш accept()? Это стандартный системный вызов socket API, который используется сервером для того, чтобы забрать очередное входящее TCP-соединение. То есть, сделали listen() - перевели созданный сокет в состояние “готов принимать соединение”. Работы сделано много, VPCS устал и хочет поспать, но перед тем как идти спать он делает accept() и как бы говорит ядру: «Так, я спать, разбуди как кто придёт по мою душу»

Когда кто-то извне на этот порт стучится, ядро линукса поздоровается с ним (хандшейк тот самый), создаст ещё один socket - на этот раз с полноценным 4-tuple в состоянии ESTABLISHED. Дальше ядро такое “Алло, VPCS, спишь? Лови дескриптор с соединением, я сделаль”. VPCS просыпается (реально же спал) и получает дескриптор на созданный полноценный tcp-сокет - может там читать\писать.

Кароче, этот accept() тоже какую-то переменную использует которая в формате sockaddr_in - тут тоже немножко бы поправить, потому что то что мы правили для создания сокета - это про нас, про сервер, а accept у нас история про клиентский IP - а он тоже же IPv6 будет

Поэтому заменили sockaddr_in на структуру sockaddr_storage. В этот раз использовалась более универсальная sockaddr_storage , потому что здесь мы уже не формируем адрес сами, как в случае с bind(), а отдаём ядру буфер, куда оно запишет адрес подключившегося клиента. sockaddr_storage как раз и нужен как универсальный контейнер, который подходит и для IPv4, и для IPv6.

В общем, основное меняем struct sockaddr_in cli; на struct sockaddr_storage cli;

Собираем и проверяем IPv6-патч

На С я не писал больше 20 лет, поэтому вообще не был уверен, что оно скомпилируется даже. Однако:

cd /root/vpcs-ipv6/src
./mk.sh 64

gcc -O2 -m64  -DLinux -Dx86_64 -DHV -Wall -DTAP -c vpcs.c
gcc -O2 -m64 vpcs.o daemon.o readline.o packets.o utils.o queue.o \
command.o dev.o dhcp.o command6.o packets6.o ip.o tcp.o inet6.o dns.o \
remote.o help.o dump.o relay.o hv.o frag.o frag6.o \
-o vpcs -lpthread -lutil

Появился новый бинарник по адресу /root/vpcs-ipv6/src/vpcs . Ну я боялся его просто так запускать - вдруг мой новый код это завуалированный rm -rf / или три цыфры с карточки кому-то передаст, поэтому я бахнул strace, чтобы наверняка:

strace -f \
  -e trace=socket,setsockopt,bind,listen \
  ./vpcs -p 39999

Ну и норм кароче стало:

socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(4, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(4, {
    sa_family=AF_INET6,
    sin6_port=htons(39999),
    inet_pton(AF_INET6, "::", ...)
}, 28) = 0
listen(4, 5) = 0

ss -lntp6 | grep 39999 показывает нужное LISTEN 0 5 *:39999 *:* users:(("vpcs",pid=...,fd=4)) и даже внешний telnet на ipv6 адрес по порту 39999 возвращал консоль VPC

Последняя засада

Казалось бы, всё уже готово: новый VPCS собирается, слушает одновременно IPv4 и IPv6, telnet работает. Но перед заменой штатного бинарника я решил посмотреть, как именно PNETLab запускает VPCS. И заметил в командной строке вот такой параметр -N vrf-A-PC-1 Например:

/opt/vpcsu/bin/vpcs \
  -m 123 \
  -N vrf-A-PC-1 \
  -i 1 \
  -p 30123 \
  -e \
  -d vunl123_0

При этом в оригинальном upstream VPCS 0.8.1 параметра -N вообще нет. Если запустить наш новый бинарник так же:

./vpcs -N TEST-PC -p 39998

он честно отвечает - “не ебу”,то есть invalid option -- 'N'

То есть просто заменить штатный бинарник пока нельзя - пнетлаб будет запускать его с неизвестным аргументом. Интуитивно я сначала решил, что -N как-то передаёт в VPCS hostname или имя устройства. Он запускает его примерно так -N vrf-A-PC-1, что очень похоже на имя ноды. Проверили - не. Prompt от этого параметра не меняется.

Дальше начался небольшой отдельный квест: пришлось залезть в штатный EVE-NG-бинарник с gdb и “немного” поковырять ассемблер.

Два часа времени с LLM b выяснилось, что всё гораздо прозаичнее: -N используется только для передачи имени в заголовок telnet-сессии. На сам VPCS, его hostname, сеть и работу консоли этот параметр не влияет.

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

- "?c:efhm:p:r:Rs:t:uvFi:d:"
+ "?c:efhm:p:r:Rs:t:N:uvFi:d:"

И обработчкие main()-е:

case 'N':
    /* EVE-NG/PNETLab compatibility:
       terminal window name is ignored by ROMOCHKA*/
    break;

Заменил бинарник и сижу довольный

Пересобрал ещё разок

cd /root/vpcs-ipv6/src
./mk.sh 64

Чекнул с опцией - ./vpcs -N TEST-PC -p 39998 - на опцию не ругается, функционал пашет. Можно подкидывать пнетлабу эту историю

Фиксируем инфу про старый бинарник stat /opt/vpcsu/bin/vpcs:

Access: (0777/-rwxrwxrwx)
Uid:    root
Gid:    unl

Хеши

sha256sum \
  /opt/vpcsu/bin/vpcs \
  /root/vpcs-ipv6/src/vpcs

Делаем резервную копию штатного бинарника:

cp -a \
  /opt/vpcsu/bin/vpcs \
  /opt/vpcsu/bin/vpcs.original-20260826

Проверили:

ls -l /opt/vpcsu/bin/vpcs*
-rwxrwxrwx 1 root unl 221720 ... /opt/vpcsu/bin/vpcs
-rwxrwxrwx 1 root unl 221720 ... /opt/vpcsu/bin/vpcs.original-20260826

После этого уже заменили штатный бинарник нашим.

Ну и всё кароче - теперь можно просто добавлять ручками VPC в вебморде как и раньше, жамкать мышкой по нему - и открывается телнет сессия нормально. Всё просто оказалось.