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

Кстати вместо модема во 2 варианте можно использовать прокси-сервер, а на Сервер например TeamViewer, тут тебе и передача файлов на Пользователь и VPN- драйвер (см.доку по TeamViwer). Ну а прокси несложно сделать из любого компа с интернетом.Количество вариантов резко увеличиться.

Не работает, поподробнее можно?Идеи, как сделать у меня есть, не получается конкретная реализация. Даже чтобы организовать удалённый стол надо как минимум чтобы Пользователь пинговал Сервер. С этим проблемы. А стол через стол - Пользователь рехнётся с этим "удобством" работы с такой конструкцией.

Простейший вариант здесь удалённый стол через TeamViewer (тот же RDP).Но для этого необходимо иметь интернет на Сервере. С учётом невозможности установить дополнительную сетевую карту остаётся вариант проки-сервер. То есть нужно любое подключение к интернету на машине находящейся в той же сети, что и Сервер. На нём любым программным способом делать прокси. Теперь тот же TeamViewer (у него очень гибкие настройки) установить на сервере и дать ему соединение с интернетом через прокси.Всё!!!С любой машины имеющей доступ к интернету и установленным (запущенным) TeamViewer вы получите возможность полноценно работать на сервере, без наличия на нём реального IP, и действительно сложной настройкой маршрутизации. TeamViewer выигравает перед RDP, за счёт передачи файлов с удаленной машины Север на локальную Пользователь.

И отпадает необходимость в этом:
"2 карта соединена через АДСЛ-модемы (точка-точка, бридж, услуга сторонней организации "Телеком", маршрутизировали на своём оборудовании) с удалённым Пользователем (Win XP)
192.168.101.1 255.255.255.0 шлюз 192.168.101.101"

Кажется всё.

Интернета в сети нет и в принципе не будет никогда. Поэтому иного способа как организовать канал с удалённым пользователем у меня нет

2 карта соединена через АДСЛ-модемы (точка-точка, бридж, услуга сторонней организации "Телеком", маршрутизировали на своём оборудовании) с удалённым Пользователем (Win XP)

route add -p 192.168.1.0 mask 255.255.255.0 172.16.1.1

Такая конструкция работать не будет, эта команда не отрабатывает, так как шлюз находится вне сети, или я не прав?

Такая команда должна отработать, т.к. шлюз 172.16.1.1 находится внутри подсети 172.16.0.0/16, к которой относится "сервер"
В идеале включенной на "шлюзе" маршрутизации и такого маршрута вполне хватит для работы данной схемы
Если при выполнении команды возникает ошибка, то предоставьте ее для просмотра

Просьба опубликовать лог-команды tracert от пользователя до шлюза, да и ping тоже.

Сделайте как я описал.
Отчего вы решили что не будет работать.

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

Соберите железо!

Нет идеальных людей или техники. Приходится работать с тем, что есть.)))
Есть мысль как это сделать, нужны данные.
Лог-команды tracert и ping от пользователя до шлюза.
Кстати, Ув., Асхат Мадиевич я ознакомился со всеми предложениями и вынес много полезного. Изменить бывает можно, переделать никак.(((

Нет идеальных людей или техники. Приходится работать с тем, что есть.)))

Вот это вы в самую точку, за живое можно сказать задели

