to post messages and comments.

@Strephil:

Но в результате всех этих действий на ноутбуке пропал инет.
Ложиться спать или дальше настраивать?

@Strephil:

Разобрался, почему пакеты не приходили!
Нужно было написать -A INPUT -i lo -j ACCEPT
у меня было написано -s 127.0.0.1, но это же не одно и то же! потому что у этих пакетов -s как раз другой, у них -d 127.0.0.1.

@Strephil:

В настройках systemd к одному из интерфейсов у меня написано:
[Network]
DHCP=yes
IPForward=ipv4
IPMasquerade=yes

и в таблице nat появляется строчка:
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all — 192.168.0.0/24 0.0.0.0/0

Если эту таблицу сбросить, то подмена адреса прекращается. Но вот что удивительно, адрес-то меняется не на 192.168.0.16, а на адрес другого интерфейса… Хотя, там же в этом дополнительном правиле и не говорится ничего про интерфейс (почему?).

@Strephil:

Я прописал правило:
$ iptables -t nat -A OUTPUT -p udp --dport 555 -j REDIRECT --to-ports 5555
Даю команду
$ nc -u ya.ru 556
Это другой порт, он никуда не перенаправляется, поэтому я вижу в tcpdump вполне ожидаемые пакеты:
192.168.0.16.48741 > 87.250.250.242.556
Теперь я пробую
$ nc -u ya.ru 555
и с помощью tcpdump я вижу, что пакеты теперь почему-то имеют другой src-адрес! Не 192.168.0.16, а другого сетевого интерфейса, не буду его палить!
Кроме того, я запускаю
$ nc -l -u localhost 5555
и этих пакетов не вижу! Они почему-то не доходят… Где же они теряются?

На ноутбуке почему-то работает.

@Strephil:

Я у мамы админ локалхоста, и я что-то не очень понимаю, как работает -j REDIRECT.
Напердолил тестовую программки, запускаю на ноутбуке — всё работает. Пакеты перенаправляются, куда надо.

Но я смотрю на них в tcpdump, а там:
192.168.13.138.34288 > 127.0.0.1.5555: UDP

меня это смущает :)

Сейчас буду разбираться, почему на десктопе не работает :)

@Strephil:

Жуйк, а если я хочу -j DNAT, я могу указать не только другой ip-аредс, но и другой порт? Или нужно сначала DNAT, потом REDIRECT?

@Strephil:

Похоже, что запуск docker'а на десктопе ломает напердоленные правила iptables, и на ноуте пропадает интернет.

@Dant:

Неплохая шпаргалка/квик-старт-гайд по UFW: cyberciti.biz

@L29Ah:

Дайте костыль для автоматического производства правил iptables для заворачивания хуйни из говнореестра в специальное правило.

@OCTAGRAM:

-j REDIRECT --to-ports зачем–то ещё и меняет целевой IP на основной IP интерфейса. Вот кто его просил это делать? Не вижу, как отключить. Пришлось перейти на -j DNAT --to-destination

@unfalse:

Вот вроде полезная статья в ксакепе и такая чушь в заключении.

@Turbid:

Чтобы iptables завелся внутри lxc-контейнера делаем на хосте:
# mkdir /var/lib/lxc/<name>/rootfs/lib/modules
# echo "iptable_filter" >> /etc/modules
и в конфиг контейнера:
lxc.mount.entry = /lib/modules /var/lib/lxc/<name>/rootfs/lib/modules none ro,bind 0 0

@Strephil:

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

@Dant:

Скриптег файрвола для одиноко-стоящей в интернетах VPS-очки : ) Бета-Версия: pastebin.com

Пока сочинял, узнал про особенные особенности дефолтной политики цепочек иптаблес. Век жыви и все такое...

Оказывается, можно задать умолчательную политику iptables -P INPUT DROP, тогда специальное правило блокировки входящего трафика не нужно, но если потом, вдрук неподумавши, сделать iptables -F — можно лехко и непринужденно отвалиться от сервера и получить долгую дорогу к нему : )

Поэтому, в случае дефолтно-дропающей политики для входящей цепочки, перед iptables -F нужно всегда говорить iptables -P INPUT ACCEPT

