Sdscompany.ru

Компьютерный журнал
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Настройка vpn для rdp

Настройка vpn для rdp

Вопрос

Ответы

Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»

  • Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:08

Cложновато для моего понимания!)))

:))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.

У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.

Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉

P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».

  • Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:09

В опсчем-с, я поступил иначе. У актуального антивируса, помимо модуля «Защита от сетевых атак» есть модуль — «Сетевой экран», я в нём, в разделе «Сетевые пакетные правила» создал три правила для моих трёх внешних RDP- подключений. И всё. Итак:

Открываем настройки Сетевых пакетных правил, и далее:
1. Создаём новое правило
2. Действие — Разрешать
3. Отмечаем Протокол и выбираем TCP
4. Направление — Входящее
5. Локальный порт — 3389
6. Удалённые адреса — Адреса из списка
6.1. Нажимаем Добавить и указываем IP адрес или группу адресов используя маски, как написано в примере в окне ввода адресов
7. Нажимаем ОК в окне нового сетевого правила
8. При помощи кнопки Вверх в окне Сетевых пакетных правил перемещаем новое правило выше правила запрещающего «Сетевая активность для работы технологии удаленного рабочего стола»

Применяем настройки сетевого экрана и проверяем доступность сервера при удалённом подключении. Вуаля. )) А вы мне «. VPN. TMG. » ))) Шучу! )) Всем очень признателен за уделённое время и помощь! ))

  • Помечено в качестве ответа Joker Alvares 28 апреля 2017 г. 11:54

Все ответы

Если правильно понял вас проблема из-за неверно введенных паролей производится блокировка УЗ в AD. И вы решили вопрос поставив актуального антивируса и в отчетах нашли причну такова поведения, а именно Bruteforce.Generic.RDP ?

Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»

  • Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:08

В принципе, VPN на TMG поднимается на раз-два, в разнообразных вариантах, вроде и без мануалов понятно :).

Есть и другой вариант — поднять шлюз RDP и убрать возможность прямых подключений к RDP (только через шлюз). Основной фокус в проверке на соответствие политикам (предварительная авторизация) до аутентификации. При грамотно составленных политиках (какому эккаунту к какой системе подключаться можно) большинство попыток доступа отсеиваются без аутентификации (до), блокировки «популярного набора» учёток не будет. Дополнительный фокус — подключение по SSL/TLS, не каждый из ищущих открытых RDP будет туда ломиться. Компонент «шлюз RDP» на W2k8R2 вполне функционален.

  • Помечено в качестве ответа Joker Alvares 28 апреля 2017 г. 3:21
  • Снята пометка об ответе Joker Alvares 28 апреля 2017 г. 3:21

. По RDP извне официально подключаются трое пользователей. Поэтому, он всё таки нужен. Это если предложите отключить!)))) Есть мысль организовать VPN, и уже через него подключаться по RDP. .

В принципе, VPN на TMG поднимается на раз-два, в разнообразных вариантах, вроде и без мануалов понятно :).

Есть и другой вариант — поднять шлюз RDP и убрать возможность прямых подключений к RDP (только через шлюз). Основной фокус в проверке на соответствие политикам (предварительная авторизация) до аутентификации. При грамотно составленных политиках (какому эккаунту к какой системе подключаться можно) большинство попыток доступа отсеиваются без аутентификации (до), блокировки «популярного набора» учёток не будет. Дополнительный фокус — подключение по SSL/TLS, не каждый из ищущих открытых RDP будет туда ломиться. Компонент «шлюз RDP» на W2k8R2 вполне функционален.

Cложновато для моего понимания!)))

Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»

Как обычно у Майкрософт, — нагромождено всего, не разобраться, что важно на самом деле, а что нет.

Cложновато для моего понимания!)))

:))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.

У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.

Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉

P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».

  • Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:09

Cложновато для моего понимания!)))

:))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.

У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.

Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉

P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».

Есть нюанс: шлюз RDP (RD Gateway, RDG) на компьютер с TMG, на котором опубликованы по HTTPS внутренние серверы, так просто не поставить — он при настройках по умолчанию будет конфликтовать за порт 443 со службой, которая обеспечивает публикацию (она, к сожалению, не использует системный драйвер http.sys а прослушивает порт самостоятельно). Как установить RDG на сервере TMG в таком случае, я когда-то написал.

