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

Так, начнем прямо с сетевых карт:

Трудно не заметить, что сетевые карты разные. Разница — в компонентном различии, количестве микросхем, использовании восьмибитного и шестнадцатибитного разъёмов ISA, цвете текстолита (сверху серо-голубой или бирюзовый, а снизу зелёный). А общее у них одно — максимальная скорость 2 Мбит/с.

❯ Настройка сетевой среды под MS-DOS

Для работы сетевой карты нам понадобится осуществить следующие настройки.

У нас есть пакетный драйвер, для MS-DOS.

Он прописывается в autoexec.bat с использованием следующих параметров.

Параметры, указанные в шестнадцатеричной системе счисления (hex), следующие:

• 0x60 — стандартный программный номер прерывания (interrupt), через которое сетевое приложение, например FTP-сервер, общается с сетевым драйвером;

• 0x20 — уникальный идентификатор рабочей станции в сети;

• 0x05 — аппаратное прерывание;

• 0x318 — адрес используемого в системе порта.

Идем дальше. Для осуществления сетевого взаимодействия, нам понадобится вот этот замечательный пакет.

Mtcp не «новодел». Cогласно информации с официального сайта: «mTCP is a hobby project that I started in 2005». Так что в этом вполне аутентично.

Mtcp настраивается достаточно просто.

В autoexec.bat, нужно указать переменную MTCP:

SET MTCPCFG=c:\mtcp\MTCP.CFG

В конфигурационном файле MTCP.CFG указать параметры, относящиеся к статическому IP-адресу. Почему «статика»? Потому что для MS-DOS отсутствует DHCP-сервер. Есть, конечно, «Microsoft LAN Manager», но пакет тяжеловат, да и оперативную память отъедает прилично. А других вариантов использовать динамическую адресацию я не встречал. Речь идёт о двух машинах без шлюза к маршрутизатору.

Сетевую среду под MS-DOS мы настроили — посмотрим физические соединения.

❯ Физическая среда

Выдержка из документации к сетевой плате ИОЛА:

Для топологии «звезда» используется коаксиальный кабель с волновым сопротивлением 75 Ом (РК-75-2, РК-75-4). Для соединения на длинные расстояния > 800 м. могут использоваться более толстые кабеля: РК-75-7, РК-75-9 и т.д. Так же расстояние зависит от качества кабеля, так для кабеля РК-75-4-113 расстояние увеличивается до 1000 м.

Наш кабель выглядит так:

Кабель с одним и тем же волновым сопротивлением может иметь разный диаметр. Чем больше диаметр кабеля — тем на более далёкие расстояния возможна связь. Полезно.

В сети не должно быть кабелей, второй конец которых ни к чему не подсоединён («висячий конец»). Не допускается образования петель в сети. Хм, ввиду того, что подопытные компьютеры расположены вплотную, им не помешало то, что кабель был свернут кольцом. С другой стороны, не повлияло ли это на скорость передачи? А от «висячего конца» мы спасёмся терминатором на 75 Ом.

В собранном виде BNC-коннектор выглядит так:

В документации есть упоминание о бездисковой загрузке:

Сама плата выглядит так:

Я не знаю, какая микропрограмма зашита в ROM, установленную на эту платку. Если бы эта ПЗУ была установлена в «кроватку» — считал бы программатором, а выпаивать ещё не решился. Что должно быть со стороны, осуществляющей бездисковую загрузку, — в документации не сказано. Сталкивались с таким?

❯ Настройка сетевой среды под W2K Server

А теперь Windows 2000 Server? Не проблема, есть драйвера и для неё.

Ставим драйвер:

Проверяем аппаратное прерывание, конфликтов нет:

Устанавливаем статический IP-адрес:

Копируем DOOM для проверки сети. Почему DOOM, а не Pacman? Да просто он несколько «тяжелее весит» — и мне хотелось посмотреть, не будет ли ошибок при протяжённом копировании. Как увидите на ролике внизу — сетевая передача была осуществлена успешно.

