VPN и проброс портов

а шо впн? а как ж сам комп?

Не понял вопроса)

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

Хм, а ведь и правда, логика в этом есть)

Сам спросил сам ответил.

Чтобы всё

iptables -t nat -A PREROUTING --dst mmm.xxx.yyy.zzz -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10

iptables -t nat -A POSTROUTING --dst 192.168.1.10 -p tcp --dport 80 -j SNAT --to-source 192.168.1.1

iptables -t nat -A OUTPUT --dst mmm.xxx.yyy.zzz -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10

iptables -I FORWARD 1 -i ens18 -o tun0 -d 192.168.1.10 -p tcp -m tcp --dport 80 -j ACCEPT

где mmm.xxx.yyy.zzz - внешний IP VPS

Может последнее правило и лишнее, но в любом случае без ната в цепочке OUTPUT нормально ничего не работает.

Все равно все это непонятно.

Если у тебя впн поднят, то зачем вообще маскарадинг? Все должно работать напрямую. А если ты DNAT настроил на vps, то зачем тогда вообще vpn? Да и snat там в любом случае лишний.

Если у тебя впн поднят, то зачем вообще маскарадинг?

Как ни странно, но без этих правил не работает, хотя должно.

А если ты DNAT настроил на vps, то зачем тогда вообще vpn?

Неуверен, что правильно понял вопрос, но провайдер выдаёт серый статический IP, со всеми вытекающими. Плюс пров из Тундры и не факт, что при заказе белого IP суппорт поймет, что от них требуется именно проброс портов на абонентском оборудовании.

Тот случай, когда вчерашние фарцовщики подались в телекоммуникации - это я о провайдере, не о себе))

но в любом случае без ната в цепочке OUTPUT нормально ничего не работает.

Это правило только для процессов запущенных на машинке где оно и добавлено.

Как ни странно, но без этих правил не работает, хотя должно.

Значит, неверно настроил vpn. Не настроена маршрутизация туда или обратно.

Просто нарисуй схему и разберись, откуда и куда ты обращаешься. Как пакет должен идти туда, и как ответ вернется обратно.

С vps при поднятом тоннеле обращение с 192.168.1.1 на 192.168.1.2 должно идти прямо и без всяких днатов. Проверяй через wget или curl с самого vps.

Да в туннеле понятно, что оно будет ходить, но я то клиентом (смарт) потом обращаюсь по белому IP VPS, который знать не знает о поднятом реверс-туннеле между тестовым ПК и самим VPS.

Для меня в целом все логично)

Ну так если для тебя все понятно, то чего тогда маешься?

Тебе нужно:

Убрать все днаты и снаты. Оставить только туннель и убедится, что он полностью работает. С vps можно зайти на домашний комп и обратно. Все пингуется по туннельным адресам, все хорошо.

Далее:

1. Добавить DNAT с порта 8080 белого IP на 80 порт своего компа за тунелем

Запускаешь tshark на домашнем компьютере на 80 порту тунельного ip и видишь, что при попытке обращений запрос от телефона с его интернетовским адресом есть. А ответ идет через твой eth0 и поэтому теряется.

2. Добавить на vps маскарадинг обращений извне к тунельным адресам.

Запускаешь tshark на домашнем компьютере на 80 порту тунельного ip и видишь, что при попытке обращений запрос идет с тунельного адреса VPS. И ответ идет обратно на него, поэтому все работает.

Жмем руки, расходимся.

2.Добавить на vps маскарадинг обращений извне к тунельным адресам.

Тут немного не понял,

iptables -t nat -A POSTROUTING --dst mmm.xxx.yyy.zzz -p tcp --dport 80 -j SNAT --to-source 192.168.1.10

так?

В целом понял, правил поменьше.

Спасибо.

Вот так

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

да, snat и masq это разные вещи.

Этот вариант верный. Проверяй, должно работать.

Всё как доктор прописал)

Да, хотя и в таком виде тоже работает

iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 192.168.1.1

SNAT vs MASQUERADE

если только для одного человека.

Попробуй с разных телефонов зайти и посмотри.

Хотя может и сработает. Давно уже не смотрел в эту сторону.

если только для одного человека

Да, это я просто на пробу сделал)

На постоянку лучше оставить маскарадинг

если только для одного человека.

С чего бы это?

Согласен, устарело уже. Помнится, раньше snat был stateless. Я даже не заметил, как его подогнали по сути под masq.

Я даже не заметил, как его подогнали по сути под masq.

