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

ivand	# 9 лет, 4 месяца назад
Темы: 9 Сообщения: 477 Участник с: 04 января 2013	Если товарисчи мейнтейнеры хотя переписать конфиги, пускай пишут их в .pacnew, как во всех нормальных пакетах. Собственно, именно такого поведения я и добился манипуляцией с pacman.confЕсли товарисчи мейнтейнеры хотя переписать конфиги, пускай пишут их в .pacnew, как во всех нормальных пакетах. Собственно, именно такого поведения я и добился манипуляцией с pacman.conf Ай, спасибо, дорогой Вы наш Человек С мезой запарился- тупо переписывает drirc Бум попробовать

# 9 лет, 4 месяца назад

Сообщения: 477

Участник с: 04 января 2013

Если товарисчи мейнтейнеры хотя переписать конфиги, пускай пишут их в .pacnew, как во всех нормальных пакетах. Собственно, именно такого поведения я и добился манипуляцией с pacman.confЕсли товарисчи мейнтейнеры хотя переписать конфиги, пускай пишут их в .pacnew, как во всех нормальных пакетах. Собственно, именно такого поведения я и добился манипуляцией с pacman.conf

Ай, спасибо, дорогой Вы наш Человек
С мезой запарился- тупо переписывает drirc
Бум попробовать

Natrio	# 9 лет, 4 месяца назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	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 покажет, что они пришли, а ожидающее их приложение ничего не получит.

Natrio

# 9 лет, 4 месяца назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

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 покажет, что они пришли, а ожидающее их приложение ничего не получит.

SergeiX	# 9 лет, 4 месяца назад
Темы: 0 Сообщения: 1 Участник с: 08 апреля 2013	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?

Natrio	# 9 лет, 4 месяца назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	SergeiX, не знаю, врать не буду. Но есть способ проверить – просто попробовать :) Правда, я не очень понял смысл этого действия. Можно поподробнее? P.S. Ну вот, выяснилось (уже проверил), что в случае подмены адреса без изменения интерфейса rp_filter не мешает. Всё дело именно в полиси-роутинге, а не в подмене IP через SNAT – этот параметр заставляет ядро отбрасывать ответные пакеты, если они пришли не с того интерфейса, откуда "ожидалось", согласно таблице main. В случае полиси-роутинга таблиц много, и "ожидания" rp_filter идут лесом, он не может правильно предсказать результат столь сложных операций. В LARTC (перевод этого места) упоминается другой, более простой случай, когда Reverse Path Filtering (rp_filter) требуется отключать – это ассиметричный роутинг, когда ответные пакеты действительно приходят через другой интерфейс.

Natrio

# 9 лет, 4 месяца назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

SergeiX, не знаю, врать не буду.
Но есть способ проверить – просто попробовать :)
Правда, я не очень понял смысл этого действия. Можно поподробнее?

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

В LARTC (перевод этого места) упоминается другой, более простой случай, когда Reverse Path Filtering (rp_filter) требуется отключать – это ассиметричный роутинг, когда ответные пакеты действительно приходят через другой интерфейс.

samson4747	# 9 лет, 4 месяца назад
Темы: 33 Сообщения: 534 Участник с: 23 февраля 2012	Прописал 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