Изменить бывает можно, переделать никак.(((

Переделать то можно, но для рабочей системы это критично.
Всегда советую делать бэкапы, в данном случае бэкап системы. Я в ответе описывал про это.
Ночью сделали изменения, попробовали, не получилось вернули и днем опять в думы пуститесь.

Не работает схема. 20120525_Ne_mogu_marshrutizirov.doc (51.5 кб) - здесь выложил всё, что мне удалось достичь.

От Шлюза до пользователя точка-точка работает нормально, пользователя на Сервер прописать не удалось. В предыдущем посте подробно нарисовал сеть. Адреса немного не такие, как в вопросе, но это не принципиально. Да и у Вас, как понимаю, 172.16.1.1 - это описка, в вопросе этот адрес не звучал. Конечная цель - запустить у пользователя программу, которая будет работать с базой сервера.

Да 172.16 написал по привычке.

Если я правильно понимаю:
- шлюз и сервер пингают друг друга
- пользователь и шлюз пингают друг друга
- пользователь и сервер не пингают друг друга
Так?

Если да, то openvpn на шлюзе 100% решит задачу. Если хотите именно роутингом - покажите здесь вывод tracert со всех на всех - тогда можно будет что-то придумать.

Сегодня вечером отключил все АДСЛ-модемы, а злополучный включил в общую сеть. У удалённого пользователя программа прекрасно запустилась. Пользователь прекрасно подключился к моему серверу. Если так оставить, то с другим модемом появится аналогичная проблема. Источник проблемы - каждый разработчик внешнего софта с внешними базами требует для себя отдельный канал (вплоть до отдельного компьютера).

Если я правильно понимаю:
- шлюз и сервер пингают друг друга
- пользователь и шлюз пингают друг друга
- пользователь и сервер не пингают друг друга
Так?

- совершенно верно. Завтра на работе выдам tracert, увы, подозреваю, он не поможет. Я даже не могу допинговаться от Сервера до шлюза Телекома ...2,101, при том, что до модема, включенного в сетевую карту на Шлюзе, (как до устройства с адресом ...2,100) допинговываюсь прекрасно. [offtop]Всем спасибо за сотрудничество[/offtop]

У Вас что-то слишком много сетей с одинаковым началом адресации и разными масками - это основная причина заплетов.
И еще - либо у меня в linux'e libreoffice криво отображает схему, либо там не все адреса. Напишите в догонку к tracert еще и адреса с масками всех карточек сервера, шлюза и удаленного.

да, что-то в схеме не то, т.к. модем HDSL смотрит в свитч своим адресом 173.52.1.1, но для кого он туда смотрит не понятно, т.к. на SQL-сервере адрес 173.52.2.2 с маской 255.255.255.0, а не 255.255.0.0
а больше устройств из подсети 173.52.0.0 к свитчу не подключено
уточните схему со всеми адресами и допишите все маски

Пользователь 173.52.2.4 работает с сервером 173.52.2.2 по выделенной линии с модемами соответственно 173.52.2.3 и 173.52.2.1. Соединение работает успешно, более того, это соединение можно вообще не рассматривать, так как при желании я его волен перенастроить на любые адреса, так как не завязан на услугу телекома. Это выделенная линия.
В схеме нарисовано как есть и все маски указаны. Для сети 172.17... 255.255.0.0 Для сети 173.52... 255.255.255.0
На моей стороне центральная точка со шлюзом 173.52.2.101. На стороне удаленных пользователей 173.52.nnn.101. Пользователи видят центральную точку и не должны видеть друг друга.
Сейчас у меня лимит времени исчерпан, больше эту схему не рассматриваю. Убрал из общей сети другой модем, из-за которого возникали проблемы для нужного мне соединения. Модем для связи с удалёнными клиентами подключил в общий свич, задача у пользователя работает. Далее начинаю подключать других пользователей этой задачи. Теперь возникла проблема маршрутизации для другой задачи, но даже если мне это и не удастся сделать, там возможно другое решение. И несколько дней в наличии.
Спасибо всем, кто взял на себя труд вникнуть в проблему. Буду благодарен, если появятся еще рекомендации.

Вижу во то, что в аттаче. Гипотетически оно работать может, но с маршрутизацией будет черт-и-что.
Рекомендация остается одна: избегайте возможности возникновения неопределенности в выборе маршрута. Сейчас сервер блудит в трех соснах между большой сеткой 173.52.х.х/255.255.0.0 и меньшими подсетями 173.52.Y.х/255.255.255.0, которые оказались за роутером, а по его представлениях - есть частью той большой.

У Вас криво отобразился файл. 8336.pdf (161.5 кб)

Теперь понял. Все выше сказаное о неоднозначности маршрутов забываем - с сетями все в порядке. (хотя 173.52.2.х в двух местах - "не есть гуд")

Задача доступа с помощью маршрутизации не решается без участия "Белтелекома". При такой схеме нужно, чтобы их оборудование правильно маршрутизировало сетку 172.17.х.х . Хотя она здесь выглядит "притянутой за уши" и похоже изначально все строилось по схеме к которой Вы в конце-концов пришли - все модемы в общем свиче.

Если вдруг придется все вернуть назад и провайдер не пойдет на встречу - VPN с клиента на шлюз + маршрутизация или VPN и с клиента и с сервера на шлюз.

Как вариант - настройка управляемого свича, но это требует времени на освоение и, не дай бог, он "ляжет" - быстро такой свич не купишь, дорого, а рабочий процесс не должен останавливаться.

Свич третьего уровня (второго нет смысла брать - с ним маршрутизировать все равно через сервер придется) будет делать то же самое, что сейчас делает Ваш "шлюз". Разве что Вы захотите каждого удаленного работника в отдельную сетку закинуть и каждого отдельным мостом соединить. Тогда да - он будет шлюзом с бОльшим количеством сетевых чем любой среднестатистический сервак.
А настройки и цен боятся не стоит, если Вы конечно не на "Сисько" нацелились. Можно найти свич третьего уровня где-то за 500-1000 условных баксов, а самая минимальная настройка будет делать как раз то, что надо - маршрутизировать между всеми сетками.
Нормальный UPS и ничего не "ляжет" - из всех свичей с которыми приходилось иметь дело ни один не умер от перенагрузки трафиком, а вот три или четыре блока питания "ушло". После чего во все коммутационные шкафы UPSов понатыкали и забыли даже где от них ключи :-)
Если есть такая надобность и возможность - ставте "умные" свичи - разобратся с ними достаточно просто, а жизнь в сети облегчают существенно.