Здравствуйте, уважаемые читатели, прошу не бросать в меня помидорами из-за столь странного использования виртуализации, у меня дома достаточно хорошая беспроводная сеть с пингом менее 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. Такая настройка не годится для боевых серверов, но для всяких домашних временных серверов вполне пойдет.