Эмуляция сети

[Error404]

Насколько я понял, ndisprot позволяет отправлять и принимать данные непосредственно через имеющуюся сетевую карту (правда, не совсем понятно, как будет обрабатываться входящий траффик по IP - будет он передан только обработчику протокола IP или же обеим обработчикам, и можно ли установить два обработчика протокола IP). Правда, в таком случае у нас не получится соедениться с программами, работающими на том-же компьютере, что и эмулятор. Можно, конечно, установить loopback-адаптер, но будет ли это работать, сказать сложно.

TAP-драйвер, наоборот, выступает в роли сетевой карты, и будучи привязанным к протоколам TCP/IP, позволяет принимать и отправлять данные через сетевой стек на том-же компьютере. А чтобы отправлять через сетевую карту, нужно настроить роутинг во внешнюю сеть, точно также, как между двумя реальными сетевыми картами.

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

Я, правда, не совсем понимаю, как это сделано в VMware - там гостевая ОС может работать и с хостом, и с другими компьютерами в сети.

Я себе представлял так:

[Эмулятор->NDIS]->[[TAP1<-бридж->TAP2]->router->realEth]->внешняя сетка

Здесь адаптеры TAP1, TAP1 и виртуальный свитч (бридж) образуют IP-подсеть 1. Наш PC работает роутером из подсети 1 в подсеть 2 куда входит реальный адаптер realEth. Соответственно:
- на адаптере TAP1 кодом Z80 эмулятора через NDIS устанавливается МАС и настраивается IP из сетки1.
- На адаптере realEth средствами Винды настраивается IP из сетки2
- на адаптере TAP2 средствами Винды настраивается IP из сетки1 (типовой случай с РС-роутером, который смотрит двумя адаптерами - TAP2 и realEth - в две сетки)

Как я понимаю, TAP-адаптеры никак не привязаны к IP (LAYER3), они эмулируют на уровне MAC (LAYER2). Хочешь, можно вообще на них IP не поднимать, а поднять что-то другое. Соответственно, в адаптер TAP1 мы можем из эмулятора через NDIS дуть голыми пакетами, которые полностью программно формируются стеком IP, реализованным на Z80 (т.е. они не голые на самом деле, а содержат все нужные структуры для IP). И нормально получать ответы в виде голых же пакетов LAYER2 (это нам обеспечит виртуальный свитч - ему достаточно знать МАС-и TAP1 и TAP2 чтобы понимать что от кого и кому слать).

Сейчас ковыряю, наделал ТАР-ов, пока не понятно что к чему. При создании бриджа ТАР-ы (до того отдельные девайсы со своими MAC) перестают енумероваться по-отдельности, вместо них енумеруется только бридж с единственным MAC-ом. Надо подумать отчего так...

[Advertiser]

[b2m]

Я себе представлял так:

Как-то сложно ты всё представляешь
На мой взгляд есть 2 варианта:
1. эмулятор -> ndisprot.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть
2. программы на локальном PC <- winsock <- tcpip.sys <- NDIS <- tap0801.sys <- эмулятор

В первом случае, для взаимодействия с программами на локальном PC нужен loopback-адаптер.
То есть получится так: эмулятор -> ndisprot.sys -> NDIS -> loopback-адаптер -> NDIS -> tcpip.sys -> winsock -> программы на локальном PC

Во втором случае, для выхода во внешнюю сеть нужен сервис, который будет осуществлять роутинг (на уровне IP) между реальной сетевой картой и tap0801.sys
То есть так: эмулятор -> tap0801.sys -> NDIS -> tcpip.sys -> router service -> tcpip.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть

[Error404]

Как-то сложно ты всё представляешь
На мой взгляд есть 2 варианта:
1. эмулятор -> ndisprot.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть
2. программы на локальном PC <- winsock <- tcpip.sys <- NDIS <- tap0801.sys <- эмулятор

