02:14 14-12-2009
Доступ с виртуальной машины в сеть через ESET SmartSecurity firewall
Свежеустановленный имидж Debian 5 под coLinux 0.7.5 (забридженный через winpcap к физической сетевой карте) не мог не только выйти в сеть, но даже получить адрес по DHCP. Для проверки отрубил файервол в ESET SmartSecurity - все работает.
Создание правил в конфигурации файервола ситуации не меняет - работающий файервол ESET SS намертво блокирует любой трафик с и к виртуальной машине.
Проблема решается просто, путем включения в конфигурации ESET SS (Personal Firewall -> IDS and advanced options) опции "Allow communication for bridged connections" (которая открывает доступ для забридженной машины) и отключения опции "Covert data in ICMP Protocol detection" (иначе протокол ICMP и в частности ping блокируется файерволом).
Следует заметить, что правила файервола ESET SS не накладываются на трафик от или к забридженной машине, так что виртуальный сервер остается незащищенным, соответственно имеет смысл конфигурировать локальный файервол на виртуальной машине.
Маленькое попутное разочарование, обнаруженное в ходе разруливания проблемы: coLinux пока не работает под виндой x64 на хостовой машине - по причине того, что драйвер надо основательно переписывать под x64, плюс драйвер необходимо сертифицировать у MS. Так что использовать coLinux под x64 можно будет похоже очень не скоро. Подробнее
Практический вывод, что W7 я себе буду ставить x32, тем более что ставить больше установленных сегодня 4 гигов оперативки я в обозримом будущем не планирую, так что и отдачи особой от x64 я не получу.
Создание правил в конфигурации файервола ситуации не меняет - работающий файервол ESET SS намертво блокирует любой трафик с и к виртуальной машине.
Проблема решается просто, путем включения в конфигурации ESET SS (Personal Firewall -> IDS and advanced options) опции "Allow communication for bridged connections" (которая открывает доступ для забридженной машины) и отключения опции "Covert data in ICMP Protocol detection" (иначе протокол ICMP и в частности ping блокируется файерволом).
Следует заметить, что правила файервола ESET SS не накладываются на трафик от или к забридженной машине, так что виртуальный сервер остается незащищенным, соответственно имеет смысл конфигурировать локальный файервол на виртуальной машине.
Маленькое попутное разочарование, обнаруженное в ходе разруливания проблемы: coLinux пока не работает под виндой x64 на хостовой машине - по причине того, что драйвер надо основательно переписывать под x64, плюс драйвер необходимо сертифицировать у MS. Так что использовать coLinux под x64 можно будет похоже очень не скоро. Подробнее
Практический вывод, что W7 я себе буду ставить x32, тем более что ставить больше установленных сегодня 4 гигов оперативки я в обозримом будущем не планирую, так что и отдачи особой от x64 я не получу.
03:30 12-05-2008
Что-то я в ступоре
Запущенный через dynamips роутер должен общаться с реальной сетью. На машине с dynamips установлен winpcap, сама машина подрублена к цисковскому свитчу. Если на свитче порт сконфигурирован в mode access, то все работает нормально - виртуальный роутер пингуется из реальной сети (и в обратную сторону), по CDP виден. Но дело в том, что роутер должен иметь доступ в 2 vlan'а - data vlan и в voice vlan, так как виртуальный роутер должен выполнять функции CallManager Express. То есть между роутером и свитчем должен быть транк.
Если я форсирую транк на стороне свитча, то соединение между свитчем и физической машиной проподает. В принципе логично. Зашел в опции интерфейса физической машины, в настройках драйвера включил поддержку vlan'ов и указал каким id физическая машина должна тагировать свои фреймы. После рестарта интерфейса на свитче, связь между свитчем и физическим сервером появилась и работает. Однако виртуальный роутер недоступен полностью (кроме как через консоль), хотя сконфигурирован он вроде правильно - и суб-интерфейсы, и энкапсуляция dot1q включена...
По какому принципу работает winpcap?
Если я форсирую транк на стороне свитча, то соединение между свитчем и физической машиной проподает. В принципе логично. Зашел в опции интерфейса физической машины, в настройках драйвера включил поддержку vlan'ов и указал каким id физическая машина должна тагировать свои фреймы. После рестарта интерфейса на свитче, связь между свитчем и физическим сервером появилась и работает. Однако виртуальный роутер недоступен полностью (кроме как через консоль), хотя сконфигурирован он вроде правильно - и суб-интерфейсы, и энкапсуляция dot1q включена...
По какому принципу работает winpcap?