VPN-подключение: динамический маршрут, корп. DNS | GRE-туннель

[The_Immortal]

Приветствую!

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

Итак, на работе имеется LAN-сеть (192.168.32.0/25) и VPN для выхода в Интернет (192.168.33.0/25). Внешний IP VPN-сервера: 91.215.218.123, он же DNS-сервер.
Дома всё тривиально: 192.168.1.0/24; внешние IP белые, динамические.

Необходимо организовать соединение между домашней и корпоративной сетями, но при этом:
а) без задействования шлюза корп. сети в виде общегоосновного;
б) DNS-сервер должен быть один, который бы резолвил имена машин корп. сети, так и глобальные имена.

I. Маршрутизация.
Тут всё стандартно. На домашней Win-машине (192.168.1.20) задал постоянный маршрут для доступа к машинам корп. сети:route add 192.168.32.0 MASK 255.255.255.128 192.168.33.85 IF 38 METRIC 1 -p - где "IF 38" (192.168.33.85) - IP VPN'а.
В итоге в таблице имею следующее:===========================================================================
Список интерфейсов
38...........................VPN
11...f4 d1 08 2b 64 ca ......Intel(R) Wireless-AC 9462
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.20 50
91.215.218.123 255.255.255.255 192.168.1.1 192.168.1.20 51 // нафег не нужен
192.168.1.0 255.255.255.0 On-link 192.168.1.20 306
192.168.1.20 255.255.255.255 On-link 192.168.1.20 306
192.168.1.255 255.255.255.255 On-link 192.168.1.20 306
192.168.32.0 255.255.255.128 On-link 192.168.33.85 36 // добавленный маршрут
192.168.32.127 255.255.255.255 On-link 192.168.33.85 291
192.168.33.85 255.255.255.255 On-link 192.168.33.85 291
224.0.0.0 240.0.0.0 On-link 192.168.1.20 306
224.0.0.0 240.0.0.0 On-link 192.168.33.85 291
255.255.255.255 255.255.255.255 On-link 192.168.1.20 306
255.255.255.255 255.255.255.255 On-link 192.168.33.85 291
===========================================================================
Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
192.168.32.0 255.255.255.128 192.168.33.85 1
===========================================================================После этого я могу обращаться по IP к машинам корп. сети.
Однако тут возникает два нюанса:

1. После поднятия VPN'а автоматически создается совсем не нужный маршрут: "91.215.218.123 255.255.255.255 192.168.1.1 192.168.1.20 51" - каким образом его также автоматически удалять?
2. Сетевой администратор сообщил, что решение из разряда через одно место и что надо создавать маршрут динамически при изменении соответствующих интерфейсов. Действительно ли так правильнее? Попытался найти в гугле решение, но не обнаружил. Подскажите, пожалуйста, как это сделать: каким-либо скриптом или есть встроенные решения?


II. DNS-сервер.
"DNS-сервер должен быть один, который бы резолвил имена машин корп. сети, так и глобальные имена." - для этого необходимо задействовать корп. DNS-сервер 91.215.218.123, но извне он недоступен.
Я решил обойти эту проблему следующим образом. Добавил в настройки интерфейса клиента (192.168.1.20) два DNS:
- предпочитаемый: 91.215.218.123 (корп. сеть);
- альтернативный: 192.168.1.1. (домашняя сеть).
И также добавил следующий постоянный маршрут:route add 91.215.218.123 MASK 255.255.255.255 192.168.32.1 IF 38 METRIC 1 -pВ итоге таблица следующая:Список интерфейсов
38...........................VPN
11...f4 d1 08 2b 64 ca ......Intel(R) Wireless-AC 9462
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.20 50
91.215.218.123 255.255.255.255 192.168.1.1 192.168.1.20 51 // по-прежнему нафег не нужен
91.215.218.123 255.255.255.255 192.168.32.1 192.168.33.85 36 // добавленный маршрут
192.168.1.0 255.255.255.0 On-link 192.168.1.20 306
192.168.1.20 255.255.255.255 On-link 192.168.1.20 306
192.168.1.255 255.255.255.255 On-link 192.168.1.20 306
192.168.32.0 255.255.255.128 On-link 192.168.33.85 36
192.168.32.127 255.255.255.255 On-link 192.168.33.85 291
192.168.33.85 255.255.255.255 On-link 192.168.33.85 291
224.0.0.0 240.0.0.0 On-link 192.168.1.20 306
224.0.0.0 240.0.0.0 On-link 192.168.33.85 291
255.255.255.255 255.255.255.255 On-link 192.168.1.20 306
255.255.255.255 255.255.255.255 On-link 192.168.33.85 291
===========================================================================
Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
192.168.32.0 255.255.255.128 192.168.33.85 1
91.215.218.123 255.255.255.255 192.168.32.1 1
===========================================================================Соответственно, когда поднят VPN, то резолвинг всех имен идет через корп. DNS-сервер 91.215.218.123. Когда VPN тухнет, то вступает альтернативный домашний DNS-сервер 192.168.1.1.
Однако и здесь профессиональный сетевик меня тормазнул, сообщив, что таким макаром будет создаваться задержка.
Поэтому прошу подсказать вас как решить вопрос с DNS-сервером в моем случае по уму?


III. Альтернативное решение - GRE-туннель.
А вообще указанный выше товарищ порекомендовал поднять постоянный GRE-туннель на централизованном устройстве (роутере). Однако я немного в ступоре от данной рекомендации.
Во-первых, насколько я понял, GRE-тунель предполагает использование на двух концах статические IP-адреса. У меня же дома "внешние IP белые, динамические". Конечно, есть DDNS, но он вроде имя в организации GRE-туннеля неуместно.
Во-вторых, когда я уточнил, что будучи в разъездах в качестве роутера у меня будет использоваться Android-телефон, но на это я получил ответ, что под Android никаких проблем организовать GRE-туннель нет. Однако там та же ситуация: динамические IP-адреса и, более того, они ещё сидят за провайдерским NAT'ом.

Вопросы тут такие:
1. Возможно ли организовать GRE-туннель с белым динамическим IP-адресом на одном из концов?
2. Возможно ли организовать GRE-туннель с серым IP-адресом на одном из концов?
3. Освобождает ли GRE-туннель от прописывания такого же постоянного маршрута, который был указан в вопросе I?


Благодарю!!!

[Busla]

После поднятия VPN'а автоматически создается совсем не нужный маршрут »
нужный
если вы этого не понимаете, то не понимаете как работает и зачем нужна маршрутизация
Сетевой администратор сообщил, что <..> Действительно ли так правильнее?»
действительно, доверия Васе Пупкину с форума больше, чем отвечающему за это сетевику

читайте книги - так у вас сложится целостное представление о сетях

Альтернативное решение - GRE-туннель. »
альтернативное чему?

каким-либо скриптом или есть встроенные решения? »
встроенные куда?

[The_Immortal]

Busla,
нужный »
"Нужность" проверяется на практике. На практике отсутствие данного маршрута показало, что он не влияет на работоспособность ни коим образом.

действительно, доверия Васе Пупкину с форума больше, чем отвечающему за это сетевику »
Во-первых, Васе предоставили достаточно входной информации. Если же намек на то, что всё настолько индивидуально, то тогда к чему ссылка на чтение общей литературы?
Во-вторых, сетевик больше по этому поводу ничего не скажет, ему не до земных запросов.

альтернативное чему? »Альтернативно настройкам на клиенте:
поднять постоянный GRE-туннель на централизованном устройстве (роутере) »

встроенные куда? »В данном случае в ОС.

[Busla]

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

[The_Immortal]

Busla, вы же не пишете какими средствами VPN организуете »В смысле VPN-сервер как организуется? Без понятия, т.к. я всего лишь клиент.

это багофича конкретной реализации »Этот маршрут необходим только в том случае, если основной шлюз клиента задействован будет через корпоративную сеть, что мне не надо по условию задачи:
без задействования шлюза корп. сети в виде общего; »

[Jula0071]

Без понятия, т.к. я всего лишь клиент. »
Но ведь вы наверное в курсе, что существует с пяток современных технологий, у каждой десятки вариантов исполнения и сотни вендорских реализаций? Даже не хочу вникать, например тот же IPSec можно настроить десятками способов - PSK или сертификат, с десяток шифров и хешей, применять PFS или нет, несколько туннельных протоколов, и тд и тп.

Либо вы это всё согласуете с админом, либо сосёте болт.

[Busla]

Этот маршрут необходим только в том случае, если основной шлюз клиента задействован будет через корпоративную сеть, что мне не надо по условию задачи:
Цитата The_Immortal:
без задействования шлюза корп. сети в виде общего; » »
ах вот про что эта фраза :-)
чем больше терминов вы придумываете, тем меньше вас понимают

[The_Immortal]

Jula0071, существует с пяток современных технологий, у каждой десятки вариантов исполнения и сотни вендорских реализаций »
Сиё применимо и к PPTP/GRE?

Busla, чем больше терминов вы придумываете, тем меньше вас понимают »о-с-н-о-в-н-о-й (учту). Но как-то Вы единственный такой непонимающий оказались-то ;)
И по поводу:
нужный»ибагофича конкретной реализации»ине понимаете как работает и зачем нужна маршрутизация »- понимающий подчеркнутые вещи точно не написал бы. Точнее Вы опять-таки единственный, кто так категорично среагировал ;)
Поэтому будьте любезны, поясните, пожалуйста, необходимость того маршрута (при отключенной на интерфейсе опции "Использовать основной шлюз в удаленной сети"), иначе книжки будем вдвоем изучать! :)

[Jula0071]

Сиё применимо и к PPTP/GRE? »
Неа. Оно вымерло (окей, должно вымереть) по причине слабости шифрования для современных мощностей. Это уже не современные технологии.

[The_Immortal]

Jula0071, ну дык выше монолог (по сути) вокруг этих динозавров и происходит.

[Busla]

Но как-то Вы единственный такой непонимающий оказались-то »
нет, я оказался единственным, кто с вами общается. Л - логика!

- понимающий подчеркнутые вещи точно не написал бы. Точнее Вы опять-таки единственный, кто так категорично среагировал
Поэтому будьте любезны, поясните, пожалуйста, необходимость того маршрута (при отключенной на интерфейсе опции "Использовать основной шлюз в удаленной сети"), иначе книжки будем вдвоем изучать! »
и снова странная логика
ваше "думал одно, написал другое, исправил на третье" с изучением мной книг никак не связано
без задействования шлюза корп. сети в виде общего »
это звучит как требование/описание офисной/серверной стороны, что сервер vpn не пользуется корпоративным шлюзом в инет
а вовсе не как описание галки "Использовать основной шлюз в удаленной сети"

[The_Immortal]

Busla, нет, я оказался единственным, кто с вами общается »
Ну да, единственный, если не брать ещё с десяток человек на других форумах, которые действительно пытаются помочь разобраться в проблеме, а не разводят пустую полемику.
это звучит как требование/описание офисной/серверной стороны, что сервер vpn не пользуется корпоративным шлюзом в инет
а вовсе не как описание галки "Использовать основной шлюз в удаленной сети" »Это звучит как д-демагогия!

Не понимаю смысла такого "вхождения" в тему. Бестолково потыкать носом в определения?