И ещё — про аутентификацию на RDG: если её сделать по доменной учётной записи, то эта запись точно так же будет блокироваться из-за попыток подбора пароля (хотя пароль будут пытаться подбирать не так часто, возможно). Я бы в таком случае подумал бы насчёт аутентификации на RDG по локальным учётным записям сервера, где стоит TMG. Это, конечно, создаёт неудобства для пользователей — им придётся при подключении использовать две разные учётные записи с двумя паролями, но зато проблем с блокировкой не будет.

Читать еще:  Настройка vpn туннеля

VPN и Удалённый рабочий стол: что нужно знать

VPN и Удаленный рабочий стол: что нужно знать

Хотя VPN-сервер и удалённый рабочий стол (Remote Desktop Protocol, RDP) создавались для различных задач, у них есть одна общая черта. И VPN-сервер, и RDP зашифровывают Ваш трафик и соединяют Вас с устройством, которое может находиться за тысячи километров. Но, разумеется, безопасный доступ в Интернет они предоставляют на разном уровне. Давайте разберёмся, чем же различаются эти две аббревиатуры.

VPN-сервер и удалённый рабочий стол (RDP): в чём сходства и различия

Странный вопрос для системного администратора, но если Вы не сисадмин и читаете эту статью, Вам это может быть не очевидно. И VPN-сервер и RDP шифруют трафик, оба предоставляют для Вас частный доступ к серверу хоть на другом краю земного шара. Так в чём же разница? Главное, чем различаются VPN-сервер и RDP – задача, для которой эти технологии были придуманы:

● VPN-сервер — это «стелс-режим», который Вы включаете, чтобы избежать лишнего внимания хакеров или спамеров, например, если используете персональный VPN при подключении к общественному Wi-Fi (мы ОЧЕНЬ рекомендуем так делать — с безопасностью таких точек доступа всё очень плохо, об этом мы рассказываем в отдельной статье). Или, например, Вам нужно зайти на страницу, которая заблокирована правительством в том месте, где Вы сейчас находитесь. Включаете персональный VPN — и спокойно заходите на нужный сайт из другой точки мира. ● RDP – это другая технология. RDP был создан, как следует из названия, для удалённого доступа к рабочему столу. Например, Вы в командировке, но Вам понадобилось зайти на свой рабочий компьютер в офисе. RDP позволит Вам это сделать, как будто Вы находитесь на рабочем месте.

RDP: как он работает

Начнём с того, что RDP – это название конкретной программы от Microsoft. Но на практике название RDP применяется к любой программе, предоставляющей удалённый доступ к другому компьютеру. Итак, как работает RDP?

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

Вся прелесть в том, что все вычислительные мощности удалённого компьютера находятся в Вашем распоряжении. Поэтому RDP очень популярен, например, у любителей компьютерных игр, требовательных к мощности ПК. Да и люди с более серьёзными задачами, чем поиграть в вымышленных мирах, с радостью найдут RDP применение – например, решая научные задачи со сложнейшими вычислениями или обсчитывая 3D-модели в инженерном проекте.

Разумеется, для такого объёма данных требуется мощное интернет-соединение, поскольку при работе RDP требуется передавать между компьютерами огромные массивы данных. Более того – и здесь мы переходим к необходимости использовать VPN-сервер, работая с протоколом RDP – такому соединению необходима качественная защита. Безопасный доступ в Интернет здесь критично важен. Ведь если Вы не используете VPN-сервер, и хакер вклинится в Ваш протокол RDP, то он получит доступ ко всему, что есть на целевом компьютере. А затем и на Вашем.

VPN-сервер: как он работает и почему необходим при работе с RDP?

VPN-сервер работает совсем иначе. Когда Вы используете VPN-сервер, то сначала подключаетесь к нему, а уже через VPN-сервер переходите на любой сайт и используете любые приложения. Безопасный доступ в Интернет – вот главная задача VPN. VPN-сервер зашифровывает все данные, которые Вы передаёте, к тому же, он маскирует Ваше местоположение – поскольку Вы заходите на сайты через VPN-сервер, находящийся где угодно. Например, VPN-серверы BroVPN находятся в Панаме. Именно поэтому VPN-сервер очень важен при работе с протоколом RDP. Они прекрасно дополняют друг друга: благодаря RDP Вы можете подключиться к нужному Вам компьютеру в любой точке мира, а VPN-сервер обеспечит Вам безопасный доступ в Интернет.

