Клієнт DNS over HTTPS (DoH)

DNS over HTTPS (DoH) — це протокол для виконання DNS-запитів через протокол HTTPS. Надає певні переваги в захисті DNS-запитів. Якщо звичайний запит по 53/udp доволі легко перехопити і проаналізувати через, наприклад, Wireshark то з запитом через HTTPS цей "фокус" стає не таким вже й тривіальним. Mikrotik дозволяє нам налаштувати DNS over HTTPS (DoH) з тими чи іншими службами, наприклад з Google або Cloudflare.

Завантажуємо та імпортуємо сертифікат:

/tool fetch url=https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
/certificate import file-name=DigiCertGlobalRootCA.crt.pem passphrase=""

Далі, в DHCP-клієнті вимикаємо отримання DNS-серверів, наприклад, від провайдера, а також видаляємо використання будь-яких користувацьких налаштувань щодо DNS-серверів:

/ip dns set servers=""
/ip dhcp-client set [ find ] use-peer-dns=no

Ну й налаштовуємо DNS over HTTPS (DoH) для Google:

/ip dns set use-doh-server=https://8.8.8.8/dns-query verify-doh-cert=yes

або Cloudflare:

/ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes

Після цього можна скинути наявний кеш і перевірити, що DNS over HTTPS (DoH) працює:

/ip dns cache flush
/ping meta.ua count=4
/ip dns cache print without-paging

ovpn-файл до статті "Налаштування OpenVPN-сервера на Mikrotik"

Вступ

Нещодавно в статті Налаштування OpenVPN-сервера на Mikrotik (метод 2) було наведено вміст ovpn-файла, для OpenVPN-клієнта Windows/Linux, в той самий час в статті Налаштування OpenVPN-сервера на Mikrotik було розглянуто лише налаштування OpenVPN-клієнта в RouterOS. Спробуємо виправити ситуацію.

Експорт сертифікатів

Нарешті ми налаштували OpenVPN-сервер на Mikrotik і тепер хочемо роздати нашим клієнтам ovpn-файл, щоб вони підключалися до сервера.

Експортуємо ca та клієнтський сертифікати. Тут все просто:

/certificate export-certificate ca file-name=ca-v1 type=pem 
/certificate export-certificate ovpn-muter file-name=ovpn-client-v1 type=pem export-passphrase="passphrase"

Створюємо ovpn-файл

client
dev tun
remote <ip address or dns name of the ovpn server> 1194 tcp
nobind
persist-key
persist-tun
remote-cert-tls server
data-ciphers AES-256-CBC
cipher AES-256-CBC
auth-user-pass
auth SHA1
redirect-gateway def1
verb 1
<ca>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ca-v1.crt
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ovpn-client-v1.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
вставляємо вміст з експортованого файла ovpn-client-v1.key
-----END ENCRYPTED PRIVATE KEY-----
</key>

Налаштування OpenVPN-сервера на Mikrotik (метод 2)

Вступ

Вже був розповідав як налаштувати OpenVPN-сервер на Mikrotik (назвемо його - метод 1). В тому методі ми налаштували сервер де організували з кожним клієнтом point-to-point канал і маршрутизували трафік. Але подекуди нам зустрічаються локальні мережі в яких працює специфічний софт, який "не любить" маршрутизацію і чи зовсім не працює з нею, чи працює лише після танців з бубном. В таких випадках нам зможе допомогти другий метод налаштування OpenVPN-сервера, коли клієнт входить безпосередньо в бродкаст домен (bridge-інтерфейс) локальної мережі.

Сертифікати

В цьому другому методі нам теж треба згенерувати сертифікати, але з іншими правами. Якщо генерувати сертифікати в тими правами, що були у попередньому методі, нічого не буде працювати. Це важливо.

Генеруємо корневий сертифікат нашого "сертифікаційного центру":

/certificate add name=ca-v2 country="UA" state="KY" locality="Locality" organization="Organization" unit="Unit" common-name="ca-v2" key-size=2048 days-valid=3650 key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign
/certificate sign ca-v2

Створюємо сертифікат та закритий ключ для OpenVPN-сервера:

/certificate add name=ovpn-server-v2 country="UA" state="KY" locality="Locality" organization="Organization" unit="OpenVPN-server-v2" common-name="ovpn-server-v2" key-size=2048 days-valid=3650 key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,tls-server
/certificate sign ovpn-server-v2 ca=ca-v2

Генеруємо клієнтський сертифікат:

/certificate add name=ovpn-client-v2 country="UA" state="KY" locality="Locality" organization="Organization" unit="OpenVPN-client-v2" common-name="ovpn-client-v2" key-size=2048 days-valid=3650 key-usage=tls-client
/certificate sign ovpn-client-v2 ca=ca-v2

Сервер

З сертифікатами поки закінчили, тепер налаштуємо сам OpenVPN-сервер.

/ppp profile add bridge=bridge bridge-learning=yes local-address=192.168.0.1 name=profile-ovpn remote-address=default-dhcp use-ipv6=no
/interface ovpn-server server set auth=sha1 certificate=OVPN-server cipher=aes256 default-profile=profile-ovpn enabled=yes mode=ethernet require-client-certificate=yes

Тут важливо розуміти що на відміну від метода 1 тут ми вводимо клієнтів безпосередньо в бродкаст домен (bridge-інтерфейс) локальної мережі, відповідно для сервера вказуємо mode=ethernet, а в профілі використовуємо наявний для локальної мережі dhcp-діапазон адрес і локальним адресом вказуємо адресу на bridge-інтерфейсі.

Далі додаємо користувачів

/ppp secret add name=USERNAME password=PASSWORD profile=ovpn service=ovpn

та не забуваємо відкрити OpenVPN-сервер для доступу:

/ip firewall filter add action=accept chain=input dst-port=1194 protocol=tcp

Клієнт

Тепер давайте створимо ovpn-файл для OpenVPN-клієнта. Спочатку експортуємо ca та клієнтський сертифікати. Тут все просто:

/certificate export-certificate ca-v2 file-name=ca-v2 type=pem 
/certificate export-certificate ovpn-client-v2 file-name=ovpn-client-v2 type=pem export-passphrase="passphrase"

Важливо! Для клієнтського сертифіката необхіжно вказати бодай якусь passphrase, інакше не буде експортовано закритий ключ, а він нам необхідний.

Сам вміст ovpn-файла може бути приблизно таким.

client.ovpn:

client
dev tap
proto tcp
remote <ip address or dns name of the ovpn server> 1194
nobind
persist-key
persist-tun
remote-cert-tls server
data-ciphers AES-256-CBC
cipher AES-256-CBC
auth-user-pass
keepalive 10 120
verb 1
auth SHA1
<ca>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ca-v2.crt
-----END CERTIFICATE-----
</ca>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ovpn-client-v2.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
вставляємо вміст з експортованого файла ovpn-client-v2.key
-----END ENCRYPTED PRIVATE KEY-----
</key>

Якщо OpenVPN-клієнт для Windows дозволяє запам'ятати введену passphrase та ім'я та пароль користувача то для Linux такої можливості немає, але в сам ovpn-файл можна додати опції:

auth-user-pass auth.cfg
askpass store.pass

а в самих файлах розмістити, відповідно, ім'я користувача з паролем та passphrase.

auth.cfg:

USERNAME
PASSWORD

store.pass:

passphrase

Ось і все, щодо метода 2.

Налаштування wifiwave2 на hAP ax² (C52iG-5HaxD2HaxD).

Так вже сталося, що потрапив мені в руки Mikrotik hAP ax². Перша, й характерна, відмінність, від того до чого звик, це WiFi 6 і пакет wifiwave2. Що хочеться сказати: все, що знали про налаштування WiFi на Mikrotik до wifiwave2 — забудьте! Все, що знали про налаштування CAPsMAN на Mikrotik до wifiwave2 — забудьте!

Одразу хочу сказати, що не стану тут пересказувати статтю WifiWave2 з офіційного джерела Mikrotik-а. Стаття гарна і висвічує майже всі аспекти. Я просто розповім про свої митарства і про позитивний досвід.

Спочатку, так як залізо було новим, спробував подивитися, що та як налаштовує Quick Set і, як це зазвичай буває, мені це не дуже сподобалося. Ні, звісно, що працювати якось буде, але… ну не те.

Не помітив улюбленого пункту меню CAPsMAN… Хм… Пішов до меню Wireless і одразу побачив схожість вкладок до меню CAPsMAN попередніх версій. Ну, думаю, супер! Адже CAPsMAN мені дуже подобається, особливо коли мова йдре про масштабування wifi-мережі. Але не все так сталося як гадалося. Функціонал попередніх версій CAPsMAN подекуди докорінно відрізнявся від того, що побачив тут. Окрім того, тут, назвемо так, "гібрідний функціонал". Тобто можна налаштовувати через меню Wireless як безпосередньо wifi-інтерфейси так і задіяти для того самого CAPsMAN.