Видим присвоенный DHCP-сервером IP-адрес клиентской машины 10.0.0.2:

Все настроено и готово.

❯ Теперь в игры

Сложность была вот в чём. Скажите, много ли Вы знаете сетевых игр для чистого MS-DOS? Навскидку, кроме DOOM-like, Command & Conquer: Red Alert, Warcraft II: Tides of Darkness, Dune 2000, Quake — ничего не вспоминается. А теперь немного усложним: наша сеть не использует IPX/SPX, а только TCP/IP? Теперь и вообще практически ничего — поиском требуемого я не нашёл. На помощь мне пришла драгоценная находка, в виде этого ресурса.

Здесь есть то, что нам нужно: игра Pacman с поддержкой TCP/IP. Целевых операционных систем здесь много, и самое главное — есть MS-DOS. Нижепродемонстрированный Pacman работает даже на IBM PC XT с процессором Intel 8088. Можно сказать — на минимальной конфигурации.

Игра, согласно документации, запускается просто. Выдержка из README:

Примеры запуска в ОС DOS:

pacman.exe — одиночная игра или 2 игроками на одной клавиатуре. Управление стрелочками — игра за Pac-Man (1-й игрок), управление WASD — игра за Pac-Girl (2-й игрок).

pacman.exe 7777 — запуск сервера, ожидающего подключения 2-го игрока на 7777-й порт (порт можно указывать любой незанятый). Управление стрелочками — игра за Pac-Man (1-й игрок).

pacman.exe 192.168.1.101 7777 — запуск клиента, подключающегося к запущенному серверу на хосте 192.168.1.101 и 7777-му порту. Управление стрелочками — игра за Pac-Girl (2-й игрок).

Создаём серверную часть: pacman.exe 7777
и присоединяемся клиентом: pacman.exe 10.0.0.1 7777

Пояснение к видео. На самом сервере Pacman запустился с артефактами экрана и не отображался ни в окне, ни в полноэкранном режиме. Вероятно, проблема с моей видеокартой. Решив, что это не принципиально, я демонстрирую сетевую игру на одном экране. Управляю обоими Пакманами с клавиатур двух компьютеров, соединённых в сеть. Результат мы видим на одном экране справа. Главное, что Пакманы перемещаются, а это значит — сеть работает.

Результат:

❯ FTP-сервер для MS-DOS

Взглянем, как работает FTP-сервер, запущенный под MS-DOS. Настройка FTP-сервера в пакете MTCP сводится к редактированию файла ftppass.txt, а конкретнее — к заданию имени пользователя, разрешённого «залогиниться», и указанию его пароля. Далее, запустив сам сервер командой FTPSrv, видим следующую картинку.

Что же мы видим? FtpSrv запущен на IP-адресе 10.0.0.1 и слушает стандартный порт 21. Также мы видим, что удалённый пользователь с именем «root» подключился с IP-адреса 10.0.0.2.

FTP-сервер мы запускали, чтобы копировать игры по сети, ну и проверить её работоспособность. Не бегать же с дискетками... Что копируем мы? DOOM, разумеется.

Если не лень, прошу взглянуть на видео — можно перематывать, я записал в реальном времени. Для полноты эксперимента запустил одиночную игру как демонстрацию того, что дистрибутив передался успешно. На процессорах 80386 эта игра — как слайд-шоу, но нужно было убедиться в работоспособности.

❯ Заключение

Для меня остались два открытых вопроса.

Первый.

Удалённая загрузка по сети. В документации указана возможность загрузки по сети с использованием BOOT ROM. Вопрос в следующем: как должен быть настроен компьютер, обеспечивающий сетевую загрузку? Какие файлы операционной системы, где и на чём расположены — и передаются ли они на бездисковую загружающуюся станцию?

Второй.

В использованном ресурсе есть упоминание про драйвера для Linux, только ссылки все «битые». Если есть у кого упомянутые драйвера, прошу поделиться.

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

Благодарю за уделенное время :)

Утром:

$ uptime
08:03:17 up 2:03, load average: 0.00, 0.00, 0.00
$ free -h
total used free
Мозг 2.5P 80T 2.4P
$ systemctl status настроение.service
● настроение.service - Нормальное человеческое настроение
Active: active (running)
$ journalctl -b -p err
-- No entries --
$ echo $?
0

И главное:

sudo apt purge работа_после_18_00
E: Unable to remove 'работа_после_18_00':
package is required by 'ипотека', 'еда' and 'желание_не_жить_под_мостом'

Я на это наткнулся ровно так, как обычно натыкаются на подобное — не потому что курил мануалы, а потому что два часа дебажил то, что по всем признакам не должно было ломаться. И только на дне этого дебага понял: я вообще не знаю, что происходит между вызовом getaddrinfo() и ответом. Никто, по сути, толком не знает. Все просто верят, что DNS резолвит имена и живут с этим счастливым заблуждением, пока оно их не настигает.

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

DNS — это не резолвинг. DNS — это один из вариантов

Вот с чего стоит начать разгребать: getaddrinfo() — это не функция “спроси DNS”. Это функция “спроси NSS”, а NSS (Name Service Switch) — это диспетчер, который решает, у кого спрашивать: у файла, у mDNS, у DNS, у LDAP, у самого черта, что тебе кто-то подсунул модулем. DNS там просто один из кандидатов, причем необязательно приоритетный.

Вся эта логика описана в одном скромном файле, который почти никто не читает после того, как система его замутила при установке:

$ cat /etc/nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] dns

Вроде все просто, сначала спроси /etc/hosts, потом mDNS, потом DNS. Ну да, пока не обращаешь внимание на [NOTFOUND=return] (кому ведь интересно че там в скобках пишут?) — а ведь это уже маленькая бомбочка, о которой мы поговорим отдельно.

Первый источник вранья: /etc/hosts

Самый банальный и самый частый в реальности. Кто-то полгода назад добавил staging.internal в /etc/hosts, чтобы обойти DNS во время какого-то расследования, и забыл убрать. И из-за этого Пинкертона теперь этот хост “резолвится” на машине навсегда независимо от того, что говорит настоящий DNS, независимо от того, что там сейчас в зоне, независимо от того, помнит ли об этом кто-то живой.

files стоит первым в цепочке почти на любом дистрибутиве по умолчанию. И это значит: если имя есть в /etc/hosts — DNS вообще не спросят. Не DNS ответит неправильно, а DNS не спросят вовсе. Для человека, который смотрит на dig и видит правильный ответ, это выглядит как необъяснимая магия. Ведь как это может резолвиться в другое, если DNS говорит правильно? А очень просто — потому что digделает прямой DNS-запрос, а твой процесс до DNS в принципе не доходит.

Ловушка [NOTFOUND=return]

Вот эта конструкция в nsswitch.conf заслуживает отдельного разговора, потому что она реально может испортить тебе в лучшем случае вечер. [NOTFOUND=return] значит: если предыдущий источник явно ответил “такого имени нет” — остановить цепочку прямо здесь и вернуть “ниче не нашел”, не пытаясь спросить следующего.

Казалось бы, разумная оптимизация — mDNS не должен ходить в DNS за именами .local, которых там заведомо не будет. Но на практике это означает, что если что-то в цепочке до DNS решило, что имени не существует, DNS никогда не получит шанс сказать свое слово. Ты можешь идеально настроить зону, ты можешь трижды проверить записи и все равно получить NXDOMAIN на уровне приложения, потому что где-то раньше в цепочке был молчаливый шлагбаум.

Самое неприятное здесь — это происходит тихо. Просто отрицательный ответ, который выглядит абсолютно легитимно.

mDNS и иллюзия .local

Второй пункт в нашей цепочке — mDNS, тот самый multicast DNS, который отвечает за .local-имена в локальной сети. Штука сама по себе рабочая и полезная (Avahi, Bonjour и вот это все), но она добавляет еще один недетерминированный слой: ответ зависит от того, что прямо сейчас есть в сегменте сети, кто отозвался на multicast-запрос за отведенные ей несколько сотен миллисекунд, и повезло ли пакету дойти.

