картинка сверху для R1, я сделал на S1 ошибочно!!!

Итак, чего мы достигли? Мы настроили маскарад для VM2. Это значит что когда она будет стучаться к S1, то S1 увидит адрес не VM2, а адрес роутера! Парочка пруфов:

а что же в этот момент видит S1?

8.8.8.8 прекрасно общается с 8.8.8.100 =) никаким 172.16.0.2 и не пахло!

а что же происходит в этот момент на роутере? как работает эта кухня? подслушаем "серый" интерфейс eth0.300

а вот как это выглядит на выходе во "внешнюю" сеть

R1

ядро в зависимости от направления пакета обрабатывает его и подставляет правильные ip адреса

А вот если мы сделаем то же самое с VM1, то S1 увидит серые адреса. и просто не ответит на данный запрос. Посмотрите на это самостоятельно. Напомню, что GW на S1 необходимо удалить

На этом, полагаю, на сегодня все. Завтра разберем оставшиеся 2 пункта. Спасибо за внимание, жду ваших комментариев и вопросы в группе!
https://t.me/joinchat/AAAAAEBUOAcqLKMjf2b94A

Доброе утро, мир!

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

Сымитируем, что S1 - некий клиент из интернета и он хочет подключиться к VM1 (тот клиент, до которого нет ни маршрута, ни настроен маскарад). Пусть это будет попытка подлючиться по ssh. SSH по дефолту висит на 22 порту, но если у нас таких серваков будет больше 1, то как быть? Вообще по-хорошему чтобы избавиться от самых простых сканеров сети, ssh нужно всегда убирать с 22 порта. Воспользуемся портом 30022, например, чтобы обратиться по ssh к VM1.
Как это работает?
S1 отправляет пакет (s.ip=s1.ip, d.ip=r1.ip; s.port=N, d.port=30022) который прилетает на R1
R1 Просматривает iptables и применяет правило DNAT, и формирует пакет (по нашему правилу): (s.ip=s1.ip, d.ip=vm1.ip; s.port=N, d.port=22)
Просматривает таблицу маршрутизации и отправляет пакет vm1 через интерфейс eth0.200.

vm1 в свою очередь принимает пакет, получает data, и формирует ответ: (s.ip=vm1.ip, d.ip=s1.ip; s.port=22, d.port=N)
R1 принимает пакет и восстанавливает исходный s.ip к которому изначально обратился s1:
(s.ip=r1.ip, d.ip=s1.ip; s.port=22, d.port=N)

Достичь этого можно следующим образом:

пробуем подключиться

Итого, чему мы научились, работая с NAT?
мы скрыли наши серые сети и выпустили хосты за роутер, подменив ip адеса источников на адрес роутера. И в другую сторону - мы научились пробрасывать определенный порт определнной виртуалки "наружу" и смогли подключиться к серому адресу виртуалки VM1 из "публичной" сети с сервера S1

И последнее, что я хотел бы рассмотреть в данном занятии - tcp сессии и направление установки этих сессий. Так, например, рассмотрим 2 сегмента: серверный и клиентский. Клиент, например, должен иметь возможность "сходить" в серверный сегмент к контроллеру домена. А вот контроллеру домена делать на клиентской машине нечего. Таких примеров можно придумать множество и ситуации почему из одного сегмента сети в другой ходить можно а наоборот нет - тоже. Зачем же может это понадобиться? Например у нас есть веб сервер, который "смотрит" в интернет и им "завладел" злоумышленник. С этого сервера он вполне может попробовать постучаться в корпоративную сеть. Однако, если запретить устанавливать сессии из этого сегмента - этого не произойдет. Т.е. мы по крайней мере усложняем злоумышленнику жизнь. Давайте добавим правило, которое запретит ходить VM2 к VM1, а VM1 к VM2 - можно.