В первом случае, для взаимодействия с программами на локальном PC нужен loopback-адаптер.
То есть получится так: эмулятор -> ndisprot.sys -> NDIS -> loopback-адаптер -> NDIS -> tcpip.sys -> winsock -> программы на локальном PC

Во втором случае, для выхода во внешнюю сеть нужен сервис, который будет осуществлять роутинг (на уровне IP) между реальной сетевой картой и tap0801.sys
То есть так: эмулятор -> tap0801.sys -> NDIS -> tcpip.sys -> router service -> tcpip.sys -> NDIS -> минидрайвер реальной карты -> внешняя сеть

В первом случае на этом физическом адаптере возможна или работа эмулятора, или работа всех прочих IP-программ Винды. Потому что NDIS - это то что "раньше" всего стека IP, доступ к LAYER2 минуя весь стек IP. В параллель два стека (эмуляторский и виндовый) на одном физическом (или виртуальном) приборе канального уровня (MAC) работать не могут.

Второй случай невозможен, потому что через NDIS (не через TAP, TAP это уже ниже NDIS, это сам адаптер, как я понимаю, к которому доступ должен быть через драйвер - NDIS в нашем случае) ты опять же выведешь пакет в канальный уровень. Оттуда этот пакет может быть передан только на другой адаптер. Этот другой адаптер, получив пакет LAYER2, уже "дернет вверх" всю цепочку уровней протокола IP (LAYER3 и выше - TCP/UDP). И вот на этом, другом адаптере уже может жить router, потому что router - это понятие уровня LAYER3.

loopback-интерфейс вообще никогда не пропускает пакеты на уровень LAYER2 (куда мы ходим при помощи NDIS). Пакеты разворачиваются "сами на себя" на уровне LAYER3.

[b2m]

В параллель два стека (эмуляторский и виндовый) на одном физическом (или виртуальном) приборе канального уровня (MAC) работать не могут.

Есть подозрение, что если к сетевой карте привязаны два протокола, то входящие пакеты NDIS будет дублировать для обоих обработчиков протокола. А обработчики должны "отвечать" только на "свои" пакеты.

Второй случай невозможен

Я не понял, так ты разобрался, как работать с TAP-драйвером? Или всё-таки нет?

loopback-интерфейс вообще никогда не пропускает пакеты на уровень LAYER2 (куда мы ходим при помощи NDIS). Пакеты разворачиваются "сами на себя" на уровне LAYER3.

По моему ты путаешь loopback-интерфейс и localhost с адресом 127.0.0.1. Обращения к localhost действительно обрабатываются на уровне tcpip.sys, а loopback-интерфейс выглядит для системы как сетевая карта, которая возвращает все посланные пакеты обратно.

[Error404]

Я не понял, так ты разобрался, как работать с TAP-драйвером? Или всё-таки нет?

Пока нет.
Но других путей не вижу.
Все виртуалки на РС (которые по сути - эмуляторы) работают с сеткой через TAP или его проприетарный аналог.

---------- Post added at 23:29 ---------- Previous post was at 22:11 ----------

Сеть я делать врятли буду, нифига в этом непонимаю.

Дык никто не понимает. Надо разбираться.

---------- Post added 15.02.2011 at 00:46 ---------- Previous post was 14.02.2011 at 23:29 ----------

Некоторые приемы работы с TAP прогуглил. Ничего особенного - открыл, читаешь/пишешь.
http://www.rsdn.ru/forum/network/3842938.flat.aspx
http://www.rsdn.ru/forum/winapi/2724711.aspx

А вообще, все сразу посылают в исходники OpenVPN - дескать "иди и смотри".

А сама концепция пока не ясна. Неясно главным образом почему при объединении в бридж, и реальные адаптеры и TAP-ы перестают энумероваться (например из NDIS по ndisprotQueryBinding, да везде - даже по ipconfig, т.е. по GetAdaptersInfo) .