Тут вранья как такового меньше, но неопределенности — выше крыши. Один и тот же .local-хост может резолвиться по-разному в зависимости от того, кто именно ответил первым и насколько загружена сеть в этот момент.

systemd-resolved и обман через 127.0.0.53

А вот это, пожалуй, самый недооцененный источник путаницы на современных дистрибутивах. Открываешь /etc/resolv.conf, видишь:

nameserver 127.0.0.53

и на автомате читаешь это как “вот мой DNS-сервер”. Нет. Это заглушка, локальный прокси systemd-resolved. Реальные нейм-серверы, которые он спрашивает от твоего имени, спрятаны у него внутри в per-link конфиге, до которого обычный resolv.conf не дотягивается вообще. Чтобы узнать кто там реально отвечает за резолвинг, нужно спрашивать не файл, а сам systemd-resolved через D-Bus (org.freedesktop.resolve1.Manager).

Почему это важно? Потому что если ты хочешь сделать независимую проверку и наивно шлешь запрос на 127.0.0.53, ты снова спрашиваешь ту же самую цепочку, только другим путем. Ты сверяешься сам с собой. Ложное чувство независимой проверки, эдакая форма вранья, просто вежливая.

И вот тут есть нюанс, который удивляет: у systemd-resolved DNS-серверы не одни на всю систему, а per-link — свои на каждый сетевой интерфейс. Поднял VPN (тот же Tailscale) — получил отдельный резолвер для его зоны, который живет только на этом линке и в глобальный список серверов не попадает. Если имя относится к такой зоне, а ты сверяешься с глобальными ней серверами — ты гарантированно получишь расхождение, хотя формально все настроено правильно, просто ты спросил не того прохожего.

И тут всплывает со дна еще один источник лжи: gai.conf и сортировка.

DNS в ответе на запрос имени может вернуть сразу оба семейства адресов — и A-записи (IPv4), и AAAA-записи (IPv6). getaddrinfo() получает этот список и не отдает его как есть, а пересортировывает его по правилам RFC 6724, а конкретные веса этих правил живут в /etc/gai.conf. По умолчанию файл почти всегда пустой или отсутствует, что означает “используй дефолты RFC 6724 как есть”, и дефолты там говорят: предпочитай IPv6, если он вообще есть в ответе. Не если он работает. Просто если есть.

И вот тут расходится теория с продакшеном: IPv6 у хоста может быть объявлен в DNS, но реально не маршрутизируется, задроплен на файрволе или тупо висит на мертвом линке. getaddrinfo() про это ничего не знает — он смотрит только на RFC-таблицу приоритетов, а не на реальную доступность адреса. В итоге приложение честно берет “предпочтительный” IPv6-адрес первым, пытается на него достучаться, получает таймаут и только потом падает на IPv4-фолбэк — если он вообще предусмотрен. А dig тем временем как ни в чём не бывало показывает тебе чистый и рабочий IPv4-адрес, потому что dig никого не сортирует и никаких приоритетов не расставляет — он просто печатает, что вернул сервер.

Самое обидное, что это не баг ни у кого. Ни у DNS, ни у приложения, ни у ядра. Это ровно то поведение, которое RFC и просил реализовать. Просто оно молчаливо предполагает мир, где если IPv6-адрес объявлен, то он работает. В 2026 году это предположение все еще сильно оптимистичнее, чем хотелось бы.

Ловушка, о которой почти никто не думает: статический Go-бинарник

И последняя, моя любимая, потому что она рвет шаблон у всех, кто искренне верит, что везде же NSS одна и та же.

