krosh

Странно, но правила выглядят рабочими. Может что-то не так на стороне клиента?

Вместо iptables -A INPUT -j DROP
используйте iptables -P INPUT DROP

Рекомендую пользоваться:

iptables-save > ipt.rules
iptables-restore < ipt.rules

Попробуйте посмотреть лог. Надо перед ACCEPTами добаивить:

iptables -A INPUT -p tcp --dport 22 -j LOG
iptables -A OUTPUT -p TCP --sport 22 -j LOG

и потом
journalctl -f

SSH-клиент работает?
Если -P OUTPUT ACCEPT, работает?
Нужно посмотреть вывод на сервере и клиенте

ip a
iptables-save
netstat -plnt

Ну и вообще нет смысла на хосте ограничивать OUTPUT. Это логично делать на пограничном МЭ. Софт сам будет слать данные в сеть? Зачем эти ограничения? Если INPUT будет фильтроваться, значит и ответных пакетов не будет. А если злоумышленник взломает сервер, то логично, что он сможет добавить исключение для своего приложения.

ip -6 route add 2000::/3 dev he-ipv6

или попробуйте сделать все руками и посмотрите ошибки:

ip tunnel add he-ipv6 mode sit remote 216.66.80.30 local 78.155.219.100 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f0a:b87::2/64 dev he-ipv6
ip -6 route add 2000::/3 dev he-ipv6

Назначить адрес интерфейсу из Вашего диапазона:

ip -6 a a 2001:470:1f0b:b7f::11/64 dev he-ipv6 noprefixroute

Тест:

curl --interface 2001:470:1f0b:b7f::11 "http://myexternalip.com/raw"

Ключевые слова для поиска: "шлюз iptables".

Опция для проброса трафика через хост:
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

Для выхода в интернет используем SNAT вместо маскарадинга (но это если у Вас статический внешний IPv4):
iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j SNAT --to-source 211.233.44.5

Предварительно, при этом предполагаем, что других правил нет, т.к. эти должны идти первыми:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -А FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Разрешаем 1194/udp, SSH:
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -I INPUT -p udp -m udp --dport 1194 -j ACCEPT

Блокируем все остальное:
iptables -P INPUT DROP
iptables -P FORWARD DROP

1. Ви-фи карта должна уметь быть точкой доступа. Не все на это способны, проверяйте.

2. У вас типичный шлюз. Настраивайте по любой инструкции, например: https://wiki.archlinux.org/index.php/Internet_shar... Добейтесь успешной работы в пересылке пакетов из "локальной сети" в интернет и переходите к п. 3.

3. Настройка Редсокса для локального трафика и проходящего мимо немного различается.
# If you want to configure socksifying router, you should look at
# doc/iptables-packet-flow.png and doc/iptables-packet-flow-ng.png and
# wikipedia/File:Netfilter-packet-flow.svg
# Note, you should have proper `local_ip' value to get external packets with
# redsocks, default 127.0.0.1 will not go. See iptables(8) manpage regarding
# REDIRECT target for details.
# Depending on your network configuration iptables conf. may be as easy as:
root# iptables -t nat -A PREROUTING --in-interface eth_int -p tcp -j REDSOCKS

4. Зачем Вам это? Используйте ВПН или ТОР если переживаете о безопасности.

Маска подсети тут ни при чем. Куда шлюзу отвечать на запросы из сети 10.0.0.0/24? Конечно по своему дефолтовому маршруту, который похоже смотрит в сеть провайдера.

Добавьте статический маршрут на шлюзе для возврата пакетов 10.0.0.0/24 обратно в локальную сеть. Ну и правила файерволла надо проверить.

Какой резон вешать два серых адреса из разных пространств и идти с ними в интернет?

DNS SOCKS Proxy, https://github.com/jtripper/dns-tcp-socks-proxy

Предполагая, что 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 -p udp -m udp --dport 53 -m comment --comment "РАЗРЕШЕНО DNS/udp" -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -d yandex.ru -m conntrack --ctstate NEW -m comment --comment "РАЗРЕШЕНО Доступ к Яндексу" -j ACCEPT

2 и 3 правила я бы рекомендовал сделать общими, без привязки к интерфейсу, но не зная, что у Вас к чему ограничился входным (tun0) и выходным (eyh0) интерфейсами.

Сейчас вы только подменяете адрес назначения, но Y-хост отвечает хосту источнику через свой шлюз по умолчанию. Т.е. пакет был направлен в адрес X-хоста, а ответ пришел от Y-хоста, отправитель теряется и сбрасывает соединение, поэтому ничего не получается.

