Нужен .htaccess и правила отдачи документов сервером, вместе с анализом его логов и приходящих запросов. Скорее всего, есть расхождение в конфигурации между локальным и боевым веб-серверами.
"некоторые роли не могут быть одновременно на двух exchange" - неверно, там "на одном" сервере, а именно, edge transport не может быть на одном сервере с остальными ролями.
"в современном exchange, кластер сам может двигать ящики, догадываясь где ближе" - будет неудобно, для геораспределенных систем гонять ящик взад-вперед очень накладно, долго и требует лишнего места на обеих сторонах. Поэтому никто и не собирался реализовывать такое.
Михаил Гаврилюк, тогда статический прописываете через консоль, в той же подсети, что и ваш ПК. Потом пытаетесть пропинговать ПК с виртуалки, если есть, проверяйте файрволл на ВМ, если нет, то на ПК. Дальше обычная отладка неработающего сетевого подключения - кто дропает пакеты и где.
> Но из сети 172.24.1.0 например пингуется 10.8.2.1, можно к нему подключаться по ssh и тд
Это нормально, на это как раз и нужен исходящий нат, чтобы можно было видеть сеть за пределами локальной сети.
А вот то, что у вас нат на eth+, это и нормально, и на доступ в 10.8 не влияет - она же за tun-интерфейсом. Вот есть ли у вас нат на tun? Если нет, смотрите tcpdump'ом на 10.8.1.1, видны ли айпишники из 172.24.1.0, если да, рисуйте роутинг.
NO_GLITCH, посмотрите, какие настройки NAT на 10.8.1.6 для сети 172.24.1.0. Если там SNAT или MASQUERADE, то ничего не выйдет, только менять топологию сети.
superfetch пытается выполнять адаптивное чтение в большой кэш, а если он промахивается, а тем более часто, то его чтение - пустая трата времени, так что ваша фраза неправильная.
Скорее всего влан при назначении появляется как тегированный, а на соединяющем устройстве порт не настроен принимать тегированные пакеты с этим вланом. Схема нужна, определенно.
Ну, если хотите скрипт, можно делать, скажем, start-process cmd.exe -wait, потом отключать диск. В случае флага -persist на new-psdrive диск будет виден в комстроке.
в правилах OUTPUT не заблокируется, так как ssh контролируется правилами на INPUT, а в OUTPUT должно (хотя надо бы проверить) присутствовать правило -m state --state RELATED,ESTABLISHED -j ACCEPT. Как вариант, составить правило с ! -d ip_address -p tcp --dport 666 -j DROP, чтобы не париться с изменением дефолтной политики на OUTPUT.
akelsey, примерно понимаю, поэтому и говорю, что мангл в принципе здесь не нужен. И кстати, у вас микротик натить не должен вообще в такой конфигурации, а он у вас натит. А к ВМкам надо ходить через внутренние интерфейсы, иначе у вас полноценный hairpin, чего роутеры особо-то не любят.
akelsey, то есть 10.10.0.0/16 должны выходить в интернет через Х.Х.Х.Х, при этом микротик работает только как vpn-устройство, без ната? Тогда пишите на нем дефолтный маршрут в тоннель на 10.1.0.2, а маршрут до Х.Х.Х.Х через шлюз провайдера (который на нем сейчас шлюз по умолчанию). Тогда весь трафик в Интернет из сетей за микротиком будет завернут в тоннель, Х.Х.Х.Х она же 10.1.0.2 его будет натить, и доступ внутрь 10.10.0.0/16 пойдет через Х.Х.Х.Х а не Y.Y.Y.Y. Вроде то, что вы хотите.
