Ziptar

>как это работает
Согласно модели OSI это работает. USB модем - обычно L2 (NDIS-адаптер) (хотя фактическая коммуникация по L3 - IP, NAT, все дела). Proxy - как правило подразумевается L7, хотя есть варианты L4

>можно ли как нибудь сделать так, что бы при использовании прокси компьютер думаю что это USB-модем, и работал без всяких прокси-настроек?
Нет, нельзя. Прокси не оперирует протоколами (в основном это IP), характерными для L3. А на L3 нет никакого представления о том, для чего его используют L4-7. VPN же, как раз таки, предназначен для работы на L3.
Можно лишь соорудить прокладку между целевым прокси и взаимодействием с операционной системой, реализующую L2-L3 взаимодействие (те же самые NDIS адаптеры передают привет - это и есть такая прокладка, по большому счёту, только в тех же USB 3g/lte модемах она используется несколько по-другому - в сторону L1 и L2 в сотовых сетях, а не в сторону L7) - но смысла в этом... только в определённых коммерческих целях, разве что. Не для персонального использования точно - мороки и человеко-часов много, толку мало.

Послушай, уважаемый, ты не тем занимаешься. Во-первых, интернет, на усреднённом роутере на базе лини, мало связан с доступом к роутеру и доступом роутера куда-либо. Цепочка forward не пересекается с цепочками input и output. Кроме того, само оперирование понятиями "входящие" и "исходящие" требует осознания того, к чему ты эти понятия применяешь - к пакетам, или к соединениям, потому что это разные вещи, и на разных роутерах эти разные вещи могут называться одинаково.
Что касается "можно ли заменить" - да, принципиально можно. Да, на большинстве роутеров можно. Нет, не на всех роутерах это можно сделать предусмотренным производителем путём. И интернет тут, как правило, вообще ни при чём. Но самое главное - это не нужно. Безопасности это не добавляет.

Можно отлавливать скриптом поднятие l2tp подключения и прописывать статику в настройки днс. Но я не уверен, что статически прописанные серверы имеют для микротика приоритет над динамическими.
В таком случае можно скриптом отлавливать поднятие l2tp подключения и включать правило для ридиректа запросов на 53/UDP на 8.8.8.8 например.

:if ([:len [/ppp active find name="имя l2tp подключения"]] > 0) do={
/ip firewall nat enable [find comment~"Часть коммента правила с редиректом"]
} else {
/ip firewall nat disable [find comment~"Часть коммента правила с редиректом"]
}
Ну и само правило на редирект создать с соответсвующем комментом, а скрипт запускать каждые 10 сек., предположим.
Как-то так, но это не точно.

Если вы говорите о конфликте шлюзов, то...
Метрики маршрутов в автоматическом режиме назначаются по последнему установленному соединению; при этом обновление dhcp по таймеру считается заново установленным соединением, поэтому могут возникнуть эксцессы при определённых обстоятельствах. (актуально для win7, другие ОС могут себя иначе вести)
Вручную можно настроить в свойствах ipv4 конкретного подключения.

Нормально разбивать на подсети, больше никак.

Эти машины просто напросто не находят DHCP сервер при очередной попытке обновления адреса.

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

Роутер 2 - просто мост?

А в чём, собственно? Порт на свиче в режим транка, или гибридный режим, для ip-телефона tagged vlan, для пк untagged
Там то особой разницы нет, как пк подключён, телефон просто мост создаёт.

Тут микротик советуют - предупреждаю: реализация ovpn оставляет желать на столько лучшего, что даже udp не поддерживает.

Вам зачем?

Напрямую - никак.
И Layer7 тут не помощник, т.к. DNS-запрос посылается только при первом обращении к ресурсу, всё остальное время (пока жив днс-кэш) софт работает с ip.

Можно лишь попытаться составить список доменных имён, обновлять периодически их ip-адреса на маршрутизаторе, составляя списки, и уже с этими списками работать. Для клиентов в локальной сети перехватывать через L7 запросы к DNS, и подменять на те адреса, что есть у роутера. Хотя стоит учитывать, что в случае использования клиентами DNSCrypt - перехватить не получится.
На микротиках реализуемо, хотя и нетривиально.

Другие без самоделкинства не реализовать, и все они локального действия.
Весь остающийся вывод: usb, poe, ssh.

Самый простой и наименее затратный вариант - всё же e-mail уведомления. С МТ на внутренний smtp-сервер, а с него уже с авторизацией и шифрованием на внешний почтовик - хотя бы и тот же gmail. Это если внутрикорпоративного почтовика нет, конечно.
UPD: я невнимательный. Почитал комменты. Ну, можно намутить коннект по ssh, дабы мт посылал команду на рассылку сообщения по корпоративному мессенджеру?... активировал лампочку на столе у босса?... что угодно, но всё равно это из разряда самоделкинства. Готовых решений, скорее всего, нет.

Завсисит от приложений. На уровне протоколов/портов можно разрулить фаерволом. Аутпостом, например.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.2:8080
iptables -A FORWARD -t eth0 -p tcp --dport 8080 -j ACCEPT
iptables -A FORWARD -s 10.8.0.2 -p tcp --sport 8080 -j ACCEPT

Должно работать, если ничего не напутал. С iptables общаюсь не то что бы часто.
А вообще: https://www.opennet.ru/docs/RUS/iptables/

P.S. форвардинг должен быть включён на обоих интерфейсах - то есть eth0 и tun/tap

Ясно-понятно.

1) CN сертификата сервера должно равняться его fqdn, или же ip
но это ладно.
2) Не знаю как в "родном" ovpn, но в микротиковской реализации овпн сервера есть 2 варианта подключения:
a. логин-пароль
b. сертификат И логин-пароль
вариант с только сертификатом отсутствует.

UPD: crl host задаётся жёстко ip-адресом, только винбокс об этом ни слова не говорит, и если указать fqdn - спокойно создаёт самоподписанный CA без crl. ><
deleted(ибо я лапоть и всё враки): И ладно, я был бы только рад, но в ROS клиентский сертификат невозможно привязать к пользователю + ROS'овский PKI не поддерживает автоматическое создание crl, не говоря уже об отсутствии места хранения этого crl для массового пользователя.
Что делает поддержку клиентских сертификатов, так скажем, менее полезной, чем хотелось бы, а смысл от клиентских сертификатов для каждого юзера вообще сводит к нулю.

Этот конфиг, во всяком случае, для домашнего использования, посмотрим как это будет в рабочей обстановке с WinSrv PKI и радиус-аутентификацией; но... позже.