Так як треба було все налаштувати швидко то налаштував через winbox два інтерфейси у вкладці WiFi Wawe 2. Запрацювало. Добре. Але… але не подобалося, от якось не те, хотілося, прямо кортіло, задіяти функціонал CAPsMAN

Треба сказати, що грішив від самого початку на версію прошивки. Factory Firmware була 7.6, а на той час як hAP ax² потрапив до рук, то актуальною stable-версією була 7.9. Раз підхід. Два підхід. Ну не виходить кам'яна квітка… Повернувся до налаштувань WiFi Wawe 2 без CAPsMAN і "забув".

Все змінилося, коли вийшла stable-версія прошивки 7.10.2, до якої прямо було написано

wifiwave2 - fixed interface hangs on IPQ6010-based boards (introduced in v7.9)

Далі без лірики. Далі практика.

Оновлюємося до прошивки не меншої за 7.10.2, щоб успішно задіяти функціонал CAPsMAN пакету wifiwave2.

Відкриваємо консоль. І робимо дві магічні команди, бо без них подальші дії будуть схожі на шаманські танці з бубном, але результату буде мало. Так от, робимо:

/interface/wifiwave2/remove [ find ]
/interface/wifiwave2/reset [ find ]

таким чином ми видаляємо всі наявні "підлеглі" wifi-інтерфейси і скидаємо налаштування щодо "основних".

Після цього все стає не просто, а занадто просто:

/interface wifiwave2 channel
add disabled=no name=channel2 width=20/40mhz-Ce
add disabled=no name=channel5 skip-dfs-channels=disabled
/interface wifiwave2 datapath
add bridge=bridge disabled=no interface-list=LAN name=datapath1
/interface wifiwave2 security
add authentication-types=wpa2-psk,wpa3-psk passphrase=p@ssw0rd disabled=no group-encryption=ccmp name=sec1
/interface wifiwave2 configuration
add channel=channel5 country="United States" datapath=datapath1 disabled=no name=5ghz security=sec1 ssid=SampleWiFi tx-power=32
add channel=channel2 country=Ukraine datapath=datapath1 disabled=no name=2ghz security=sec1 ssid=SampleWiFi tx-power=32
add channel=channel5 country="United States" datapath=datapath1 disabled=no name=5ghz.5 security=sec1 ssid=SampleWiFi.5
add channel=channel2 country=Ukraine datapath=datapath1 disabled=no name=2ghz.2 security=sec1 ssid=SampleWiFi.2
/interface wifiwave2 cap
set discovery-interfaces=bridge enabled=yes
/interface wifiwave2 capsman
set enabled=yes interfaces=bridge upgrade-policy=none
/interface wifiwave2 provisioning
add action=create-dynamic-enabled disabled=no master-configuration=5ghz name-format=wifi1-5G-%I slave-configurations=5ghz.5 supported-bands=5ghz-n,5ghz-a,5ghz-ac,5ghz-ax
add action=create-dynamic-enabled disabled=no master-configuration=2ghz name-format=wifi2-2G-%I slave-configurations=2ghz.2 supported-bands=2ghz-n,2ghz-g,2ghz-ax

Ну от в принципі і все. Після цього починає нормально працювати CAPsMAN з пакета wifiwave2. Ну а всі інші налаштування — на власний розсуд. Не забуваємо дати команду:

/interface/wifiwave2/radio/provision [ find ]

Також зверну увагу, про що написано й в документації WifiWave2, що WifiWave2 CAPsMAN може керувати лише інтерфейсами WifiWave2, а WifiWave2 CAP може приєднуватися лише до WifiWave2 CAPsMAN, так само, CAPsMAN попередніх версій підтримує лише не-WifiWave2 пристрої.

Окреме зауваження щодо country. Для 5ГГц діапазона обрано United States. Чому? Скоріш за все за звичкою. Бо колись, коли тільки почали з'являтися 5ГГц-пристрої, iPhone погано "дружив" з  Mikrotik-ами на цьому діапазоні, ащо країна відрізнялася від United States. Час плине, можливо зараз все змінилося, але звичка залишилася.

Ще раз скажу, що документація щодо налаштувань WifiWave2 з офіційного джерела Mikrotik-а заслуговує на увагу, як і всі інші статті. Якщо у вас щось не виходить то це не тому, що Mikrotik такий прямо ну поганий і кривий, можливо просто в дзеркалі щось не так. Нічого не маю проти інших вендорів, але за критеріями ціна-якість-можливості, вважаю, що Mikrotik це всюдихід, який можна налаштувати майже під будь-які потреби… хіба що HTCPCP не підтримує ;)

Як з консолі перевірити термін дії SSL-сертифікату на ресурсі (наприклад https)

