Доступ в виртуалку через нат

Вот если из VE101 сделать такую команду, то получу таймаут

$ telnet 88.88.88.88 80

А что вы пытались добиться то? Чтобы VE101 законнектилась сама на себя? Сейчас плохо соображаю, устал, но ЕМНИП, линуксам нифига не нравится, когда им приходит пакет с src-адресом с одного из их интрефейсов, его там rp_filter может грохнуть или его могут признать «марсианским» пакетом.

А что вы пытались добиться то? Чтобы VE101 законнектилась сама на себя? Сейчас плохо соображаю, устал, но ЕМНИП, линуксам нифига не нравится, когда им приходит пакет с src-адресом с одного из их интрефейсов, его там rp_filter может грохнуть или его могут признать «марсианским» пакетом.

Для того, чтобы такая шняга работала в цысках делают hairpinning, или twice nat или что-то такое, забыл уже. Т.е. чтобы можно было коннектится из натируемой наружу локалки к внешнему адресу той же НАТ-коробки, который натируется куда-то внутрь. Как-то так :)

В линухах, наверное, как-то аналогично.

зайти изнутри контейнера через внешний адрес на порт, который проброшен внутрь этого контейнера

)))))...))))))

Может просто настроить нормально днс?

Т.е. чтобы можно было коннектится из натируемой наружу локалки к внешнему адресу той же НАТ-коробки, который натируется куда-то внутрь.

именно так. раньше читал про double nat, но было мало инфы, почитал про twice nat, тоже не много, но кое что узнал - пакет не может попасть в нат таблицу два раза, что объясняет часть трейса. попробую дальше разбираться.

Т.е. чтобы можно было коннектится из натируемой наружу локалки к внешнему адресу той же НАТ-коробки, который натируется куда-то внутрь.

В случае с ТС у него есть VE101 с адресом 192.168.10.1. С этой виртуалки TC идёт на 88.88.88.88, где настроен DNAT на 192.168.10.1 и его пакет благополучно DNATится обратно на 192.168.10.1, где, скорее всего рубится rp_filter'ом.

Причём, судя по фразе ТС: «не попадает в net:POSTROUTING и SNAT на него не срабатывает», он хочет, чтобы на пакет ещё сработало SNAT правило (-j SNAT --to-source 88.88.88.88), но, почему то, считает, что пакет должен уходить в виртуалку на 192.168.10.1 через eth0, а не через venet0. Я пытаюсь понять, толи ТС ошибся в SNAT-правиле (-i eth0), толи ему действительно надо, чтобы этот злосчастный пакет ещё и по ethernet (физической сети) походил.

да, все верно, с нат все понял. но проблема с тем что пакет после возвращения в VE101 все равно где-то теряется и до filter:INPUT не доходит.

Покажите трассировку пакета в iptables при включенном log_martians и посмотрите, не появилось ли записей в логах о «марсианских» пакетах.

записей в логах о «марсианских» пакетах.

спасибо, похоже это верное направление. уже более понятно что с этими пакетами происходит и общее направление. буду копать дальше.

[17498.631393] martian source 192.168.10.11 from 192.168.10.11, on dev venet0
[17498.631450] ll header: 45:10:00:3c:6e:f4:40:00:40:06:36:51:c0:a8

Собственно изначально проблема была с сокетами (битрикс ругался непонятными ошибками), по ходу выяснилось вот это неожиданное поведение. А проблему решил использованием дополнительного внешнего адреса.
Еще помню из этой серии когда человек изнутри локалки пытается зайти на внешний адрес роутера.