Ну, тоесть в man-ax на OpenVPN конечно написано, что в Винде после объединения в бридж адаптеры теряют идентичность, и "сущность адаптера" остается только у бриджа, но нафига это так сделано и как это уложить в башке - пока не понятно. Что самое интересное, в Линухе виртуальные адаптеры после объединения в бридж никуда не деваются, как это происходит в Винде.

Поэтому, хотя с бриджем было бы и проще (если бы оно работало как я представляю себе), но схема по прочтении людей по ссылкам похоже вырисовывается такая (несколько отличается от того что я сочинял двумя постами ранее):

эмулятор<-------+------->TAP1<-------+-------->router<-----+--->RealEthAdapter
(IP-subnet1)    |                    |         is our      |      (IP-subnet2)
                |                    |           PC        |
      WinAPI (CreateFile,     Windows IP stack        Windows IP stack
     WriteFile, ReadFile,                                 
       DeviceIoControl)

Как видим, никакого NDIS.
А РС, на котором будет работать эмулятор, сам будет роутить из сети где находится TAP1 в сеть реального адаптера, надо только галку поставить где надо. Или не ставить, если выход во внешнюю сеть не нужен - тогда взаимодействующий IP-софт (telnet, к примеру) просто запускаем на своем же РС - там же где и эмулятор, натравив его на TAP1.
При этом TAP1 не обслуживается двумя стеками. "IP-стек кода на Z80" транслируется на выходе эмулятора в вызовы WinAPI, которые просто являются симметричной ответной частью для IP-стека Винды (имитирую ответные-парные "отправки и прием пакета" в/из эмулятор).

[Error404]

эмулятор<-------+------->TAP1<-------+-------->router<-----+--->RealEthAdapter
(IP-subnet1)    |                    |         is our      |      (IP-subnet2)
                |                    |           PC        |
      WinAPI (CreateFile,     Windows IP stack        Windows IP stack
     WriteFile, ReadFile,                                 
       DeviceIoControl)

Как видим, никакого NDIS.
А РС, на котором будет работать эмулятор, сам будет роутить из сети где находится TAP1 в сеть реального адаптера, надо только галку поставить где надо. Или не ставить, если выход во внешнюю сеть не нужен - тогда взаимодействующий IP-софт (telnet, к примеру) просто запускаем на своем же РС - там же где и эмулятор, натравив его на TAP1.
При этом TAP1 не обслуживается двумя стеками. "IP-стек кода на Z80" транслируется на выходе эмулятора в вызовы WinAPI, которые просто являются симметричной ответной частью для IP-стека Винды (имитирую ответные-парные "отправки и прием пакета" в/из эмулятор).

Правда в последнем варианте канальный уровень "подсети1" и "второй адаптер подсети1" (тот который в эмуляторе) полностью придется обеспечивать эмулятором. Т.е. если в ранней моей схеме в реальный (пускай и TAP) адаптер Винды просто через NDIS передавался пакет (массив) подготовленный Z80-IP-стеком эмулятора, и инкапсуляция этих данных в Ethernet-кадр выполнялась этим адаптером, а передача далее (на второй TAP) производилась бриджем, то в последнем случае и "рисовать исходящий из эмулятора Ethernet-фрейм" и парсить "входящий Ethernet-фрейм" на предмет выделения "на мой MAC пришло или не на мой (да еще в зависимости от promiscuous mode), или это вообще широковещательный пакет" надо будет уже в коде эмулятора.

Все это оттого, что пока никто не сделал под виндой для Ethernet аналог пакета com0com (2 виртуальных адаптера, соединенных кросовером). Если бы это было, можно было бы существенно облегчить себе жизнь. Я думал в этом качестве можно будет использовать схему "TAP-бридж-TAP" (как я это делал бы на реальном оборудовании), но к сожалению бридж в Винде сделан как-то по ублюдочному.

[Error404]

b2m, что скажешь? Реализуемо?