krosh

Если 192.168.1.1 это другой хост - замените INPUT на FORWARD. Все, что за пределами локального хоста, фильтруется в цепочке FORWARD.

Если 192.168.1.1 та же самая машина, то --dport 22 -> --dport 2222 в цепочке INPUT Только в этом случае не ясно, зачем использовать iptables, когда порт в настройках можно сменить.

iptables-save > tmp.save
sed -i 's/AAA(рандомное число)AAA/AAAA(нужное число)AAA/g' tmp.save
iptables-restore < tmp.save

Вы хотите в сетях разобраться или работать?

Если работать и больше ничего. Начните с https://www.whonix.org/. Там есть гейтвей и воркстейшен. Простая инструкция. Потом подпимите впн-клиента на гейтвее, как на обычном линуксе и все будет работать.

Если разобраться.

1. Делаем 2 ВМ: Шлюз, вПК. В настройках вирт. адаптера объединяем их в один сегмент локальной сети. Шлюз - 2 адаптера: первый - внешний пусть пока будет НАТ или мост, если у вас есть домашняя сеть с роутером; второй - локальный, там указываете имя сегмента вирт. локальной сети. И Виртуалбокс и ВМВарь это умеют.

2. Настройте Шлюз как обычно, чтобы он пускал в сеть вПК. Это класическая тема, ищите мануалы в сети snat + forwarding. Как настроите и проверите, можно дальше двигаться.

3. На Шлюзе настраивайте впн-клиент до внешнего впн-сервера. Проверяте чтобы локально работало через впн-сервер и дефолтовый маршрут был на впн-сервер. Логично, что тогда и вПК будет ходить в инет также. Ему-то пофиг, что там с трафиком после того, как он отправил его своему дефолтовому гейтвею.

4. Научиться контролировать статус соединения, чтобы не было утечки, когда впн на Шлюзе не работает. И запросы к ДНС или на Шлюзе обрабатывались, или через впн шли.

5. И почему Дебиан 9.9? Берите уже 10-ку.

Весь трафик впн-сервера проходит через цепочку FORWARD, там занимайтесь фильтрацией. В этом контексте он становится маршрутизатором, а на эту тему достаточно материала в поиске. Предполагая, что tun0 - интерфейс для впн-клиентов, а eth0 - в интернет, то можно начать со следующих правил.

iptables -P FORWARD DROP
iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -m comment --comment "РАЗРЕШЕНО Установленные соединения" -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.0.100 -p udp -m udp --dport 53 -m comment --comment "РАЗРЕШЕНО DNS/udp для 192.168.0.100" -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.0.100 -m conntrack --ctstate NEW -m comment --comment "РАЗРЕШЕНО Интернет для 192.168.0.100" -j ACCEPT

Возможно правило про ДНС лишнее, не помню как OpenVPN работает с днс-запросами. Попробуйте для начала вовсе без него.

Суть REDSOCKS проксировать весь трафик, а не только определенный - 80 порт, как у вас.

Почитайте: Как раздать интернет на вторую сетевую карту? и Настройка Bind в паре с Redsocks?

Если это не помогает, то в чем же вопрос?

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

Обмен трафиком в сегменте сети происходит по протоколу Ethernet, поиск хостов - ARP. Трафик адресуется напрямую хосту используя mac-адрес, а не ip-адрес. Поэтому трафик между хостами локальной сети а) просто не доходит до роутера, т.к. не адресуется ему, т.к. при отправке выставляется mac-адрес хоста назначения - днс-сервера. Роутер тоже получает этот пакет, но т.к. mac-адрес не совпадает, он его отбрасывает (поэтому есть еще неразборчивый режим - Promiscuous mode, который позволяет захватывать любой трафик, но это не наш случай) и б) никакие правила фильтрации не используются (можете проверить полностью заблокировав цепочку FORWARD).

Вы пробовали на хосте 192.168.1.22 менять настройки днс-сервера?
Попробуйте отправить запрос напрямую, например так:
nslookup ya.ru 1.1.1.1
nmap -p U:53 192.168.1.11

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

У вас маршрутизатор или рабочая станция/рядовой сервер? Примем ситуацию с хостом-клиентом.

Меняйте маршрут по умолчанию после того, как будет поднят впн-туннель. В некоторых клиентах можно сразу в конфиг это прописать, или напишите отдельный скрипт с ip route add, который будет запускаться при старте впн-туннеля. Можно или default gw менять, либо первой строчкой ставить доступ в сеть 0.0.0.0/0 через интерфейс впн-туннеля.

Пользуйтесь цепочкой FORWARD для фильтрации проходящего мимо трафика.

Не знаю, что у вас там сейчас, но правильное решение должно содержать такие правила:

iptables -P FORWARD DROP
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -m comment --comment "РАЗРЕШЕНО Установленные соединения" -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -o eth0 -m comment --comment "РАЗРЕШЕНО Локальная сеть, основной канал" -j ACCEPT
iptables -A FORWARD -s 192.168.0.101 -o rth1 -m comment --comment "РАЗРЕШЕНО Человек первый хороший, резервный канал" -j ACCEPT
iptables -A FORWARD -s 192.168.0.102 -o rth1 -m comment --comment "РАЗРЕШЕНО Человек второй хороший, резервный канал" -j ACCEPT

1. DNAT iptables, как написали выше. И про обратные правила SNAT и в FORWARD не забудьте.

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

Запрет трафика с одного на другой интерфейс:
iptables -A FORWARD -o tun0 -i tun2 -j REJECT

Если надо запретить клиенту идти на другой впн-сервер:

iptables -A FORWARD -s 10.10.0.0/24 -i tun2 -j REJECT

Или просто отключите форвардинг на сервере:
sysctl -w net.ipv4.ip_forward=0или в /etc/sysctl.conf

SMB can run on top of the session (and lower) network layers in several ways:

Directly over TCP, port 445;[5]
Via the NetBIOS API, which in turn can run on several transports:[6]
On UDP ports 137, 138 & TCP ports 137, 139 (NetBIOS over TCP/IP);
On several legacy protocols such as NBF, IPX/SPX.

https://en.wikipedia.org/wiki/Server_Message_Block

Я бы начал с такого набора:

iptables -t nat -A PREROUTING -p udp --dport 137 -j REDIRECT --to-port 3137
iptables -t nat -A PREROUTING -p udp --dport 138 -j REDIRECT --to-port 3138
iptables -t nat -A PREROUTING -p tcp --dport 139 -j REDIRECT --to-port 3000
iptables -t nat -A PREROUTING -p tcp --dport 445 -j REDIRECT --to-port 3333
iptables -A INPUT -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p udp –dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p udp –dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p tcp –dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p tcp –dport 445 -j ACCEPT

Таблица nat - сам редирект, а ниже в INPUT - открытие портов. Возможно и порты редиректа нужно будет открыть.

Если норм, то можно пробовать оставить только 445/tcp.

Не ясны условия, что и куда надо пробрасывать? Что не работает?
Но попробуйте решение из аналогичного вопроса: Настройки iptables для транзита на другой сервер?

В цепочке FORWARD надо и обратный (-s) трафик разрешать, сейчас у Вас только туда (-d), до 192.168.1.2, разрешено, а обратно - нет. По ссылке как раз есть два нужных, возможно в них все дело.

Это нормально, так NAT (Network Address Translation, сетевая трансляция адресов) и работает - подменяет в заголовках пакета один адрес на другой, поэтому у Вас и получается проброс портов и сокрытие внутренней сети от внешнего наблюдателя.

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

Правила в INPUT не работают, можете их убрать. И рекомендуется MASQUERADE менять на SNAT, если внешний адрес постоянный.

У iptables есть действие REDIRECT, но оно работает только локально. Других способов изменить трафик у него нет, это маршрутизация и Вам нужно изучить работу iproute2.

Можно попробовать SNAT применять к трафику 53/udp, чтобы далее пакеты шли уже по новому маршруту. Но тут надо тестировать, может и не сработает.

Простой вариант: заблокировать проходящий трафик в цепочке FORWARD 53/udp, 53/tcp и поставить локально что-то вроде dnsmasq, и все запросы локальной сети им обрабатывать, а его настроить на работу через vpn.

Чтобы трафик до DNS-сервера с роутера шел через нужный интерфейс, нужно либо прописать статический маршрут, либо пользоваться source policy routing.

Но статический маршрут должен хорошо в вашем случае работать. Например так:
ip route add 8.8.8.8 dev tun+

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

Начните с этого правила:
iptables -I INPUT -s [SERVER_IP] -j ACCEPT

Ключ -I добавляет правило в начало цепочки и оно должно отрабатывать вперед остальных, которые блокирующие.

Если нужны только пинги:

iptables -A INPUT -s [SERVER_IP] -p icmp -m icmp --icmp-type 8 -j ACCEPT

Добавьте/поправьте в 3proxy,cfg:
proxy -n -a -p3128 -i192.168.1.2 -e10.0.0.1

Ну и проверьте, чтобы был доступ на порт 3128 из сети 192.168.1.0 и процессы сервера имели доступ в впн-сеть 10.0.0.0.

ip_forward вернуть на место, прокси его не использует. Трафик между интерфейсами заблокировать (если надо).