VPN-сервер или RDP: что для Вас важнее?

Как Вы уже поняли из статьи, и то и другое – полезные вещи. Часто необходимые. Так что же установить в первую очередь? Смотря какие у Вас задачи.

Если Вы предприниматель:

● Персональный VPN однозначно нужен, чтобы обеспечить подчинённым безопасный доступ в Интернет. Персональный VPN должен быть доступен им с любых устройств, в том числе с ноутбуков и гаджетов в поездках;

● Премиум-VPN обязательно требуется для безопасности Вашей локальной сети. Защищённый VPN сервер, на котором находятся общие файлы – это базовое требование цифровой безопасности;

● RDP Вам точно понадобится, как только Вам лично или любому сотруднику потребуется файл с офисного компьютера или корпоративного сервера;

● RDP в обязательном порядке должен быть у всех Ваших системных администраторов. Любой сисадмин должен иметь доступ, чтобы решать возникающие проблемы удалённо со своего устройства.

Если Вы просто пользователь, которому нужен безопасный доступ в Интернет:

● Персональный VPN поможет Вам обеспечить конфиденциальность и анонимность в Сети;

● Персональный VPN поможет Вам обойти государственные запреты на посещение отдельных сайтов, которые нужны Вам для дела или отдыха;

● Используя VPN-сервер, Вы обеспечите себе безопасный доступ в Интернет;

● VPN-сервер поможет Вам просматривать любой контент и заходить на любые сайты, в том числе те, которые заблокировало правительство страны, где Вы находитесь.

Также добавим, что RDP может работать и в многопользовательском режиме. Это не очень безопасно (мягко говоря), поэтому, если хотите сохранить безопасный доступ в Интернет для всех пользователей Вашего RDP, обязательно используйте VPN-сервер и голову: когда можно обойтись одним RDP-подключением, ограничивайтесь одним. Вы должны полностью доверять тому человеку, которому предоставляете доступ через RDP. Помните: персональный VPN сегодня – это не излишество, а необходимое условие, чтобы безопасный доступ в Интернет был для Вас не пустым звуком!

Попробуйте наш VPN-сервис абсолютно бесплатно прямо сейчас:

Настройка VPN Сервера из «коробки», просто и быстро (SoftEther VPN)

Про защиту RDP много сказано и много написано как избежать взлома, как защитить сервер, как хранить копии, где хранить и т.д., все это не когда не будет лишнем. Но одним из самых надежных все же является VPN сервер со своими протоколами, сертификатами, шифрованиями и т.д.

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

SoftEther VPNэто мощный продвинутый мультипротокольный VPN-сервер под лицензией CPLv2 (т.е. совершенно свободный к распространению и использованию). Способен поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол «SSL-VPN», который неотличим от обычного HTTPS-трафика. Работает что называется «из коробки».

Читать еще:  Опишите действия после команды защитить документ

Офф. сайт для скачивания, так же там имеется вся документация по настройке (на англ.): www.softether.org

Русской локализации данная программа не имеет, что может вызвать трудности при тонкой настройке самого сервера, прав доступа и т. д.

1. Скачиваем и устанавливаем программное обеспечение, серверная часть:

2. После установки, преступаем к настройке сервера VPN. Имя хоста, порт VPN севера, учетные данные для администрирования.

При первом входе запросит задать пароль администратора

3 . После переходим к настройке самой серверной части для дальнейшей его работы:

Описание настроек что и для чего необходимо более детально, можно найти в документации.

Данная настройка позволяет получать доступ к сети любому клиенту подключенному к VPN серверу, как будто они находятся в одной физической сети.

Указываем имя VPN сервера

— Включить функцию сервера L2TP через IPsec (включено)

— Включить функцию сервера L2TP без шифрования (выключено в нашем случае)

После настройки, создаем пользователей для VPN сервера.

1. Имя пользователя

2. различные типы аутентификации (самые предпочтительные просто парольная защита и пароль + сертификат)

3. При аутентификации по сертификату создаем сертификат на пользователя.

