DB
Усугублю вопрос. Если ставим вместо masquerade src-nat с адресом выходного интерфейса, тоничего не получаем. Как так?
Size: a a a
2020 November 20
MG
Все получаем, у Вас что-то явно не так
DB
Вот и разираюсь, что не так... Должно, а не фурычит...
DB
Есть L2TP интрефейс на CHR, через него шарится удаленная внутренняя сеть. Нужен доступ к определенному IP адресу из той определенной сети.
chain=dstnat action=dst-nat to-addresses=172.17.146.18 to-ports=3389
protocol=tcp dst-address=8._._.25 in-interface=ether1 dst-port=3389
log=no log-prefix=""
chain=dstnat action=dst-nat to-addresses=172.17.146.18 to-ports=3389
protocol=tcp dst-address=8._._.25 in-interface=ether1 dst-port=3389
log=no log-prefix=""
DB
Ага, и вроде подсказали как. Мой косяк
MG
Да нет
MG
Не проблема в дефолтном ид пользователя
DB
Мне и не нужен, но заставить работать с src-nat не получается. Только так chain=srcnat action=masquerade log=no log-prefix=""
DB
Дя тоже так считаю, но увы не выходит каменная чаша. На дальнем конце от CHR нет белого IP
DB
Как видим - можно и без него.
MG
Это не отменяет необходимости роутинга
MG
Вы пытаетесь решить проблему непонимания маршрутизации костылём NAT.
DB
Для чего? Пакеты на дальний конец бегут прекрасно по тоннелю, но они знают куда возвращаться без NAT на CHR
DB
К сожалению, маршрутизация прекрасно рабоатет, если у меня две внутренние сетки. И там можно прописать куда и чего безо всякого NAT/
MG
NAT вообще нужен только для прохода барьеров инсайд/аутсайд адресов или всяких балансировок, все остальное - это костыли.
MG
А у Вас их не две?
MG
Вы ж говорите туннель л2тп
DB
Это ставил эксперименты. С двумя сетками - всё видно прекрасно через l2tp.
MG
Я тогда вообще не понимаю, что в хотите.
M
В чем косяк?