$ echo "GET / " | openssl s_client -servername att.privatbank.ua -connect att.privatbank.ua:443 | openssl x509 -noout -dates
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, CN = Amazon RSA 2048 M01
verify return:1
depth=0 CN = oteroprod.lnt.cl
verify return:1
DONE
notBefore=May 30 00:00:00 2023 GMT
notAfter=Jun 28 23:59:59 2024 GMT

Ось ці строчки і показують з якого і по який час сертифікат буде дійсним:

notBefore=May 30 00:00:00 2023 GMT
notAfter=Jun 28 23:59:59 2024 GMT

В статті Налаштування OpenVPN-сервера на Mikrotik було наведено скрипт, який оновлює інформацію щодо публічних ntp-серверів, з яких Mikrotik може брати інформацію про точний час. Але справа в тому, що то для RouterOS гілки 6.x, а от для 7.x його доведеться трохи переписати:

/system script
add dont-require-permissions=no name=NTPupdate owner=olden policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":global SYSname [/system identity get name];\r\
    \n\r\
    \n# NTP pools to use (check www.pool.ntp.org)\r\
    \n:global SYSntpa \"0.ua.pool.ntp.org\";\r\
    \n:global SYSntpb \"1.ua.pool.ntp.org\";\r\
    \n\r\
    \nping \$SYSntpa count=2 do-not-fragment;\r\
    \nping \$SYSntpb count=2 do-not-fragment;\r\
    \n\r\
    \n# Resolve the two ntp pool hostnames\r\
    \n:local ntpipa [:resolve \$SYSntpa];\r\
    \n:local ntpipb [:resolve \$SYSntpb];\r\
    \n\r\
    \n# Get the current settings\r\
    \n:local ntpcura [/system/ntp/client/servers/get 0];\r\
    \n:local ntpcurb [/system/ntp/client/servers/get 1];\r\
    \n\r\
    \n# Define a variable so we know if anything's changed.\r\
    \n:local changea 0;\r\
    \n:local changeb 0;\r\
    \n\r\
    \n# Change primary if required\r\
    \n:if (\$ntpipa != \$ntpcura) do={\r\
    \n    :put (\"Old: \" . \$ntpcura . \" New: \" . \$ntpipa);\r\
    \n    :put \"Changing primary NTP\";\r\
    \n    /system/ntp/client/servers/set 0 address=\"\$ntpipa\";\r\
    \n    :set changea 1;\r\
    \n    }\r\
    \n\r\
    \n# Change secondary if required\r\
    \n:if (\$ntpipb != \$ntpcurb) do={\r\
    \n    :put (\"Old: \" . \$ntpcurb . \" New: \" . \$ntpipb);\r\
    \n    :put \"Changing secondary NTP\";\r\
    \n    /system/ntp/client/servers/set 1 address=\"\$ntpipb\";\r\
    \n    :set changeb 1;\r\
    \n    }\r\
    \n\r\
    \n:if (\$changea=1 or \$changeb=1) do={\r\
    \n    /system ntp client set enabled=\"no\"\r\
    \n    /ip dhcp-server network set [ find comment=\"dhcp-server\" ] ntp-server=\"192.168.31.1,\$ntpipa,\$ntpipb\"\r\
    \n    /system ntp client set enabled=\"yes\"\r\
    \n    }\r\
    \n"

Ну й не забуваємо його періодично викликати, для актуалізації інформації по ip-адресах ntp-серверів:

/system scheduler
add comment="Check and set NTP servers" interval=12h name=NTPupdate on-event="/system script run NTPupdate\r\
    \n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=jan/01/1970 start-time=00:00:00

winget

 Настільки наскільки я не люблю Windows, настільки сьогодні був вражений інструментом winget - сподобалося ;)

Знадобилося швиденько, на нову систему проінстальованого Windwos 10, встановити Google Chrome, PuTTY, WinSCP та деякі інші додатки. Що ж, це стало зручно робити, не витрачаючи час на пошуки ресурсів через Google, достатньо простого cmd.

Вводимо:

winget search putty

Бачимо id і далі просто:

winget install --id=PuTTY.PuTTY -e

Аналогічно

winget install --id=WinSCP.WinSCP -e
winget install --id=TeraTermProject.teraterm -e
winget install --id=Mozilla.Firefox -e
winget install --id=eloston.ungoogled-chromium -e
winget install --id=Google.Chrome -e --force
winget install --id=Microsoft.WindowsTerminal -e
winget install --id=Debian.Debian -e

Я у захваті. Сподобалося ;)