4. При создание указываются данные пользователя сертификата, срок действия, тип и т.д.

После создание сохраняем сертификат и ключ сертификата.

4. Настройка и управление VPN сервера и хаба:

Настройки виртуальной сети, настройка DHCP сервера (рекомендую отключить DHCP и прописать адреса вручную на виртуальном адаптере), интервал IP адресов, маски и т. д.

5. Настройка Security Policy для пользователя (в моем случае оставил все по умолчанию):

6. Настройка сетевого моста для объединения нескольких сетей в том числе и разных VPN сетей (в нашем случае она не нужна этот пункт можно пропустить). И перейти к настройке клиентской части программы.

Для настройки моста необходима дополнительная библиотека, WinPcap — низкоуровневая библиотека 32-битных систем Windows, для взаимодействия с драйверами сетевых интерфейсов. Она позволяет захватывать и передавать сетевые пакеты в обход стека протоколов. Скачать ее можно тут: www.winpcap.org

7. Настройка и установка клиентской части VPN-клиента (для этого нам понадобится дистрибутив для клиентской части):

Добавление клиента к VPN подключению:

— Адрес сервера (белый, внешний IP адрес), порт сервера указанный при настройке (по умолчанию 5555), имя VPN сервера (по умолчанию VPN)

— Выбираем способ аутентификации по которому был настроен доступ к серверу (в нашем случае по сертификату и паролю)

— после чего создается подключение по которому можно цепляться к VPN серверу (не забудьте настроить проброс порта на сервер в примере 5555 иначе может не подключаться) и потом уже заходить по RDP как по локальной сети (так же можно настроить доступ к ресурсам сети, принтерам, компьютерам сети и т.д.)

Для минимизации для пользователей можно настроить простой вид:

8. Так же необходимо создать правило маршрутизации для сервера VPN (интернет будет использоваться вашей машины, а не VPN сервера):

route add 192.168.1.10 192.168.30.1 -p

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

Настройка vpn для rdp

Это каким же таким образом, интересно?
Шифрованные/инкапсулированные пакеты будут идти с теми же задержками, скоростью, и потерями, что и нешифрованные.
Плюс добавятся издержки на шифрование/дешифрование с обеих сторон.
Кстати, трафик самого РДП — уже шифрованный.

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Вот тут нюанс один — много тонких клиентов и они сами VPN не умеют. И я не знаю, поднимать ли для этого шлюз с фаерволом, чтобы весь трафик, адресованный серверу, шел через тоннель. Или это вообще не то решение?

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

Безумная идея. При большом количестве установленных тоннелей стабильность не вырастет, зато прожорливость ресурсов возрастёт.

Однозначно делать так.

Только RouterOS, из этих двух вариантов
Другие варианты, cisco, zywal, d-link, zyxel. вариантов много, все зависит что вы хотите по надежности и сколько готовы выложить за железку

Настрой на сервере Firewall чтобы пускало в RDP только с офисного IP.

Добавлено:
Да.
На сервере установи службу VPN. заведи одну учетную запись.

На тот случай, если у твоего провайдера внезапно возникнет желание изменить IP офиса. Ты тогда сможешь подключиться к VPN с любого места, и настроить firewall на новый ip address офиса.

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Windows serv 2003 sp2, IP динамический, привязан к хосту через No-IP, модем Huawei HG532e работает в режиме роутера который соединяется с провайдером и получает динамический адрес,
тип соединения IPoE. На серваке поднят VPN-сервер, соединение работает с шифрованием,
проверялось на удаленной машине.

В NAT прописано маршрутизацию по портам удаленный доступ и VPN, на модеме подброшены порты, соединение RDP за NAT работает с подключенным VPN и без. Можно достучатся к серв. с помощью mstsc.

чёт не получается настроить полноценный VPN, что бы заходить по RDP только после подключенного VPN, работает и без него

