LAN (Client) -> KWF -> Inet -> KWF -> LAN (Terminal Server)

[det]

Ситуация такая. Есть две фирмы А и Б, расположенные в разных городах. Обе имеют одноранговые локальные сети (рабочие группы), в которые раздают интернет при помощи WRF 6.

В локалке фирмы А расположен терминальный сервер. Необходимо открыть доступ к этому терминальному серверу из интернета (для бухгалтеров фирмы Б). Соответственно, в фирме Б для этого необходимо открыть доступ в интернет по протоколу RDP.

IP у обоих фирм динамический, статический провайдер не предоставляет.

Пытался вот с такими настройками (во вложении) - не работает ну вообще никак( А шеф подгоняет...

[naliman]

динамический IP - не проблема
уже давно все используют системы динамических ДНС (DynDNS к примеру)
- регистриуешься на сервисе динамического днс ( например Dyndns.com)
- заводишь себе имена для обоих филиалов (например firma1.dyndns.com, firma2.dyndns.com)
- на каждый server ставишь клиент, который следит за изменением IP и сразу правит ДНС-зону

в итоге адрес у тебя динамический, но постоянно доступен по одному и тому же имени

после этого:
- в одном филиале (откуда доступ) делаешь правило разрешающее РДП куда нужно и кому нужно
- во втором филиале (куда доступ) делаешь правило соответствующее (оно на картинке второе, состевлено правильно)

[С.С. Горбунков]

det,
неправильно выпускаешь клиентов из сети Б
надо так:
"Подключение по локальной сети" -> Megaline : RDP : Permit : NAT

а для победы над динамическими айпи придуман сервис no-ip.com, где нада зарегиться, создать 2 А-записи, и в дальнейшем доступ осуществлять по ДНС-именам (клиент no-ip.com бесплатный, работает сервисом)

[det]

Спасибо за DynDNS, обязательно попробую.

Была проблема с внутренним фаерволом ethernet-модема, поставил обычный на принимающей стороне и в логах KWF стали появляться записи о входящем подключении.

Также переписал правило, как подсказал С.С. Горбунков:

Цитата

Подключение по локальной сети" -> Megaline : RDP : Permit : NAT

Изменилось лишь то, что в логах Connection на принимающей стороне вместо записи:

[12/Nov/2008 16:50:36] [ID] 1976 [Rule] TERMINAL [Service] RDP [Connection] TCP 95.58.131.187:10385 -> 192.168.1.74:3389 [Duration] 90 sec [Bytes] 144/0/144 [Packets] 3/0/3

появляется запись:

[12/Nov/2008 17:04:20] [ID] 2246 [Rule] TERMINAL [Service] RDP [Connection] TCP 95.58.131.187:11354 -> TERMINAL:3389 [Duration] 90 sec [Bytes] 144/0/144 [Packets] 3/0/3

То есть вместо IP комьютера - его NETBIOS-имя.

В остальном все осталось по-прежнему - при попытке подключения вылетает ошибка:

Удаленный рабочий стол отключен. Клиенту не удалось подключиться к удаленному компьютеру.

Разбор пакетов:

[12/Nov/2008 17:47:04] PERMIT "TERMINAL" packet from Megaline, proto:TCP, len:48, ip/port:95.58.131.187:12534 -> 89.218.178.25:3389, flags: SYN , seq:638655478 ack:0, win:65535, tcplen:0
[12/Nov/2008 17:47:04] PERMIT "TERMINAL" packet to Подключение по локальной сети, proto:TCP, len:48, ip/port:95.58.131.187:12534 -> 192.168.1.74:3389, flags: SYN , seq:638655478 ack:0, win:65535, tcplen:0
[12/Nov/2008 17:47:07] PERMIT "TERMINAL" packet from Megaline, proto:TCP, len:48, ip/port:95.58.131.187:12534 -> 89.218.178.25:3389, flags: SYN , seq:638655478 ack:0, win:65535, tcplen:0
[12/Nov/2008 17:47:07] PERMIT "TERMINAL" packet to Подключение по локальной сети, proto:TCP, len:48, ip/port:95.58.131.187:12534 -> 192.168.1.74:3389, flags: SYN , seq:638655478 ack:0, win:65535, tcplen:0
[12/Nov/2008 17:47:13] PERMIT "TERMINAL" packet from Megaline, proto:TCP, len:48, ip/port:95.58.131.187:12534 -> 89.218.178.25:3389, flags: SYN , seq:638655478 ack:0, win:65535, tcplen:0
[12/Nov/2008 17:47:13] PERMIT "TERMINAL" packet to Подключение по локальной сети, proto:TCP, len:48, ip/port:95.58.131.187:12534 -> 192.168.1.74:3389, flags: SYN , seq:638655478 ack:0, win:65535, tcplen:0

[det]

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

А между тем, все работает. Надо было лишь настроить правило на принимающей стороне: в поле Translation установить переключатель Source NAT в положение Translate to ip address of interface и выбрать интерфейс локальной сети из выпадающего списка.

Дополнительно сегодня настроил Dynamic DNS: на подключающейся стороне в конфигурации роутера (ADSL-модем с портами Ethernet и фаерволом), а на подключаемой - при помощи службы DynDNS Updater (там Dial-Up ADSL-модем). Чую, что при установке роутера на подключаемой стороне (сети, в которой находится сервер терминалов) придется настраивать на нем переадресацию портов, но это будет уже другая история

В правиле на подключающейся стороне поэкспериментировал, указывая вместо интерфейса локальной сети в качестве источника пакетов отдельных пользователей (бухгалтеров), а вместо исходящего интерфейса в качестве получателя пакета - hostname подключаемой стороны, все работает!

Измененные правила прилагаются. Всем огромное спасибо

[det]

Цитата:

Сообщение от С.С. Горбунков

возможно, стоило выложить ipconfig /all с терминала.

Замотался малость, упустил. Дело в том, что у нас в сети два компьютера с KWF и прямым доступом в Интернет. Один из них раздает всем высокоскоростной, но не безлимитный инет. Второй раздает в разы более медленную, но безлимитку избранным (то есть мне и тем оболтусам, которым не жалко за это вкусняг доброму админу, то есть мне). Желательно обеспечить возможность подключаться удаленно через оба два компьютера.

Вот:

Microsoft Windows [Версия 5.2.3790]
(С) Корпорация Майкрософт, 1985-2003.

C:\Documents and Settings\Администратор>ipconfig /all

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : terminal
   Основной DNS-суффикс  . . . . . . :
   Тип узла. . . . . . . . . . . . . : неизвестный
   IP-маршрутизация включена . . . . : нет
   WINS-прокси включен . . . . . . . : нет

Подключение по локальной сети - Ethernet адаптер:

   DNS-суффикс этого подключения . . :
   Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 PM Network Connection
   Физический адрес. . . . . . . . . : 00-16-76-90-71-87
   DHCP включен. . . . . . . . . . . : нет
   IP-адрес  . . . . . . . . . . . . : IP_СЕРВЕРА
   Маска подсети . . . . . . . . . . : 255.255.255.0
   Основной шлюз . . . . . . . . . . : НЕ_IP_МАШИНЫ_С_KWF

Когда прописал в качестве основного шлюза IP той машины, через KWF которой пытался подключиться - все заработало и без Source NAT. Попытался при этом подключиться через KWF другой машины - тишина. Прописал ее IP, как второй основной шлюз на сервере терминалов - тишина.

Какие в подобной ситуации минусы у моего решения и какие еще решения возможны?

[С.С. Горбунков]

Цитата:

Сообщение от det

Когда прописал в качестве основного шлюза IP той машины, через KWF которой пытался подключиться - все заработало и без Source NAT.

ну никто не сомневался!

Цитата:

Сообщение от det

Прописал ее IP, как второй основной шлюз на сервере терминалов - тишина.

это ересь. основной шлюз в винде ОДИН!
другое дело - можешь прописать СТАТИЧЕСКИЙ МАРШРУТ на терминальном сервере до нужного хоста в интернете через другой комп с KWF. В твоем случае конкретно к хосту не получится наверно, потому как айпи динамический, и заранее неизвестен. поэтому надо прописывать маршрут в подсеть.

[det]

Цитата:

Сообщение от С.С. Горбунков

это ересь. основной шлюз в винде ОДИН!

Значит, это виндузная ересь, потому как:

Microsoft Windows [Версия 5.2.3790]
(С) Корпорация Майкрософт, 1985-2003.

C:\Documents and Settings\Администратор>ipconfig /all

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : terminal
   Основной DNS-суффикс  . . . . . . :
   Тип узла. . . . . . . . . . . . . : неизвестный
   IP-маршрутизация включена . . . . : нет
   WINS-прокси включен . . . . . . . : нет

Подключение по локальной сети - Ethernet адаптер:

   DNS-суффикс этого подключения . . :
   Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 PM Network Connection
   Физический адрес. . . . . . . . . : 00-16-76-90-71-87
   DHCP включен. . . . . . . . . . . : нет
   IP-адрес  . . . . . . . . . . . . : 192.168.1.74
   Маска подсети . . . . . . . . . . : 255.255.255.0
   Основной шлюз . . . . . . . . . . : 192.168.1.7
                                       192.168.1.3

И вот даже картиночка имеется во вложении.

[С.С. Горбунков]

det,
я не пойму, ты мне что-то пытаешься доказать? Не надо. Особенно насчет 2-х основных шлюзов в системе. Это хорошо, что другие не видят пока.

Повторяю, в твоей ситуации нужно оставить у терминала один основной шлюз, а возможность подключаться к терминалу через другой шлюз обеспечит статический маршрут.
route -p add subnet_of_remote_clients mask subnet_mask_of_remote_clients Internal_IP_of_other_KWF

[det]

Зачем мне чего-то кому-то доказывать? Вы специалисты, а я в этом деле новичок, и я просто хочу получить ответ на вопрос:

Цитата:

Сообщение от det

Какие в подобной ситуации минусы у моего решения и какие еще решения возможны?

Почему лучше лезть на сервант, прописывать там маршруты до айпишников, которые вообще могут быть разными (вдруг я через дайлап выйду, но под тем же DynDNS-именем?), чем поставить Source NAT на KWF и наслаждаться, а сервант вообще не трогать.

[С.С. Горбунков]

det,
то есть, если я правильно понял, при указании в правиле Source NAT
законнектиться к терминалу можно через другой шлюзовой комп?

[det]

Да, в том то и дело :-)