А если хочется предсказуемости и не хочется долгой дороги к консоли — все дефолтные политики делаем ACCEPT, а правило DROP указываем явно, последним в цепочке. Такие дела )

@Dant:

Настройка и починка UFW на OpenVZ VPS. C ipv6 и протокольными модулями — обломсс : )

digitalocean.com
blog.kylemanna.com

@Dant:

Базовая настройка iptables на одиноком сервере:

iptables -L
iptables -S
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -i eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -i eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -i eth0 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -i eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -i eth0 -j ACCEPT
iptables -P INPUT DROP
iptables -L
iptables -S

ip6tables -L
ipt6ables -S
ip6tables -I INPUT 1 -i lo -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -p tcp --dport 22 -i eth0 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 443 -i eth0 -j ACCEPT
ip6tables -A INPUT -p udp --dport 53 -i eth0 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 53 -i eth0 -j ACCEPT
ip6tables -P INPUT DROP
ip6tables -L
ip6tables -S

apt-get install iptables-persistent
service iptables-persistent save
service iptables-persistent start
cat /etc/iptables/rules.v4
cat /etc/iptables/rules.v6

@Hawat:

Изучаю acl на Cisco, ну почему разработчики iptables не могли тупо скопипиздить? даже в сравнении с pf у cisco все выглядит проще.

@Hawat:

А насоветуйте литературы по теории построения фаерволов

@segfault:

На заметку мудаку: чтобы атомарно изменить правила iptables просто сохраняем их в файл iptables-save потом в удобном редакторе вносим нужные изменения, после чего, загружаем файл с помощью iptables-restore

@Gem:

conntrack выборочно включен
(через:
-t raw -A INPUT -s to_chto_nado -j ACCEPT
-t raw -A INPUT -j NOTRACK),
очереди прерываний настроены и прибиты к ядрам (чтобы не прыгали), RSS настроен, ring buffer-ы настрое Не выборочно эт ерунда. Если не нужен statefull firewall или nat лучше его вообще выключить +30% к производительности

@seeker:

эээ я что-то не понял а что -A INPUT -i eth0 -j DROP влияет и на raw пакеты?

@a2TH5:

Есть у кого готовый конфиг столов для марканья пакетов торрент-клиента, пущенного от выделенного юзера? Хочу наконец-то сделать человеческий QoS.

@Gem:

коменты про аспи восхитительны
opennet.ru

@side2k:

век живи — век учись. Заебавшись от того, что логи iptables срут в dmesg, наконец-то занялся этой проблемой, и за 5 минут нагуглил ulog. Помогло.

@power:

*facepalm
Удивительно здравый коммент среди хабраподобного метанирования.
Только в прыщеядро надо встроить кошерный guile :3

linux.org.ru
"Так в нетбсд вместо «стандартных библиотек» просто встроили lua script в ядро, да и не парятся. У них, судя по всему, скоро вообще один единственный синтаксис конфигурирования ядра останется, на все подсистемы...да еще обширные возможности пилить прототипы будущих реализаций появятся прямо в скриптах ядра. Вот, думаю, куда надо стремится, а не очередной синтаксис изобретать. Все же готовое есть, что велосипедить то. lua очень производительна, генерит байткод и в ядро как показывает нетбсд ее встроить реально...да и придумывалась lua как встраиваемый высокопроизводительный скрипт."

Синтаксис им непривычный, блядь, после iptables. Инертные долбоебы.

@Annoynimous:

Чят, покажи iptables -L своей ППЭВМ.

@segfault:

Когда-то был ман по команде iptables, он был ооочень длинный и в нем были абсолютно все параметры с подброным описанием. Сейчас я наблюдаю в системе только man 8 iptables который очень маленький, в нем даже -dport нету. В интернетах тоже не могу найти документацию, где взять ?

@mdma:

Я таки жуткий оригинал. Собрать на шлюз свежее ядро и забыть включить в нем поддержку IPv4 NAT. Слава Богу я в отпуск с понедельика! :)

@ComradeDOS:

Видимо я чего-то не понимаю...
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp — anywhere anywhere icmp echo-reply state RELATED,ESTABLISHED

