Некорректный IP-адрес в строке Last login при подключении по SSH к LXC-контейнеру.

С каким контейнером?

LXC

Да ты всё прав, просто proxmox что кластерная штука, в которой при подключении к виртуалке по IP адресу должно работать подключение вне зависимости от того, где эта виртуалка расположена. И особенно, если она вообще в процессе переезда. Поэтому все соединения производятся с IP адреса моста.

Не совсем понимаю про что ты. Зашёл на LXC контейнер, но по его IP, т.е. IP контейнера, там виден мой IP, а точнее IP vpn сервера, через который подключен к сети компании, на нём делается NAT.

Контейнер может мигрировать между узлами кластера proxmox, но на каждом узле должна быть доступна сеть (VLAN / Bridge), к которому подключена сеть в LXC контейнере и IP подключающегося в last будет соответствовать клиенту, с которого произошло подключение, без разницы на какую ноду кластера мигрировал контейнер / ВМ.

-i vmbr0 –dport 22 -j DNAT –to-destination 192.168.0.136

vmbr0 - на каком устройстве поднят?

На котором Proxmox работает.

А зачем? Всё должно спокойно маршрутизироваться. В LXC контейнере задай шлюз, если это должен быть сам proxmox, т.е. IP адрес шлюза - на интерфейсе proxmox - пропиши на сетевом оборудовании маршруты до сети через внешний IP proxmox, т.е. через который он доступен в локальной сети.

Если сети перекрываются - для ВМ / LXC на proxmox поднимай отдельную сеть.

Да, в контейнере указан шлюз - 192.168.0.1, который соответствует внутреннему IP железки с Proxmox:

# ip route show
default via 192.168.0.1 dev eth0 proto static
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.136

Тогда контейнер должен быть доступен по своему IP без всяких NAT.

Маршрут из общей сети пропиши и всё. И bdirge должен быть с внешним интерфейсом proxmox.

Но лучше, чтобы IP узла proxmox был в одной сети для управления. А сеть контейнеров / ВМ в отдельной сети, на отдельном физическом интерфейсе или VLAN.

Да, без NAT, по локальному адресу (192.168.0.136) контейнер доступен. А вот по example.com к нему уже не попасть.

Пропиши в hosts

192.168.0.136 example.com

На машине с которой подключаешься - попадёшь.

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

В протоколе SSH - нет SNI и его нельзя проксировать. Т.е. ты не можешь сделать, что example1.com, example2.com, example3.com указывали на один IP и чтобы при подключении было:

• ssh example1.com -> ssh 192.168.0.136
• ssh example2.com -> ssh 192.168.0.137
• ssh example3.com -> ssh 192.168.0.138

Вот так можно:

• ssh example1.com -p 22136 -> ssh 192.168.0.136 (22)
• ssh example2.com -p 22137 -> ssh 192.168.0.137 (22)
• ssh example3.com -p 22138 -> ssh 192.168.0.138 (22)

На одном внешнем IP делаешь проброс разных портов на соответствующий внутренний IP и 22 порт.

Либо разные внешние IP и стандартный порт 22, либо разные порты.

Либо поднимай VPN сервер, допустим с внутренней DNS зоной, где example1.com, example2.com, example3.com указывают на внутренние IP конкретных контейнеров.

Либо проброс разных портов.

Ещё ты можешь взять одну систему, на которую будет осуществляться подключение по одному SSH порту, но разными пользователями.

И настроить, что если подключаются

• ssh user1@public_ip -> root@private_ip1
• ssh user2@public_ip -> root@private_ip2
• ssh user3@public_ip -> root@private_ip3

Смотри документацию по sshd_config.

Но зайти потом под этими пользователями по SSH на саму систему, где работает переключение, без изменения конфигурации SSH сервера нельзя будет.

Match User user01
    ForceCommand ssh -tt root@192.168.0.136
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY yes

Match User user02
    ForceCommand ssh -tt root@192.168.0.137
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY yes

Match User user03
    ForceCommand ssh -tt root@192.168.0.138
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY yes

Но тут нужна авторизация по SSH ключам, они могут быть разные на первом сервере и втором, но должны быть загружены в SSH агент.

С паролями не пробовал, возможно не заработает. Пробуй, если нужно с паролями, сам.

Либо можешь явно подключаться через jump хост:

ssh root@192.168.0.136 -j user02@public_ip:22

У тебя там кроме DNAT есть ещё SNAT?

Да, всё правильно. Я почему-то решил, что ТС надо подключаться с одного хоста, а не снаружи.

Было так:

iptables -A POSTROUTING -t nat -p tcp -d 192.168.0.136 --dport 22 -j SNAT --to-source 12.34.56.78

Но я это удалил, так как вместо постоянного 192.168.0.1 со всех клиентов становилось 12.34.56.78.

Хотелось бы чтобы отображался реальный адрес КЛИЕНТА, а не шлюза.

Снаружи доступ к контейнеру должен быть. Там nginx + php-fpm + mariadb.

Снаружи доступ к контейнеру должен быть только по 443 и 80 порту и то, последнее - для редиректа на 443.

А время последнего входа совпадает?

Время меняется при очередном входе. В отличие от адреса.

Скорее всего тебе нужен тот самый hairpin NAT

Где-то ещё по любому есть SNAT. Иначе как в интернет ходить.

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

Спи давай.

Итак, частично получилось достичь желаемого.

Две строчки:

iptables -A POSTROUTING -t nat -o eno1 -j MASQUERADE
iptables -A POSTROUTING -t nat -o vmbr0 -j MASQUERADE

Заменил на одну:

iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE

Теперь, при подключении к контейнеру через мобильный инет, SSH выводит правильный адрес последнего подключенного клиента:

Last login: Sat Jan 3 15:53:42 2026 from 176.15.172.27

Однако! При подключении к контейнеру из локалки:

- с 192.168.0.4 к example.com, получаю это:

Last login: Sat Jan 3 16:05:58 2026 from 192.168.0.1

, хотя адрес ожидался-таки 192.168.0.4!

- с 192.168.0.4 к 192.168.0.136, получаю это:

Last login: Sat Jan 3 16:12:20 2026 from 192.168.0.4

Ну, тут, вроде бы, всё в порядке и ожидаемо.

192.168.0.4 к example.com, получаю это

Так работает nat. У тебя example.com это внешний адрес. Если будешь подключаться к внешнему ip, также будет.

Так работает nat. У тебя example.com это внешний адрес. Если будешь подключаться к внешнему ip, также будет.

btw можно разнести зону example.com между внешними и внутренними сетями, в бинде это из каробки заточено, в каких-то других реализациях возможно придется два отдельных демона поднимать.

Заменил

Я тебя спрашивал: «У тебя там кроме DNAT есть ещё SNAT?». Ты мне что ответил?

Да судя по топику ТС действует исключительно старым дедовским способом под названием «метод тыка» не вникая в суть того, что делают те или иные ключи.

Нет, SNAT отсутствует. Вместо SNAT используется MASQUERADE.

MASQUERADE — это SNAT.

В следующий раз просто выложи что есть, а не что думаешь.

Прежде чем, что-то делать, нужно понять как и что, а не как «Я его слепила из того, что было» и ещё не нужно менять рельеф, пока составляешь карту местности.