to post messages and comments.

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

В настройках 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, а на адрес другого интерфейса… Хотя, там же в этом дополнительном правиле и не говорится ничего про интерфейс (почему?).

Я прописал правило:
$ 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
и этих пакетов не вижу! Они почему-то не доходят… Где же они теряются?

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

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

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

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

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

Чтобы 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

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

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

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

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

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

Базовая настройка 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

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

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

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

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

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

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

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

дано. файлик /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"

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

Есть такие наркоманские правила:
-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 и не направлять их назад, а направить во внешнюю сеть. Как это реализовать?