Перенаправление порта на Windows Server 2003 на машину virtualbox [закрыто]
Я хотел бы перенаправить некоторые порты (в частности TCP 22, UDP 1194, TCP 80, TCP 443) с Windows Server 2003 на Linux VM, работающую в VirtualBox на той же машине. Есть ли простой и надежный способ сделать это? В настоящее время ВМ находится в мостовой сети с сервером и должна оставаться доступной извне (LAN) по всем остальным портам.
Сам нашел решение:
Изменил настройки сети на NAT в Virtualbox и используйте встроенную функцию для туннелирования произвольных портов на виртуальную машину. У этого есть недостаток в том, что виртуальная машина может '
На мой взгляд, это не настоящее решение. Вы имели в виду мостовую сеть и то, как это сделать на машине с Windows.
Ваш ответ - не использовать мост на машине с Windows, а использовать NAT.
С моей точки зрения, это как если бы кто-то спрашивал как заменить батареи в Mercedes и ответить: используйте VW.
Итак, чтобы вернуться к виртуальной сетевой машине с мостовой схемой на хосте Windows.
Windows не пересылает пакеты виртуальному адаптеру. Итак, когда ваша машина Windows использует 192.168.1.2, а ваша виртуальная машина подключена к 192.168.1.3 с точки зрения вашего маршрутизатора, где вы пересылаете пакеты либо на 192.168.1.2, либо на 192.168.1.3, все это в конечном итоге приходит на используемую сетевую карту вашими окнами, таким образом, 192.168.1.2.Из-за некоторых протоколов нижнего уровня, используемых ВНУТРИ ЛВС, это не применяется внутри ЛВС! Компьютеры локальной сети, подключенные к 192.168.1.3, будут фактически видны адаптеру виртуальной локальной сети, в то время как перенаправленные пакеты маршрутизатора - нет. Таким образом, переадресация портов на вашем маршрутизаторе на 192.168.1.2 или 192.168.1.3 всегда будет приходить на 192.168.1.2, но внутри локальной сети с некоторыми многоуровневыми пакетами более низкого уровня окна понимают, что это не предназначено для 192.168.1.2, а для 192.168.1.3.
Это ограничение, накладываемое окнами, и то, как пакеты Windows обрабатываются иначе, чем в локальной сети с некоторыми дополнительными данными нижнего уровня к пакетам по сравнению с интернет-пакетами, в которых отсутствует эта информация, окна должны знать, что это не для основной сетевой карты, а предназначено для мостовой virtual.
Блокирование пакетов от прихода в окна или разрешение (брандмауэр) ничего не меняют в этой проблеме! Это просто то, как ОС хоста будет обрабатывать пакеты сначала, прежде чем ваш виртуальный адаптер сможет получить их в свои руки (в этом случае никогда). Это должно быть определено задолго до того, как правила брандмауэра действительно вступят в силу.
Однако есть решение: вы все равно можете связать виртуальную машину с хостом Windows, использовать мостовые сетевые возможности и сетевые протоколы нижнего уровня в своей сети И по-прежнему сообщать окнам, что пакеты на определенных портах предназначены для виртуальной машины, а не с Windows NIC!
Для этого вы можете использовать: netsh interface portproxy add v4tov4 listenport = 80 connectport = 80 connectaddress = 192.168.1.3
Теперь все входящие пакеты на порт 80 на 192.168.1.2 или 192.168.1.3 по-прежнему остаются входящие в вашу ОС хоста (Windows), но окна теперь перенаправляют их на виртуальную машину по адресу 192.168.1.3
. Вот как вы настраиваете мостовую сеть со всеми преимуществами фактического присутствия в локальной сети, к которой подключен хост, И все же получить нужные пакеты, чтобы прибыть на вашу виртуальную машину именно там, где вы хотите, чтобы они прибыли.
Надеюсь, это немного объясняет, как это настроить. Конкретное объяснение того, почему Windows обрабатывает пакеты из пакетов, перенаправленных за пределы маршрутизатора, отличных от пакетов внутри локальной сети, конечно, этим не объясняется, но я думаю, что это не имеет отношения к вашему вопросу. Вы спросили, как это сделать в среде с мостами.
Так что удачи. Вышеупомянутое решение было протестировано и доказало свою работоспособность.