Назад | Перейти на главную страницу

Маршрутизация на шлюз удаленного рабочего стола во внутренней сети

У меня есть один физический хост, который я использую в качестве лаборатории виртуализации, и несколько виртуальных машин на Hyper-V, которые подключены к хосту через внутреннюю сеть. У меня это работало так, что физический хост действовал как шлюз удаленного рабочего стола, маршрутизатор указывает на шлюз, и все было хорошо, я мог войти в свою виртуальную машину через Интернет.

С тех пор я переместил свой шлюз на виртуальную машину во внутренней сети, которая находится в DNS моего активного каталога на remote.example.com со статическим IP-адресом. Это сделано для того, чтобы отдельные виртуальные машины выполняли определенные роли, и что в конечном итоге я смогу использовать балансировку нагрузки на своих виртуальных машинах.

На данный момент, когда только одна виртуальная машина действует как RDG, я могу получить доступ ко всем своим виртуальным машинам во внутренней сети с моего хост-компьютера, так как он может видеть IP-адрес для remote.example.com. Я решил, что мне нужно добавить пересылку / маршрутизацию / перенаправление на хост-машину, чтобы сделать шлюз видимым «извне».

(Интернет) == 1 ==> (Маршрутизатор) == 2 ==> [Хост] == 3 ==> [remote.example.com] == 4 ==> [VM_1 | VM_2 | VM_3]

Каков правильный способ получить от моего хоста прокси-запросы к моей внутренней виртуальной машине / шлюзу?

Моя текущая настройка ARR в моем ApplicationHost.config:

<webFarms>
    <webFarm name="Remote" enabled="true">
        <server address="192.168.1.3" enabled="true" />
        <applicationRequestRouting>
            <protocol>
                <cache enabled="false" />
            </protocol>
        </applicationRequestRouting>
    </webFarm>
    <applicationRequestRouting>
        <hostAffinityProviderList>
            <add name="Microsoft.Web.Arr.HostNameRoundRobin" />
            <add name="Microsoft.Web.Arr.HostNameMemory" />
        </hostAffinityProviderList>
    </applicationRequestRouting>
</webFarms>

В system.webServer / rewrite / globalRules:

<globalRules>
    <rule name="ARR_Remote_loadbalance_SSL" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
        <match url="*" />
        <conditions>
            <add input="{HTTPS}" pattern="on" />
            <add input="{HTTP_HOST}" pattern="remote.example.com" />
        </conditions>
        <action type="Rewrite" url="https://Remote/{R:0}" />
    </rule>
    <rule name="ARR_Remote_loadbalance" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
        <match url="*" />
        <action type="Rewrite" url="http://Remote/{R:0}" />
        <conditions>
            <add input="{HTTP_HOST}" pattern="remote.example.com" />
        </conditions>
    </rule>
</globalRules>

Редактировать:

На внешнем устройстве я могу подключиться к https://remote.example.com и увидеть целевую страницу IIS. Когда я перехожу на https://remote.example.com/rpc, я получаю 503 Должен использовать сообщение

Когда я пытаюсь использовать сервер шлюза через RDP-клиент, я получаю

The gateway failed to connect with the message: 404 not found

После перезагрузки хоста и виртуальной машины я могу получить доступ к сайту с внешнего устройства, и я могу выполнить трассировку неудачного запроса на RDP-соединении.

и похоже, что ARR пытается обработать сам запрос, а не пересылать его на удаленную виртуальную машину.

Оказывается, это был простой случай слегка неправильно настроенных настроек. Я опубликовал шаблон для маршрутизации ARR: {HTTP_HOST} = remote.example.com. Согласно журналам неудачных запросов, это не соответствует

Я считаю, что это связано с тем, что правила ARR будут рассматривать только имя хоста, т.е. remote.example, а не remote.example.com, как различные комбинации, такие как remote.example., удаленный., remote * совпадают и перенаправляются правильно, возможно, я пропустил некоторые уловки с сопоставлением с образцом для ARR.

Для справки я в основном следовал этому руководству: http://www.msexchange.org/articles-tutorials/exchange-server-2013/mobility-client-access/iis-application-request-routing-part1.html

Я почти уверен, что использование ARR не поддерживается, даже если оно сработает. Самый простой выход - разрешить виртуальной машине шлюза взаимодействовать с «внешней» сетью, чтобы ваш маршрутизатор мог напрямую отправлять в нее трафик. Или вам нужно «что-то», что может направлять трафик на виртуальную машину шлюза, межсетевой экран NAT или что-то еще. Я бы не стал класть это "что-то" на свой Hyper-V бокс, его нужно держать как можно более чистым.