Chain INPUT (policy ACCEPT 3222 packets, 4206K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 50 packets, 3294 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- wlan0 eth0 50.1.1.0/24 0.0.0.0/0 ctstate NEW
5060 4168K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 2429 packets, 226K bytes)
pkts bytes target prot opt in out source destination
iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 89 packets, 9523 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 44 packets, 6377 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 30 packets, 2122 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
54 3653 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0
ip ro
10.10.10.0/24 dev wlan0 proto kernel scope link src 10.10.10.82 metric 9
*.*.*.* via 10.10.10.200 dev wlan0 src 10.10.10.82
50.1.1.0/24 dev eth0 proto kernel scope link src 50.1.1.1
192.168.2.1 dev ppp12 proto kernel scope link src 192.168.2.252
Да, в итоге в профиле был. Есть такие параметры у микрота в "PPP - Profiles" лежат два провиля default и default-encryption. В первом все было по заводу, а вот во втором уже добавлены пул и IP. Но в настройках secret'а (учетки для подключения) был указан профиль default, но похоже когда при конекте система опрашивает настройки и не находит нужных записей про адреса в профиле, она по умолчанию подгружает профиль default-encryption. Я попробовал его изуродовать для проверки, и пере подключил соединение PPP и естественно все сломалось. Так что, каким-то образом при определенных других настройках (или условиях) микротик использует профиль default-encryption по умолчанию, даже если он не указан явно.
Вообще склоняюсь к тому, что Alexey Dmitriev прав, все было реализовано с помощью parent. В общем по порядку есть две закрытых сторонних сети, в них проброшен доступ через железку VipNet координатор. В конторе есть стойка в ней пару серверов с гипервизорами. На одном из них вертится виртулка с debian и squid - к ним есть доступ админа. На втором гипервизоре есть еще две виртуальных машины, какая именно прокся на них поднята, я не знаю, туда доступа нет. С этих двух виртуалок трафик заворачивается через VipNet в закрытые сети. На PC пользователя прописана прокси конторы на сквиде которая. Прокся конторы имеет два списка сайтов по одному на каждую закрытую сеть соответственно, и так-же пропускает все остальные запросы в интернет. И когда юзер пишет в браузере 1с.gemor.net и этот домен принадлежит к серверу из допустим первой закрытой сети, тогда сквид заворачивает запрос на виртуальную машину, которая проксирует в ту сеть. И это работало даже с https адресами. Я теперь в другой конторе работаю, и доступа к той проксе нет, а нужно настроить нечто подобное.
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 50 packets, 3294 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- wlan0 eth0 50.1.1.0/24 0.0.0.0/0 ctstate NEW
5060 4168K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 2429 packets, 226K bytes)
pkts bytes target prot opt in out source destination
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 44 packets, 6377 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 30 packets, 2122 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
54 3653 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0
*.*.*.* via 10.10.10.200 dev wlan0 src 10.10.10.82
50.1.1.0/24 dev eth0 proto kernel scope link src 50.1.1.1
192.168.2.1 dev ppp12 proto kernel scope link src 192.168.2.252
netstat не установлен.