Тут стоит сразу закрыть придирку, которая иначе прилетит в комментарии: Go в принципе умеет резолвить и через NSS, если собран с cgo и он доступен на платформе. Но статически слинкованный бинарь — а это ровно то, что обычно льют в прод (CGO_ENABLED=0, никакой libc-зависимости, один файл, копипаст на сервер) этой возможности лишен по построению. Со стандартной статической сборкой Go использует свой собственный, чистый резолвер, написанный на Go, который парсит resolv.conf сам и ходит в DNS сам, минуя NSS, glibc и все, о чем мы говорили выше, целиком.

Это значит следующее: ты можешь идеально настроить nsswitch.conf, добавить нужную запись в /etc/hosts, все перепроверить через getent, но твой Go-сервис все равно этого не увидит, потому что он вообще не спрашивает те источники, которые ты только что поправил. Он живет в своей отдельной реальности резолвинга, которая пересекается с системной только в одной точке — в resolv.conf, да и то не полностью.

Как я до этого докопался

Я это все, честно говоря, не вычитал заранее — я это выковырял руками, комбинацией dig, getent hosts, resolvectl status с легкой злостью. У каждой команды свой кусок правды, ни одна не показывает полную картину, и собрать их вместе в голове каждый раз совсем не кайф, особенно когда уже третий час ищешь глазами несуществующую опечатку. А пресловутый ИИ путается, несет пургу и лишь добавляет сомнений в адекватности происходящего.

В какой-то момент стало проще написать тулзу, которая проходит эту цепочку сама именно так, как ее проходил бы резолвер ОС и параллельно делает независимый DNS-запрос, чтобы явно показать: вот путь, вот его результат, а вот что говорит DNS напрямую, если их спросить в обход всего. Если расходится — вот тебе конкретная причина, а не “попробуй еще раз с флагом -v”.

Так появился gai — от getaddrinfo, а не то, что вы подумали.

$ gai doctor testhost.local

[gai] Simulating name resolution for "testhost.local"... (reality check via 212.227.123.16, 212.227.123.17, systemd-resolved stub: true) RESOLUTION PATH (simulated): 1. Files FOUND 10.0.0.1 DIAGNOSIS:

┌─ ISSUE ──────────────────────────────────────────────────────────────────┐ │ The OS chain and a direct DNS query disagree: 10.0.0.1 vs (none). │ │ Something earlier in the chain (files/mdns) is answering instead of DNS. │ └──────────────────────────────────────────────────────────────────────────┘

Никакого перехвата процессов, никакого LD_PRELOAD, никакого eBPF или ptrace — gai просто читает ту же конфигурацию, что читает сам резолвер ОС (nsswitch.conf, resolv.conf, gai.conf, /etc/hosts, D-Bus-состояние systemd-resolved, одноразовый mDNS-запрос), и честно моделирует путь, которым прошел бы NSS-диспетчер glibc. Отдельно он умеет заметить статический Go-бинарник и прямо сказать, что для этого процесса вся симуляция выше не имеет значения, у него свой резолвер.

Как поставить тулзу и что дальше

Ставится одной строкой, без Rust-тулчейна, без зависимостей вообще — статический бинарник, который просто лежит и работает.

Пойдет в /usr/local/bin/gai с обычными правами 0755 — как любой другой системный бинарник, ничего экзотического. Если хочется собрать самому — cargo install gai-inspector или cargo build --release из исходников, все через crates.io. Никакого рантайма с собой не тащит, ни Python, ни JVM, ни shared-либ, за которые надо переживать при переносе на голый сервер. Скачал, chmod не нужен даже, и можно спрашивать gai doctor <имя> хоть в контейнере, хоть на минимальном Alpine-образе.

Инструмент пока Linux-only и MVP:

• Split-DNS/per-link-роутинг (VPN-зоны вроде Tailscale, о которых я говорил выше) он пока не умеет и честно репортит NOT FOUND вместо того чтобы соврать, но и не резолвит.

• IPv6 mDNS — в процессе.

Репо: github.com/casablanque-code/gai. Там подробнее про возможности и флаги.

Если случится ситуация, где gai тоже наврал — тем более буду рад услышать. Код открыт, пулл реквесты принимаются. Интереснее разобрать баг, чем сделать вид, что такого не бывает.