или полноценного VPN не получишь без минимум двух серевух, если выключаю на модеме порт удаленного доступа, VPN работает, по RDP зайти не могу….(

подскажите человеку не ит образ., возможно ли настроить полноцен. впн на одной сетевухе, и без дополнительных железяк типа cisco, zywal, d-link, zyxel. чтобы через тоннель шёл только RDP и FTP трафик?

При RDP / VPN / PPTP — не использовать это подключение для «своего» инета

Возникла потребность подключения к серверу по RDP , но этот сервер предоставляет к себе доступ только после установки VPN по протоколу PPTP. Увидел, что в настройках соединений (просто кликнул мышью по значку подключенной сети) имеется возможность для создания нового VPN подключения, указал там протокол, вид защиты и все остальное.

VPN-Соединение устанавливается успешно.

Затем RDP настроил (воспользовался для этого Remina) — тоже устанавливается.

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

Какие изменения нужно внести, чтоб сохранилась возможность подключения по RDP на этот сервер? Потому что простая перестановка параметра в IPv4 «автоматически (VPN, только адрес)» проблему с трафиком решает, но при этом же и по RDP подключиться не дает.

Дополню чуток, что при настройке этого всего подкл на клиенте с win8 или 10 — все хорошо-легко по трафику решается простым снятием флага в свойствах IPv4

А все попытки протестить все на win7 просто оказались безуспешными — на этот сервер VPN соединение не устанавливается и дальше все равно, что ни делай.

Да и если не заморачиваться, не задумываться о том, что весь мой инет-трафик уходит теперь через это VPN, то все прекрасно работает в RDP и стабильно так, комфортно.

(2) видел. тестил. если его ставишь — RDP не успешно.
Хотя нужный адрес пингуется.

Читать еще:  Порт vpn сервера

а трафик после установки галки такой как мне хочется 🙂

так. кое-что нашлось.
Оказывается, что уже установлено (может даже при установке на комп все было включено)
network-manager-pptp — это и позволило поднять VPN с нужным протоколом.
network-manager-pptp-gnome
network-manager

это все есть. и расставить галки, как я выше уже упомянул — можно. Даже результат нормальный, т.е. возможно такой, какой нужно. Только RDP перестает соединение устанавливает — пишет, что не находит адрес. Но пинг к нужному адресу в терминале есть. Чего-то ему еще нужно разрешить, но не пойму.

(14) ок. поставлю route add default gw

// А для походов в нужную сеть через VPN добавь маршрут.
(15) // Там надо указать подсеть куда должны идти пакеты.

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

Продолжаем. Что подтверждается из предложенного выше и так получается, что в (3) близкий для меня путь, но что-то не срабатывает до конца

Захожу network-manager-pptp-gnome (оно вызывается кликом ПКМ по значку сети в уведомлениях десктопа)
При изменении настроек VPN имеется вкладка «Параметры IPv4»
В ней есть «Маршруты. » — кликаю и попадаю в окошко с настройками «Маршруты IPv4 для ИмяМоегоVPN»
там есть окошко с колонками Адрес/Маска сети/Шлюз/Метрика кнопки Добавить Удалить
и ниже этого окошка две галки «Игнорировать автоматически полученные маршруты» «Использовать это соединение только для ресурсов в этой сети»

Вот как ставлю галку «Использовать это соединение только для ресурсов в этой сети» — получаю нужное мне направление всего инет-трафика через моего провайдера, который ничего мне не режет.
Если галку снимаю — инет-трафик уходит на провайдера, который внутри VPN

Но когда установлена галка, то RDP не устанавливается. Подозреваю, что нужно заполнить хотя бы одну правильную строчку в Адрес/Маска сети/Шлюз/Метрика. На установленном VPN и поднятом RDP подсмотрел в сведениях на их стороне значения Адрес/Маска сети/Шлюз — но не догоняю, а что в Метрика надо написать, чтоб оно работало? И как надо правильно написать?

Перечитал найденную статью (17) и решил, что там не мой случай, т.к. не выручила она меня

ping 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.
From 91.243.96.41 icmp_seq=6 Packet filtered

ping ya.ru
PING ya.ru (213.180.193.3) 56(84) bytes of data.
64 bytes from http://www.yandex.ru (213.180.193.3): icmp_seq=1 ttl=56 time=22.2 ms

вот такая разница

$ ifconfig
eth0 Link encap:Ethernet HWaddr 90:2b:34:97:65:ef
inet addr:192.168.1.36 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::922b:34ff:fe97:65ef/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1150624 errors:0 dropped:0 overruns:0 frame:0
TX packets:908668 errors:0 dropped:0 overruns:0 carrier:3
collisions:0 txqueuelen:1000
RX bytes:1110743656 (1.1 GB) TX bytes:125187808 (125.1 MB)

lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:87284 errors:0 dropped:0 overruns:0 frame:0
TX packets:87284 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11787754 (11.7 MB) TX bytes:11787754 (11.7 MB)

ppp0 Link encap:Протокол PPP (Point-to-Point Protocol)
inet addr:10.0.7.1 P-t-P:10.0.0.14 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1
RX packets:685 errors:0 dropped:0 overruns:0 frame:0
TX packets:966 errors:2 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:274792 (274.7 KB) TX bytes:188548 (188.5 KB)

$ netstat -rn
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
10.0.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
93.ХХ.ХХ.ХХ 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
93.ХХ.ХХ.ХХ 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

вот этот адрес 93.ХХ.ХХ.ХХ у меня реальный от того сервера прилетел

не смог понять какой маршрут ему ввести правильным. попытка закончилась

sudo: unable to resolve host

это мне на любые 192.168.1.XX которые вручную перебрал в первой команде

затем соединение никуда не работало до тех пор, пока вручную отключил-включил eth0

сейчас такой вывод есть

$ netstat -rn
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

$ netstat -rn
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 10.0.0.14 255.0.0.0 UG 0 0 0 ppp0
10.0.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
93.хх.хх.хх 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
93.хх.хх.хх 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

и получается, что маршрутизация теперь верная, но это с того момента, пока я вручную эту пару команд введу и только после старта VPN

можно как-то это закрепить за VPN ?

(32) Как закрепить за VPN в Убунту — не знаю. Надо спрашивать на специализированных форумах. Но эти две строчки можно прописать в планировщике, чтобы они выполнялись каждую минуту. Для этого пишем «crontab -e», открывается редактор планировщика, добавляем в него строчки:

*/1 * * * * ip route change default via 192.168.1.1 dev eth0
*/1 * * * * ip route add 10.0.0.0/8 via 10.0.0.14 dev ppp0

(35) Спасибо!
Насчет привязки этого в ppp0 отдельно поищу дальше в сети. Для eth0 файл указывают какой сохранить, может для ppp0 тоже можно указывать сам уже найду.

(34) да вот при поднятии VPN там как-то по хитрому берет этот адрес. От сервера получает, судя по всему. Так и при первом старте RDP я на него внимательно смотрел — был создан еще и ключ.
Там все круто настроено, только от админа в выходные дни я не могу ничего узнать, к тому же у админа на сервере может быть только винда и что там в линукс происходит он может и не знать.

все. победил. пишу решение, вдруг кому пригодится.

Устанавливаем по инструкции от поставщика VPN такие какие там нужно адреса пароли явки 🙂
Инструкция будет у поставщиков универсальной и для винды, и для линукс.
Затем уже делаем то, что в винде регулируется просто флажком «использовать удаленный шлюз в локальной сети» (win8, win10)

1. из вывода ifconfig подсмотрим следующие строки
ppp0 Link encap:Протокол PPP (Point-to-Point Protocol)
inet addr:10.0.7.1 P-t-P:10.0.0.14 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1
тут нужная нам адресация открывается с inet addr:10.0.0.0
и идет она через шлюз P-t-P:10.0.0.14
ВАЖНО видим тут Metric:1 (я не сразу догадался где можно метрику найти, но тут она нашлась сама собой)

2. запускаем снова графическую морду для настроек VPN, переключаемся в ней на Параметры IPv4 и там входим в Маршруты
2.1 добавляем нужный нам маршрут, который запустит нас в VPN на ее локальные ресурсы
адрес: 10.0.0.0 маска: 255.0.0.0 шлюз: 10.0.0.14 и метрика: 1
(сейчас написал так, но не знаю, насколько критична маска или нет, т.к. внутри RDP я видел в сведениях о сетевом подключении маску 255.255.0.0)
2.2 ставим галку «Использовать это соединение только для ресурсов в этой сети»

3. после установки VPN соединения запускаем для проверки маршрутов команду netstat -rn и видим нужное нам решение
netstat -rn
Таблица маршрутизации ядра протокола IP
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 10.0.0.14 255.0.0.0 UG 0 0 0 ppp0
10.0.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
93.92.86.96 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
93.92.86.96 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector