Немножко о выборе Windows DNS сервера и еще заметка

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

Get-DnsClientServerAddress покажет список DNS серверов с их интерфейсом и метрикой (индексом). Как это ни странно, при выборе DNS сервера между несколькими сетевыми интерфейсами метрика играет не последнюю роль. Метрика устанавливается в автоматическом режиме по внутренней логике операционной системы и согласно ей интерфейс VPN имеет меньшие затраты нежели WiFi, а значит и предпочтительней.

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

Get-DnsClientServerAddress | where -Property AddressFamily -eq 2 | ft ElementName,Address,Name,EnabledDefault,EnabledState,RequestedState,TransitioningToState,SystemName,AccessContext,InterfaceIndex

Поэтому в некоторых случаях все запросы уходят только в VPN, а в некоторых наоборот. При этом отмечено, что для dns-запросов кроме nslookup имя резолвится корректно. 

Что нам это дает? Провайдер Citytelecom заменяет ip для имен из списка РКН на свою заглушку, а Windows на моем компьютере решил что VPN до офиса с этим провайдером имеет приоритет выше реального интерфейса и я находясь в 3000 км от офиса получаю заглушку провайдера в офисе О_О

И еще один момент, если снять галочку "Использовать основной шлюз в удаленной сети", то появляется галочка "Отключить добавление маршрута основанное на классе", раньше я не обращал внимания, пока случайно не наткнулся на видео про маршрутизацию в VPN и там этот вопрос был поднят. Благодаря этому видео я понял, почему два включенных VPN с выданными IP из сетей 10.30.5.0/24 и 10.10.10.0/24 конфликтуют друг с другом и не важно какая размерность сети указана, трафик будет уходить в интерфейс включенный последним (мои личные наблюдения). Так как согласно классу сеть 10.30.5.0/24 входит в сеть 10.0.0.0/8, если галочка стоит, то добавляется маршрут 10.0.0.0 255.0.0.0 10.30.5.3

И при включении второго VPN также добавляется маршрут основанный на классе:

Ну собственно и все что хотел сказать. Самое главное, именно из-за этого работает маршрутизация если адресация удаленной сети и сети VPN в одном классе (например сеть удаленная 10.20.0.0/24, а сеть VPN 10.30.5.0/24) без бубнов на большинстве протоколов VPN. Если же классовую маршрутизацию для указанного примера отключить, то протокол SSTP/L2TP точно потребуют ручного добавления маршрутов до удаленной сети, а вот IKEv2/OVPN могут пушить маршруты (отправлять с сервера).

пример отправки маршрута с сервера на клиента

Т.о. при планировании сети требуется учитывать и этот момент, т.к. у каждого VPN протокола есть свои плюсы и минусы, а реализация на разном оборудовании добавляет еще головной боли (mikrotik not support route push for ovpn).