Нуу вы очень сильно старались «не замечать». :) Годиков эдак не меньше 18-ти :)

Примерно так и есть.

Со времен red hat 5 и дебиан 2.2 potato.

Разве в 5-ой шляпе уже был iptables? Мне почему-то кажется, что ещё нет.

ipchains тогда был.

Вот! А мы вроде как про iptables говорили.
ЗЫ Я уж чуть не подорвался откопать диск с пятой шапкой. :)

Ну так а какая хрен разница. Потом в 6 шапке уже iptables начался. На ядре 2.2 или даже 2.4 И там тоже был masq и практически бесполезный snat.

Фига себе у вас сравнение. Мальчик, девочка, iptables, ipchains, та ваше никакой разницы.

На ядре 2.2

На 2.2 ipchains

Я не заметил чего-то прям принципиального.

Да, сделали гораздо более упорядочено и функционально, но в общем и целом, все тоже самое.

Собственно, как и сейчас. Перешли же на nftables. Тоже разница есть и большая, но кто это заметил?

Я не заметил чего-то прям принципиального.

Различия весьма значительны. Один модуль state чего стоит. На всякий случай поясню. Я не про то, что знания ipfw нельзя использовать в ipchains, знания ipchains нельзя использовать в iptables. Но если дали инструмент позволяющий больше, то лучше использовать эти возможности.

Да кто бы спорил.

Просто с точки зрения простого использования как тут, разница не критична.

Хорошо вернемся к модулю state. Как раньше решали вопрос? Правильно, тупо разрешаем всё что выше серверных портов и кусочками впихиваем reject-ты если у нас там что-то серверное болтается/может болтаться.
А как решали разделение input/output и forward ? Заданием ip адресов в -s -d. Локальные изменения по пользователю? Не, не слышали. SNAT - вы о чем? Вот кстати не помню точно, кто не умел dnat на другой хост, только ipfwadm или и ipchains тоже.
И это всё только то, что за 5 минут вспомнил.

Да я не спорю, не спорю. ;) Не было бы изменений, не было бы и новых интерфейсов.

Но с точки зрения вот этого кейса, что старые могли замаскарадить локалку в интернет, что новые. Вот и все. С бытовой точки зрения, все стало проще, понятней и функциональней, но не изменилось. Я в то время просто переводил компании с виндового керио winroute или что-то там было для маскарадинга и все эти тонкости были очень и очень далеко от меня…

Но с точки зрения вот этого кейса, что старые могли замаскарадить локалку в интернет, что новые.

Коренное слово замаскарадить. Адын ip мы за ценой не постоим. :) Никаких вам радостей жизни в виде разных адресов, в зависимости от...

Я в то время просто переводил компании с виндового керио winroute и

Аааа... Вопросов нет, вот уж воистину, с какой стороны посмотреть. :) Я плавно переезжал ipfwadm, ipchains, iptables. :)

Никаких вам радостей жизни в виде разных адресов, в зависимости от...

Можно где-нить увидеть примеры использования?

Хотелось бы почитать для общего развития.

Например почтовый сервер.

Коренное слово замаскарадить. Адын ip мы за ценой не постоим. :) Никаких вам радостей жизни в виде разных адресов, в зависимости от…

Давно уже пользуюсь shorewall и он от меня эту подробность скрыл.

Сейчас посмотрел, чего он там генерит в iptables, а у него в конфигах одно и тоже правило транслируется в маскарад, если не указать to-адрес и в snat правило, если указать.

В последних версиях он явно автоматом переделывает записи с указанием адреса в правила snat. Но ранее он этого не делал и я был уверен, что это один и тот же маскарад…

Я про вариант: один интерфейс, разные адреса.

И я про него. У меня несколько алиасов на интерфейсе в интернет и в зависимости от разных условий, я могу подставлять любой из них в качестве to-source.

В shorewall есть файлик masq, в котором эти правила описываются

################################################################################################################
#INTERFACE:DEST         SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/   SWITCH  ORIGINAL
#                                                                                       GROUP           DEST

#выход в интернеты 

inet                10.1.0.0/16                    <- с подсети 10.1.0.0 выходить с основного адреса интерфейса inet
inet                192.168.1.10/32          1.0.0.10   <- с адреса 192.168.1.10 выходить в интернет с адреса 1.0.0.10, который висит алиасом на интерфейсе inet

Один файл, два правила, вроде все одинаково, но первое правило транслируется в правило masq, а второе - snat, потому что указан адрес, с которого ходить.

А, понял. Не правильно распарсил с первого раза.