Здравствуйте, уважаемые читатели, прошу не бросать в меня помидорами из-за столь странного использования виртуализации, у меня дома достаточно хорошая беспроводная сеть с пингом менее 1мс и скоростью около 90Мбит, между роутером и компьютером всего одна стена и она без металлической арматуры, а тянуть провод до компа проблематично. Мне понадобилось держать в постоянном доступе на внешнюю сеть сервер на Linux и чтобы он работал в фоне и запускался сам при включении компьютера, т.к. в Windows 10 pro есть hyper-v, то почему бы не использовать его. Но я сильно расстроился, когда виртуальные машины начали периодами терять связь с внешним миром, потери пингов достигали 20-40%.
Виртуальный коммутатор был настроен на внешнюю сеть, т.е. пробрасывал мост в локальную беспроводную сеть. Поработав один день, я обнаружил что часто сайт недоступен извне, а через секунд 30 снова работает, а потом это повторялось. Сперва долго не мог понять в чем дело, доставал ноутбук, начинал пинговать виртуалку, пинги идут и в этот момент уже и сайт открывается, потом запустил пинги из консоли виртуалки, обнаружил обрывы, одновременно запустил пинг из хост-системы, тут всё идеально, 0% потерь.
Дня три я ползал по разным форумам в поисках ответа, но везде люди ссылались на то что хост-система забирает ресурсы у виртуальных машин, что Windows 10 такая кривая и надо ставить серверную систему для таких целей, но причина оказалась не в этом.
Оказывается что при создании моста виртуальные сетевые интерфейсы с разными mac-адресами выходят через мою сетевую карту, в результате одна сетевая карта выходит в сеть с разными mac, если по проводной сети это работает прекрасно, то в беспроводной сети такое поведение вызывает неадекватную работу сети, на некоторых wi-fi картах таких проблем не будет, но на большинстве возникают проблемы.
Чтобы решить проблему со стабильностью соединения виртуальных машин, нужно использовать NAT и пробрасывать порты. В сети гуляет много инструкций как это сделать, но с простым открытием доступа на внешней сетевой карте это решить не получится.
А теперь по порядку, сперва нам нужно создать виртуальный коммутатор с типом «внутренняя сеть», в сетевых соединениях появится виртуальный интерфейс, он будет связующим с виртуальными машинами. У виртуальных машин задаем IP адреса в подсети, отличной от нашей локальной сети. Если в локальной сети у нас подсеть 192.168.0.0/24, то в виртуальной сделаем, например, 192.168.137.0/24, нашей виртуальной машине зададим 192.168.137.100, а виртуальному интерфейсу 192.168.137.1 и это будет шлюзом для наших машин.
А теперь про NAT, обычный способ с общим доступом к интерфейсу будет работать до первой перезагрузки хост-машины, скорей всего виртуальный интерфейс появляется в системе позже, чем реальная сетевая карта с ее общим доступом и NAT просто слетает, а нам нужно чтобы всё работало сразу при включении компьютера. На помощь приходит эта инструкция, открываем консоль PowerShell от имени администратора и вводим там:
Еще раз проверяем, чтобы на виртуальной сетевой карте на хост-системе не сбился ip, теперь о пробросе портов в той же консольке
В результате при обращении к нашему компьютеру по порту 8080 — запрос будет переадресовываться в нашу виртуальную машину с ip 192.168.137.100 на 80й порт.
Дальше можно пробросить 80й порт с роутера на нашу машину на 8080 и виртуальный веб-сервер будет доступен снаружи, аналогично можно сделать с ftp, ssh и другими необходимыми сервисами.
Надеюсь, что кто то другой, столкнувшись с такой проблемой не будет переустанавливать драйвера, переставлять разные галочки в настройках hyper-v и обновлять ядро в Linux, а сразу сделает NAT. Такая настройка не годится для боевых серверов, но для всяких домашних временных серверов вполне пойдет.
Виртуальный коммутатор был настроен на внешнюю сеть, т.е. пробрасывал мост в локальную беспроводную сеть. Поработав один день, я обнаружил что часто сайт недоступен извне, а через секунд 30 снова работает, а потом это повторялось. Сперва долго не мог понять в чем дело, доставал ноутбук, начинал пинговать виртуалку, пинги идут и в этот момент уже и сайт открывается, потом запустил пинги из консоли виртуалки, обнаружил обрывы, одновременно запустил пинг из хост-системы, тут всё идеально, 0% потерь.
Дня три я ползал по разным форумам в поисках ответа, но везде люди ссылались на то что хост-система забирает ресурсы у виртуальных машин, что Windows 10 такая кривая и надо ставить серверную систему для таких целей, но причина оказалась не в этом.
Оказывается что при создании моста виртуальные сетевые интерфейсы с разными mac-адресами выходят через мою сетевую карту, в результате одна сетевая карта выходит в сеть с разными mac, если по проводной сети это работает прекрасно, то в беспроводной сети такое поведение вызывает неадекватную работу сети, на некоторых wi-fi картах таких проблем не будет, но на большинстве возникают проблемы.
Чтобы решить проблему со стабильностью соединения виртуальных машин, нужно использовать NAT и пробрасывать порты. В сети гуляет много инструкций как это сделать, но с простым открытием доступа на внешней сетевой карте это решить не получится.
А теперь по порядку, сперва нам нужно создать виртуальный коммутатор с типом «внутренняя сеть», в сетевых соединениях появится виртуальный интерфейс, он будет связующим с виртуальными машинами. У виртуальных машин задаем IP адреса в подсети, отличной от нашей локальной сети. Если в локальной сети у нас подсеть 192.168.0.0/24, то в виртуальной сделаем, например, 192.168.137.0/24, нашей виртуальной машине зададим 192.168.137.100, а виртуальному интерфейсу 192.168.137.1 и это будет шлюзом для наших машин.
А теперь про NAT, обычный способ с общим доступом к интерфейсу будет работать до первой перезагрузки хост-машины, скорей всего виртуальный интерфейс появляется в системе позже, чем реальная сетевая карта с ее общим доступом и NAT просто слетает, а нам нужно чтобы всё работало сразу при включении компьютера. На помощь приходит эта инструкция, открываем консоль PowerShell от имени администратора и вводим там:
New-NetNat -Name nat1 -InternalIPInterfaceAddressPrefix 192.168.137.0/24Еще раз проверяем, чтобы на виртуальной сетевой карте на хост-системе не сбился ip, теперь о пробросе портов в той же консольке
netsh interface portproxy add v4tov4 listenport=8080 connectaddress=192.168.137.100 connectport=80 protocol=tcpВ результате при обращении к нашему компьютеру по порту 8080 — запрос будет переадресовываться в нашу виртуальную машину с ip 192.168.137.100 на 80й порт.
Дальше можно пробросить 80й порт с роутера на нашу машину на 8080 и виртуальный веб-сервер будет доступен снаружи, аналогично можно сделать с ftp, ssh и другими необходимыми сервисами.
Надеюсь, что кто то другой, столкнувшись с такой проблемой не будет переустанавливать драйвера, переставлять разные галочки в настройках hyper-v и обновлять ядро в Linux, а сразу сделает NAT. Такая настройка не годится для боевых серверов, но для всяких домашних временных серверов вполне пойдет.
Поделиться с друзьями
merlin-vrn
Это не "неадекватная работа сети", а вполне как раз правильная и документированная в стандартах.
В пакетах типа "станция-точка" есть ТРИ поля для MAC-адресов: адрес станции (клиента), адрес точки доступа и адрес какого-нибудь хоста "за точкой". Т.е. на точке бриждевать можно, для этого она и есть, а на станции — нет: некуда в пакет положить адрес хоста, расположенного "за станцией". Если заменить адрес станции (которая в вашем случае — хост) на адрес чего-то там за станцией (которое в данном случае — виртуалка), то точка доступа пакет не примет — у неё нет в табличке ассоциировавшихся клиентов станции с таким адресом.
(Здесь мог бы помочь четырёх-адресный формат пакета, WDS, но он в стандартах не детализован, каждый производитель оборудования реализует по-своему, поэтому, вообще говоря, если у вас в точке доступа broadcom, а на ноуте atheros, работать с четырёхадресным форматом не будет. Ну и на десятке вы это вряд ли заведёте.)
Странно, что на форумах не нашлось ни одного человека, кто вам бы про это рассказал.
Для бриджевания на станции может помочь MAC-NAT (или Layer2 NAT), когда станция уходящие пакеты отправляет со своим MACом, записывая в табличку, а для ответов угадывает, на что это были ответы и делает обратную подстановку — по аналогии с NAT, только на канальном уровне. (В Linux это настраивается через утилиту ebtables.) Если это недоступно, но транслировать IP-адреса не хочется, то можно ещё попробовать proxy-arp — маршрутизация, когда за двумя разными интерфейсами одна и та же подсеть, извне (со стороны точки доступа) это выглядит абсолютно так же, как и MAC-NAT.
Но ни того, ни другого десятка не умеет. Не знаю, умеет ли это серверная винда, возможно, proxy-arp могла бы уметь.
PavelBelyaev
Спасибо за комментарий, я наверно не совсем корректно выразился, просто хотел сказать что при работе по wi-fi возникают проблемы, но вот десктопные продукты эту модель использования предусмотрели и на продуктах типа virtualbox, wmvare player или parallels desktop таких проблем не возникало.
merlin-vrn
Тогда я вас тем более не понимаю. Вы используете явно серверную технологию, и требуете от неё сугубо десктопных фич, и при этом киваете на то, что "вот они поддерживают". Ну и использовали бы virtualbox, wmvare player или parallels desktop, раз в них работает из коробки. Как на рынке: если "там" яблоки дешевле — ну так и иди и купи "там", а "здесь" они вот по этой цене.
Не удивляйтесь, что у вас что-то не получается (и никто не может помочь), когда вы хотите странного.
lovecraft
В том-то и дело, Microsoft самим фактом включения Hyper-V в состав десктопной ОС утверждает, что технология готова для десктопа, а на деле оказывается, что такой use case даже никто не тестировал. А ведь десятку можно поставить и на ноуте, на котором попросту не будет ethernet, только wi-fi, и сеть работать не будет.
zeronice
Если у вас именно сайт — так поставьте на десятку IIS и настройте реверс-прокси во внутреннюю сеть виртуалки. Бридж на клиентском вайфае, как было написано выше, — никто не обещал. Хотите именно так -как задумано — берите адаптер с поддержкой функции точки доступа и стройте мост с вашим роутером.
А вообще по теме первая же ссылка гугла — https://blogs.msdn.microsoft.com/virtual_pc_guy/2015/02/02/hyper-v-and-wireless-networking/
аж почти двухлетней давности.
lovecraft
Статья — огонь. Краткий пересказ: в чисто десктопной ОС не работает нужная пользователю функция. Но мы не будем делать так. чтобы она работала или хотя бы предупреждать пользователя, что она не работает! Вместо этого попробуйте такой костыль <тут описание соединения L2-коммутатора Hyper-V и L2-коммутатора, встроенного в винду, который такой же, как и Hyper-V, только другой>. Заметим, правда, что этот костыль у нас самих не всегда работает — ну, там, адаптер не пашет, DHCP не выдается…
Но вы, уважаемые пользователи десктопных ОС без навыков системного администрирования и желания разбираться в ARP и форматах пакетов — сделайте что нибудь сами, чтобы серверная технология, которую мы впихнули в десктопную ОС, как нибкдь заработала.
zeronice
Извиняйте, перепутал вас с автором. Смысл ссылки был в том, чтобы показать, что проблема освещена и особо сакральных знаний для осознания проблемы не требуется.
А если в целом по теме — решать проблемы доступа к сайту на L2 там, где можно построить маршрут или http-прокси — смахивает на шизофрению.
PavelBelyaev
merlin-vrn, я ничего не требую от hyper-v и даже не возмущаюсь, просто описываю что по wi-fi не совсем работает и что NAT простой галочкой в сетевом интерфейсе (предоставить доступ...) тоже не совсем поднимается ну и привожу две команды, которыми это настраивается (nat + port proxy), думаю что кому-нибудь пригодится в быту.
mayorovp
Можно передать wifi-модуль линуксу монопольно, а хост-систему подключить через внутреннюю сеть. Тогда на линуксе можно уже хоть MAC-NAT, хоть proxy-arp настраивать. Или с wi-fi интерфейсом что-нибудь хитрое придумать.
PS хм, а мы на сетях ЭВМ учили что пакеты wi-fi всегда четырехадресные, про трехадресные первый раз слышу...
zeronice
ЕМНИП, Hyper-V не умеет чистый проброс устройств
mayorovp
Да, точно. Но через внешнюю сеть-то монопольный доступ дать можно, это все еще оставляет возможным MAC-NAT и proxy-arp.