Pull to refresh

Comments 11

Это не "неадекватная работа сети", а вполне как раз правильная и документированная в стандартах.


В пакетах типа "станция-точка" есть ТРИ поля для MAC-адресов: адрес станции (клиента), адрес точки доступа и адрес какого-нибудь хоста "за точкой". Т.е. на точке бриждевать можно, для этого она и есть, а на станции — нет: некуда в пакет положить адрес хоста, расположенного "за станцией". Если заменить адрес станции (которая в вашем случае — хост) на адрес чего-то там за станцией (которое в данном случае — виртуалка), то точка доступа пакет не примет — у неё нет в табличке ассоциировавшихся клиентов станции с таким адресом.


(Здесь мог бы помочь четырёх-адресный формат пакета, WDS, но он в стандартах не детализован, каждый производитель оборудования реализует по-своему, поэтому, вообще говоря, если у вас в точке доступа broadcom, а на ноуте atheros, работать с четырёхадресным форматом не будет. Ну и на десятке вы это вряд ли заведёте.)


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


Для бриджевания на станции может помочь MAC-NAT (или Layer2 NAT), когда станция уходящие пакеты отправляет со своим MACом, записывая в табличку, а для ответов угадывает, на что это были ответы и делает обратную подстановку — по аналогии с NAT, только на канальном уровне. (В Linux это настраивается через утилиту ebtables.) Если это недоступно, но транслировать IP-адреса не хочется, то можно ещё попробовать proxy-arp — маршрутизация, когда за двумя разными интерфейсами одна и та же подсеть, извне (со стороны точки доступа) это выглядит абсолютно так же, как и MAC-NAT.


Но ни того, ни другого десятка не умеет. Не знаю, умеет ли это серверная винда, возможно, proxy-arp могла бы уметь.

Спасибо за комментарий, я наверно не совсем корректно выразился, просто хотел сказать что при работе по wi-fi возникают проблемы, но вот десктопные продукты эту модель использования предусмотрели и на продуктах типа virtualbox, wmvare player или parallels desktop таких проблем не возникало.

Тогда я вас тем более не понимаю. Вы используете явно серверную технологию, и требуете от неё сугубо десктопных фич, и при этом киваете на то, что "вот они поддерживают". Ну и использовали бы virtualbox, wmvare player или parallels desktop, раз в них работает из коробки. Как на рынке: если "там" яблоки дешевле — ну так и иди и купи "там", а "здесь" они вот по этой цене.


Не удивляйтесь, что у вас что-то не получается (и никто не может помочь), когда вы хотите странного.

В том-то и дело, Microsoft самим фактом включения Hyper-V в состав десктопной ОС утверждает, что технология готова для десктопа, а на деле оказывается, что такой use case даже никто не тестировал. А ведь десятку можно поставить и на ноуте, на котором попросту не будет ethernet, только wi-fi, и сеть работать не будет.
Если у вас именно сайт — так поставьте на десятку IIS и настройте реверс-прокси во внутреннюю сеть виртуалки. Бридж на клиентском вайфае, как было написано выше, — никто не обещал. Хотите именно так -как задумано — берите адаптер с поддержкой функции точки доступа и стройте мост с вашим роутером.
А вообще по теме первая же ссылка гугла — https://blogs.msdn.microsoft.com/virtual_pc_guy/2015/02/02/hyper-v-and-wireless-networking/
аж почти двухлетней давности.
Статья — огонь. Краткий пересказ: в чисто десктопной ОС не работает нужная пользователю функция. Но мы не будем делать так. чтобы она работала или хотя бы предупреждать пользователя, что она не работает! Вместо этого попробуйте такой костыль <тут описание соединения L2-коммутатора Hyper-V и L2-коммутатора, встроенного в винду, который такой же, как и Hyper-V, только другой>. Заметим, правда, что этот костыль у нас самих не всегда работает — ну, там, адаптер не пашет, DHCP не выдается…
Но вы, уважаемые пользователи десктопных ОС без навыков системного администрирования и желания разбираться в ARP и форматах пакетов — сделайте что нибудь сами, чтобы серверная технология, которую мы впихнули в десктопную ОС, как нибкдь заработала.
Извиняйте, перепутал вас с автором. Смысл ссылки был в том, чтобы показать, что проблема освещена и особо сакральных знаний для осознания проблемы не требуется.
А если в целом по теме — решать проблемы доступа к сайту на L2 там, где можно построить маршрут или http-прокси — смахивает на шизофрению.
merlin-vrn, я ничего не требую от hyper-v и даже не возмущаюсь, просто описываю что по wi-fi не совсем работает и что NAT простой галочкой в сетевом интерфейсе (предоставить доступ...) тоже не совсем поднимается ну и привожу две команды, которыми это настраивается (nat + port proxy), думаю что кому-нибудь пригодится в быту.

Можно передать wifi-модуль линуксу монопольно, а хост-систему подключить через внутреннюю сеть. Тогда на линуксе можно уже хоть MAC-NAT, хоть proxy-arp настраивать. Или с wi-fi интерфейсом что-нибудь хитрое придумать.


PS хм, а мы на сетях ЭВМ учили что пакеты wi-fi всегда четырехадресные, про трехадресные первый раз слышу...

ЕМНИП, Hyper-V не умеет чистый проброс устройств

Да, точно. Но через внешнюю сеть-то монопольный доступ дать можно, это все еще оставляет возможным MAC-NAT и proxy-arp.

Sign up to leave a comment.

Articles