Спасибо большое! Единственная инструкция, которая действительно помогла настроить интернет на второй машине! Искал нужную информацию больше недели! С П А С И Б О! ВЫ спасили мой диплом)))
Не понял второй случай 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 окутала всё туманом.
А для чего нужен INPUT 9022 ACCEPT? Пакет ведь не должен доходить до сокетов?
Да, вы правы это правило не нужно.
@@site_support значит ваше видео очень толковое, раз я с первого знакомства с iptables нашел ошибку )
Какой тип правил/тип таблицы корректно использовать для организации роутинга между двумя виртуальными интерфейсами на сервере (запущенно два клиента разных виртуальных сетей, которые являются шлюзами в WAN для своих подсетей. Для каждой используется запись SNAT). В Интернет клиенты обеих сетей попадают, но друг друга сети не видят.
Эксперименты с -t nat -A POSTROUTING... дают положительные результаты в доступе в одном направлении. Но хотелось бы узнать наиболее рациональный вариант.
Запутался я. Зачем разрешать порт 9022 в инпуте если он не предназначен хосту и пойдет в форвард? Может тогда -A FORWARD -i enp0s3 -o enp0s8 -j ACCEPT ?
Да, там не нужно. На видео видно, что счетчик пакетов на это правило нулевой, т.е. оно не сработало.
Спасибо огромное
А можно видео о полной настройки межсетевого экрана? Или же iptable подходит по это?
Да, конечно подходит.
Супер! жаль тут список используемых в уроке правил не выложили
Добавили ссылку в описание ролика.
Добрый день.
Посмотрел ваше видео, спасибо вам за видео.
Но не получается настроить по аналогии, скажите пожалуйста можно ли с вами связаться что бы проконсультироваться по моему случаю ?
спасибо
Здравствуйте, как называется приложение в котором вы рисовали план синего цвета до программирования NAT?
MyPaint
К сожалению такой метод не работает с Докером. Поставил на 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-ится
Получается на домашнем роутере откуда приходит интернет тоже самое можно сделать, так? То есть домашнее устроство пробросить через роутер чтобы им можно было снаружи управлять?
Да, конечно у большинства домашних роутеров есть проброс портов, может называться по-разному, но должен быть.
Если на U20 будет 3 интерфейса, то возможно придется править метрики.
а если нужно например с Ubuntu перебросить в Windows
Нет проблем, правила те же самые.
На минте не должно было сработать?
Почему?
Как насчёт создать script и вкинуть туда правила и в начале скрипта задать переменные?
Нормальный вариант?
Какой script?
@@site_support создать файл, создать в нем переменные с портами, с интерфейсами и тд
Затем правила создавать с этими переменными
@@alexander199740 можешь в .bashrc в окружные переменные запихнуть, это вроде так правильно делается
как бы не запутаться с SNAT (static NAT) и DNAT (dynamic NAT)
Здесь: SNAT - Source Network Address Translation, DNAT - Destination Network Address Translation