@silvery:

$ iptables
Could not open socket to kernel: Operation not permitted

Телефон — Samsung Galaxy Mini. Интересно, это недорут виноват или официальная прошивка такова?

@seeker:

слушайте а в iptables никак нельзя списки позадавать? Ато мне надо на штук 20 ip открыть штук 5 сервсисов, в итоге конфиг получается сломиногу

@Marchael:

Открыл для себя замечательную опцию "-m comment --comment <comment>"

Всячески рекомендую юзать для документации правил при большом количестве оных.

@gabas:

Прошел боевое крещение: первая ddos атака на мой сервачок, видимо ботнет. Интересно, есть смысл писать заяву в отдел К и прикладывать список атакующих IP адресов?

@Turbid:

жуйк, ты почему скрывал от меня такую штуку как ipset? /me пошел переписывать костыли...

@ng358ex-2:

i.minus.com

@Offoffoff:

#читаю ман вслух и учусь пробрасывать порт через NAT
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -i ppp0 -j DNAT --to 192.168.1.2:80

@k1lg0reTr0ut:

вобщем, надо людям делать проброс из инета в локалку на порт 3389.
но. эти люди получают динамические ip. хотел просто ip заменять на доменные адреса, но бляяя, домен второго уровня содержит дефис, и либо дефис вопринимается кк диапазон, либо вообще не воспринимается, но нихрена не работает.
мне лень прописывать статику для каждого нового удаленника.
есть ли готовые варианты?

@k1lg0reTr0ut:

дано. файлик /etc/sysconfig/iptables
в файлике всякая байда.
вобщем я хочу в некоторых строках писать вместо ip доменные имена локальных хостов. на серваке эти локальные имена резолвятся. просто хост, или хост.домен.loc
вобщем, пишу в файле iptables:

вместо -A PREROUTING -s 217... -d 212... -p tcp -m tcp --dport 8083 -j DNAT --to-destination 192.168.0.135:8083
пишу так: -A PREROUTING -s 217... -d 212... -p tcp -m tcp --dport 8083 -j DNAT --to-destination ws135.blabla-blabla.loc:8083

при применении правил — пишет ошибку. типа нет такого хоста: "ws135.blabla"

похоже проблема в дефисе. хз чо делать. экранировать не получилось.
есть ли истории успеха?

@Turbid:

Кэширующий DNS-server на Debian: turbidit.blogspot.com

@wasd:

Есть такие наркоманские правила:
-A PREROUTING -d 62.76.189.64/32 -j DNAT --to-destination 213.141.144.39
-A POSTROUTING -d 213.141.144.39/32 -j SNAT --to-source 62.76.189.64

То есть, все пакеты, поступающие на 62.76.189.64 перенаправляются к 213.141.144.39, ну вы поняли. Всё вроде бы ок.

Теперь смотрим правила на самом 213.141.144.39:
-A POSTROUTING -d 172.16.0.55/32 -j SNAT --to-source 62.76.189.64
-A PREROUTING -s 62.76.189.64/32 -j DNAT --to-destination 172.16.0.55

То есть, все пакеты, пришедшие от 62.76.189.64 уходят на 172.16.0.55.
Выходит, все пакеты, которые ходят на 62.76.189.64, доходят на 172.16.0.55 моей внутренней сети и всё прекрасно работает.

some_host_from_net => 62.76.189.64 => 213.141.144.39 => 172.16.0.55 (грубо говоря, http-запрос)
172.16.0.55 => 213.141.144.39 => 62.76.189.64 => some_host_from_net (скажем, http-ответ)

Задача — все исходящие коннекты на 172.16.0.55 зароутить через 62.76.189.64. Если на 213.141.144.39 пишем так:
-A POSTROUTING -s 172.16.0.55/32 -j SNAT --to-source 62.76.189.64
то все пакеты зацикливаются и проходят такой путь:

172.16.0.55 => 213.141.144.39 => 62.76.189.64 => 213.141.144.39 => 172.16.0.55
Это не верно. Хост должен подбирать пакеты, пришедшие с 213.141.144.39 до 62.76.189.64 и не направлять их назад, а направить во внешнюю сеть. Как это реализовать?