systemd-200: осторожно, /usr/lib/sysctl.d/

Если товарисчи мейнтейнеры хотя переписать конфиги, пускай пишут их в .pacnew, как во всех нормальных пакетах. Собственно, именно такого поведения я и добился манипуляцией с pacman.confЕсли товарисчи мейнтейнеры хотя переписать конфиги, пускай пишут их в .pacnew, как во всех нормальных пакетах. Собственно, именно такого поведения я и добился манипуляцией с pacman.conf
Ай, спасибо, дорогой Вы наш Человек
С мезой запарился- тупо переписывает drirc
Бум попробовать
P.S.
Что касается пресловутого параметра rp_filter, он может поломать сеть в некоторых специфических конфигурациях, когда используется SNAT для изменения source IP исходящих пакетов хоста. Мне известны как минимум два возможных варианта:

1) Две локальных сети (например 192.168.1.0/24 и 192.168.2.0/24) соединены туннелем. В каждой из них адреса другой сети маршрутизируются через шлюз, но адреса концов туннеля (10.0.0.1 и 10.0.0.2) по каким-то причинам не принадлежат ни одной из этих сетей, и не маршрутизируются в них. В результате из одной сети доступна другая сеть, но с самого шлюза, поддерживающего туннель, она недоступна, потому что source IP его исходящих пакетов это адрес 10.0.0.1 в туннеле, а не его же адрес 192.168.1.1 в локалке. Если нет возможности настроить SNAT для адресов туннеля на другом его конце, проблема решается и на этом конце, подменой IP туннеля на IP локалки:
iptables -t nat -A POSTROUTING -s 10.0.0.1 -d 192.168.2.0/24 -j SNAT --to-source 192.168.1.1

2) Если на хосте используется полиси-роутинг исходящих соединений хоста, их изначально назначенный source IP может не соответствовать IP выбранного в результате роутинга интерфейса. Эта проблема также решается заменой source IP через SNAT или маскарадинг, к примеру:
iptables -t nat -A POSTROUTING -o tun1 ! -s 10.1.0.0/16 -j MASQUERADE
Здесь маскарадинг выполняется для уходящих в VPN соединений, source IP которых НЕ принадлежат диапазону этой VPN.

В обоих этих случаях (как выяснилось, только во втором случае) включение параметра rp_filter молча заблокирует вернувшиеся из интерфейса пакеты, причём tcpdump покажет, что они пришли, а ожидающее их приложение ничего не получит.
iptables -t nat -A POSTROUTING -s 10.0.0.1 -d 192.168.2.0/24 -j SNAT --to-source 192.168.1.1
А если добавить такое правило:
iptables -t nat -A PREROUTING -s 192.168.2.0/24 -d 192.168.1.1 -j DNAT --to 10.0.0.1
будет ли влиять ли на него параметр rp_filter?
SergeiX, не знаю, врать не буду.
Но есть способ проверить – просто попробовать :)
Правда, я не очень понял смысл этого действия. Можно поподробнее?

P.S.
Ну вот, выяснилось (уже проверил), что в случае подмены адреса без изменения интерфейса rp_filter не мешает. Всё дело именно в полиси-роутинге, а не в подмене IP через SNAT – этот параметр заставляет ядро отбрасывать ответные пакеты, если они пришли не с того интерфейса, откуда "ожидалось", согласно таблице main. В случае полиси-роутинга таблиц много, и "ожидания" rp_filter идут лесом, он не может правильно предсказать результат столь сложных операций.

В LARTC (перевод этого места) упоминается другой, более простой случай, когда Reverse Path Filtering (rp_filter) требуется отключать – это ассиметричный роутинг, когда ответные пакеты действительно приходят через другой интерфейс.
Прописал NoUpgrade = etc/sysctl.conf usr/lib/sysctl.d/*, надеюсь безобидно.
"If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding. —Aaron Griffin
 
Зарегистрироваться или войдите чтобы оставить сообщение.