Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

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

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare :)

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

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

Если посмотреть на эту схему, то от нее пахнет легкими наркотиками. Настаиваю на том, что здесь можно назвать минимум две позиции, где есть существенный недочет. Можете попробовать испытать вопросы на коллегах :)

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

1. Указан просто гигантский разбег по адресам, с таким успехом можно было бы зарядить весь трафик в тоннель. А это не всегда целесообразно и необходимо, не говоря уже про трафик и нагрузку. Отсюда может выйти подпунктом дополнение — поленились собрать IP-адреса сервиса и сделать маршруты по ним или же поленились использовать L7.

2. Использование имени вместо адреса в шлюзе. Оно и так работает, конечно, но в этом место в случае реконнекта или изменений можно найти приключений, маршруты просто перестанут работать.

Появилась задача — сделать автоматическое подключение и переподключение к VPN пользователей, чтобы у них был доступ к определенному внутреннему ресурсу. VPN не наш, ресурс тоже не наш. Конечно проще всего было подключать одного пользователя и всем остальным пользователям при помощи маршрутизации отдавать тот самый заветный ресурс. Осталось решить, как быть с остальными пользователями, которые должны раз в определенный период времени показывать сетевую активность на VPN, чтобы избежать блокировки.

Идея в том, чтобы по списку подключать пользователя с учетом его логина и пароля. Далее держать его какое-то время на линии и благополучно отключать. Нам дан Cisco AnyConnect для решения задачи и сначала нужно будет разобраться с cli. Оказалось, что работа с cli и из командной строки различаются у этого клиента от версии к версии, потому далеко не все советы и руководства сработали. Для версии 4.1.х подошел вот такой вариант:

set FILE=C:\Temp\tmp.txt
echo connect vpn.server.ru> %FILE%
echo clientusername>> %FILE%
echo clientpassword>> %FILE%
"C:\Program Files\Cisco\Cisco AnyConnect Secure Mobility Client\vpncli.exe" -s < %FILE%

Осталось только сделать красиво:

• показывать дату и время при соединении;
• писать в лог дату и время соединения и отключения;
• временные интервалы отсчитываем «ping localhost -n 20 >nul»;

Листинг — https://sku.ovh/?03e14b7bab3c5264#7+ocEkLcKGOjqlmJyBVDtDgEYZXMsVr4EBldB3OZat8=