[det]

Ввиду затишья в теме и работоспособности представленной конфигурации вопрос прошу считать закрытым. Если кому интересно, во вложении приведены подробные инструкции по решению поставленного вопроса, включая настройку Dynamic DNS и аппаратных роутеров.

Скромно предлагаю перенести тему в раздел [Для просмотра данной ссылки нужно зарегистрироваться].

[EnMan]

Я почитал эту статью и считаю, что она неверна, ИМХО.
На мой взгляд спорно следующее.

Цитата

2. Обеспечение доставки пакетов до сервера.
[skip]
• Трансляция сетевых адресов (NAT) должна быть включена, а инспектор трафика, наоборот, отключен.

могу продемонстрировать, что НАТ включать не нужно и протокол инспектор выключать - тоже. Скорее всего, подобное требовалось афтару статьи только из-за того, что в его случае терминальный сервер имел шлюзом не один хост, а несколько - по числу его шлюзов в локалке.

Цитата

2. Обеспечение доставки пакетов до сервера.
[skip]
Если в локальной сети сервера выход в Интернет производится сразу с нескольких компьютеров, и доступ к серверу из Интернета необходимо обеспечить более чем с одного из них, необходимо для правила трансляции сетевых адресов также указать в качестве Source NAT интерфейс локальной сети, как это показано на рисунке ниже:

