Спасибо большое! Единственная инструкция, которая действительно помогла настроить интернет на второй машине! Искал нужную информацию больше недели! С П А С И Б О! ВЫ спасили мой диплом)))
Не понял второй случай 15:41. Если мы на prerouting уже поменяли адрес и порт, то дальше должна работать цепочка forward, ведь пакетик предназначается не нам, почему он попадает в цепочку input? Я так понимаю успех был потому что политика forward accept. спасибо
Угу, я тоже не понял, почему так работает. Но помимо этого я не понял еще одну деталь. Почему при инициации запроса из внутреннего сервера, пакеты проходят в обратную сторону? Мы ведь не указывали явно, что ESTABLISHED и RELATED пакеты в обратную сторону должны работать. Должно же быть что-то вроде: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT . Или я ошибаюсь? Политика ACCEPT для FORWARD окутала всё туманом.
Добрый день. Посмотрел ваше видео, спасибо вам за видео. Но не получается настроить по аналогии, скажите пожалуйста можно ли с вами связаться что бы проконсультироваться по моему случаю ?
Какой тип правил/тип таблицы корректно использовать для организации роутинга между двумя виртуальными интерфейсами на сервере (запущенно два клиента разных виртуальных сетей, которые являются шлюзами в WAN для своих подсетей. Для каждой используется запись SNAT). В Интернет клиенты обеих сетей попадают, но друг друга сети не видят. Эксперименты с -t nat -A POSTROUTING... дают положительные результаты в доступе в одном направлении. Но хотелось бы узнать наиболее рациональный вариант.
Запутался я. Зачем разрешать порт 9022 в инпуте если он не предназначен хосту и пойдет в форвард? Может тогда -A FORWARD -i enp0s3 -o enp0s8 -j ACCEPT ?
Получается на домашнем роутере откуда приходит интернет тоже самое можно сделать, так? То есть домашнее устроство пробросить через роутер чтобы им можно было снаружи управлять?
К сожалению такой метод не работает с Докером. Поставил на docker контейнер с WireGuard VPN. В докере открыл порт VPN порт + 3000:3000. Внутри контейнера пытаюсь сделать PortForwarding на единственного подключившегося VPN клиента, который сервит HTTP на порту 3000. когда делаю Curl $VPN_CLIENT_IP:3000 - возвращает HTML, т.е. VPN коннект есть. А вот curl $CONTAINER_IP:3000 дает Connection Refused 😞
Я разобрался. Проблема была в том что я тестировал отправляя запросы с IP этого же сервера на свой же IP - поэтому я думал что это не работает. А как отправил запрос с другого сервака - убедился что все правильно forward-ится
Единственное видео в интернете, которое решает твою проблему.
согл
Спасибо большое! Единственная инструкция, которая действительно помогла настроить интернет на второй машине! Искал нужную информацию больше недели! С П А С И Б О! ВЫ спасили мой диплом)))
Очень познавательно и интересно, спасибо!
Почему так мало лайков? Лучшее видео!
Спасибо за качественный контент)
Спасибо, классное видео, я как раз таки подвис в конфигурации NAT Gateway на серверах через terraform
Спасибо за объяснение!
Ооочень понятно объясняете. Благодарю Вас)
Очень классные у вас видео. Спасибо!
Спасибо, всё классно и работает!!! Очень помогли
Отличное видео, все четко и доходчиво!!!
спасибо за толковую инструкцию!
Спасибо огромное, очень полезно)
Огромное спасибо за видео!
Спасибо огромное
спасибо
Не понял второй случай 15:41. Если мы на prerouting уже поменяли адрес и порт, то дальше должна работать цепочка forward, ведь пакетик предназначается не нам, почему он попадает в цепочку input? Я так понимаю успех был потому что политика forward accept. спасибо
Угу, я тоже не понял, почему так работает. Но помимо этого я не понял еще одну деталь. Почему при инициации запроса из внутреннего сервера, пакеты проходят в обратную сторону? Мы ведь не указывали явно, что ESTABLISHED и RELATED пакеты в обратную сторону должны работать. Должно же быть что-то вроде: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT . Или я ошибаюсь? Политика ACCEPT для FORWARD окутала всё туманом.
Добрый день.
Посмотрел ваше видео, спасибо вам за видео.
Но не получается настроить по аналогии, скажите пожалуйста можно ли с вами связаться что бы проконсультироваться по моему случаю ?
Супер! жаль тут список используемых в уроке правил не выложили
Добавили ссылку в описание ролика.
А можно видео о полной настройки межсетевого экрана? Или же iptable подходит по это?
Да, конечно подходит.
А для чего нужен INPUT 9022 ACCEPT? Пакет ведь не должен доходить до сокетов?
Да, вы правы это правило не нужно.
@@site_support значит ваше видео очень толковое, раз я с первого знакомства с iptables нашел ошибку )
Какой тип правил/тип таблицы корректно использовать для организации роутинга между двумя виртуальными интерфейсами на сервере (запущенно два клиента разных виртуальных сетей, которые являются шлюзами в WAN для своих подсетей. Для каждой используется запись SNAT). В Интернет клиенты обеих сетей попадают, но друг друга сети не видят.
Эксперименты с -t nat -A POSTROUTING... дают положительные результаты в доступе в одном направлении. Но хотелось бы узнать наиболее рациональный вариант.
Запутался я. Зачем разрешать порт 9022 в инпуте если он не предназначен хосту и пойдет в форвард? Может тогда -A FORWARD -i enp0s3 -o enp0s8 -j ACCEPT ?
Да, там не нужно. На видео видно, что счетчик пакетов на это правило нулевой, т.е. оно не сработало.
Здравствуйте, как называется приложение в котором вы рисовали план синего цвета до программирования NAT?
MyPaint
Получается на домашнем роутере откуда приходит интернет тоже самое можно сделать, так? То есть домашнее устроство пробросить через роутер чтобы им можно было снаружи управлять?
Да, конечно у большинства домашних роутеров есть проброс портов, может называться по-разному, но должен быть.
Если на U20 будет 3 интерфейса, то возможно придется править метрики.
Как насчёт создать script и вкинуть туда правила и в начале скрипта задать переменные?
Нормальный вариант?
Какой script?
@@site_support создать файл, создать в нем переменные с портами, с интерфейсами и тд
Затем правила создавать с этими переменными
@@alexander199740 можешь в .bashrc в окружные переменные запихнуть, это вроде так правильно делается
К сожалению такой метод не работает с Докером. Поставил на docker контейнер с WireGuard VPN. В докере открыл порт VPN порт + 3000:3000. Внутри контейнера пытаюсь сделать PortForwarding на единственного подключившегося VPN клиента, который сервит HTTP на порту 3000. когда делаю Curl $VPN_CLIENT_IP:3000 - возвращает HTML, т.е. VPN коннект есть. А вот curl $CONTAINER_IP:3000 дает Connection Refused 😞
Я разобрался. Проблема была в том что я тестировал отправляя запросы с IP этого же сервера на свой же IP - поэтому я думал что это не работает. А как отправил запрос с другого сервака - убедился что все правильно forward-ится
а если нужно например с Ubuntu перебросить в Windows
Нет проблем, правила те же самые.
На минте не должно было сработать?
Почему?
как бы не запутаться с SNAT (static NAT) и DNAT (dynamic NAT)
Здесь: SNAT - Source Network Address Translation, DNAT - Destination Network Address Translation