Пакеты через шлюз проходят такие цепочки: PREROUTING, FORWARD, POSTROUTING и вам для каждой нужно правило. Еще нужно, что-бы была разрешена пересылка трафика. Нужно не только подменить адрес назначения (DNAT, PREROUTING), но и заменить адрес источника (SNAT, POSTROUTING), что бы Y-хост отвечал X-хосту, а не по маршруту по умолчанию, и еще не забыть про фильтрацию проходящего трафика (FORWARD).

Чтобы все работало, так как описано выше, нужны такие действия:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --dport 8888 -j DNAT --to-destination Y.Y.Y.Y:80
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 80 -j SNAT --to-source X.X.X.X:1024-32000
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED  -m comment --comment "РАЗРЕШЕНО Установленные соединения" -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate NEW -d Y.Y.Y.Y  -m comment --comment "РАЗРЕШЕНО Новое соединение к Y.Y.Y.Y" -j ACCEPT
iptables -P FORWARD DROP

Первая команда разрешает форфард трафика через хост.
Вторая: подмена назначения в PREROUTING, т.е. в точке решения о маршрутизации уже будет принято решения передать пакет дальше в сеть, а не отдавать локальному процессу.
Третья: подмена адреса источника в цепочке POSTROUTING на выходе на адрес X-хоста. И тогда пакет уже будет выглядеть так, будто он с X-хоста был отправлен на 80 порт Y-хоста.
Четвертая: работа со статусами. Пропускает только пакеты уже установленого соединения. А соединение можно установить только в одну сторону (пятая строка) и только до Y-хоста.
Шестая: сбрасывать все пакеты, которые не подпадают под правила цепочки - политика по умолчанию.

Проблема в данном решении будет только в том, что в логах у вас будет один адрес источника - X-хоста. Если это важно и речь про веб-сервер, то я бы рекомендовал разобраться с проксированием nginx и ничего пробрасывать не придется.

Еще нужно разобраться с локальным трафиком на 8888 и 80 порты. и трафиком из локальной сети, если это шлюз. Но это уже отдельный вопрос.

Вопрос в том, откуда куда должен идти трафик? Из локальной сети на mail.shf.com.ua? или из интернета локально на шлюз?

Фильтрация в таблице nat не рекомендуется:

$ip -t nat -A POSTROUTING -d mail.shf.com.ua -o $EXTERNAL_IF -p tcp -m multiport --dports 80,443,465,993,995 -j MASQUERADE

Рекомендую заменить на:

-t nat -A POSTROUTING -j MASQUERADE
-P FORWARD DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i $LOCAL_IF -o $EXTERNAL_IF -s $LOCAL_NET -d mail.shf.com.ua  -p tcp -m multiport --dports 80,443,465,993,995  -m comment --comment "РАЗРЕШЕНО ИСХ Почтовые протоколы + http/s" -j ACCEPT

Если трафик идет на шлюз, а не транзитный, то смотрите процесс на порту:
netstat -antp |grep 465

У Вас в правилах бардак. Надо бы сначала из причесать, а уже потом разбираться. Скорей всего из-за этого что-то и не работает. А бардак просто от незнания.

Почему используете MASQUERADE, а не SNAT? Внешний адрес динамический?

Проблема таких скриптов, в том, что не ясно какой набор правил будет в итоге. А если работа скрипта прервется на полпути? Где очистка цепочек перед загрузкой новых правил? Политики по умолчанию? Используйте iptables-save, iptables-restore. Либо генерируйте сценарием файл с правилами, а грузите есть через iptables-restore.

Нужно хотя бы iptables -L --line-numbers показать, чтобы фактическое состояние смотреть, а не то, что в скрипте прописано.

Хотите разобраться? Сохраните все правила и очистите все цепочки и начинайте настройку именно с открытия нужных портов и маскарадинга трафика. Потом усложняйте правила.

В блоке #cam уж используйте multiport, они же есть в других правилах ниже.

80 порт Вы редиректите на прокси, а 443/https маскарадите. Будьте последовательны в своих намерениях. Либо пользуйте прокси на все порты, либо используйте НАТ/маскардинг для всего трафика.

Цепочку INPUT не проходят транзитные пакеты.
В цепочке FORWARD у Вас пока политика разрешает все, поэтому в правилах там нет смысла. После смены политики по умолчанию не забудьте дополнить обратными правилами, с портом источника 22513.

Пинги до В идут?
Порт открыт, подключение с А возможно?
Маршрут до В прописан?
На В есть блокировка входящих? Надо разрешить доступ А на порт 22513.

Покажите
cat /proc/sys/net/ipv4/ip_forward
iptables -t nat -S
iptables -S FORWARD
ip route sh