Очень и очень спорно. Но говорить, что делать так нельзя - я не стану. Нет возможности провериться. Но другими словами, автор хочет сказать, что, если в локальной сети есть ДВА физических шлюза и нужно обеспечить доступ к севреру внутри локальной сети с любого из них, то нужно всего лишь добавить НАТ в правило с МАПингом. Я не вижу этому логического объяснения, хоть убейте.

Также в его статье ни разу не сказано, что при таком развале шлюзов у сервера внутри локалки должно быть два (поручеги, молчать... ), но у одного сетевого интерфейса. И как будет работать интернет, в таком случае на сервере терминалов, мне не ясно ни разу. Пакет уйдет в первый же шлюз и таки попадет, куда надо, ведь он рабочий шлюз то.

Приглашаю к дискуссии.

[EnMan]

Ну уж и называться эта статья никак не должна "Удаленное управление через интернет". Это узкий случай автора.

[Valery12]

Как мне кажется предложенная автором система работоспособна, по крайней мере на сетевом уровне.
Как я это понимаю: у автора в локальной сети два шлюза КВФ1 и КВФ2 на разных провайдеров и он хочет чтобы через любой из них был доступ из внешней сети до терминального сервера в локалке,
даже если он добавляет на терминальном сервере оба КВФ как шлюзы по умолчанию работать он будет только через один (с меньшей метрикой) и только в случае его недоступности через второй
это значит что в случае обычного маппирования на запрос пришедший с КВФ2 сервер отправит ответ через КВФ1
если кроме маппирования включить и НАТ - КВФ2 заменит внешний IP хоста с которого пришел запрос на свой внутренний и серверу терминалов пользоваться маршрутами по умолчанию не нужно (они в одной подсети)он отправит ответ КВФ2 а тот согласно своей таблице НАТ отправит пакет нужному адресату во внешке
Другой вопрос, как при этом будет работать терминальный сервер в большим количеством пользователей, ведь для него они все будут локальными КВФ1 и КВФ2, трудно будет с сессиями разбираться.

[p0m]

А как можно реализовать отправку е-майла с помощью cronnt? Чтобы сразу после смены IP слал мыло с новым IP.