Интерфейс TAP обеспечивает виртуальную связь с двумя сторонами:
/dev/net/tun
), что позволяет этому процессу читать и записывать IP-пакеты (tun режим )или фреймы Ethernet (коснитесь режима ). Эти пакеты либо исходят, либо направляются на интерфейсную сторону хоста. Создание интерфейса — не самая важная часть. Наиболее важной частью является наличие процесса, подключенного к невидимой стороне этого интерфейса для чтения и записи пакетов. Пока нет такого процесса, связи по этому каналу не существует. Это естественно переводится как «НЕТ -CARRIER», потому что это имеет смысл. Это нормальное и ожидаемое поведение.
Три примера таких процессов, которые мне приходят в голову, это QEMU (, который обеспечивает эмуляцию устройства для KVM, включая сетевые интерфейсы ), OpenVPN и опцию туннеля openssh.
Обычно вы позволяете qemu или помощнику qemu или libvirtd создать интерфейс (и присоединить его к мосту. )и передать qemu то, что необходимо для использования соответствующего файлового дескриптора.Затем интерфейс будет правильно обрабатывать эту невидимую другую сторону:qemu и сообщать об обнаружении несущей. Возможно, вы сможете передать созданный вручную интерфейс qemu(или libvirtd и т. д. )самостоятельно, но, поскольку это не обычный метод, вам придется проделать дополнительную работу.