Работа различных скриптов с различными сетевыми интерфейсами.

[sensei88]

Добрый день. Имеется два интерфейса:
br0 - статика, смотрит в локалку, через NAT (маршрутизатор) локалка выходит в инет, белый адрес у маршрутизатора динамический.
br1 - динамический белый адрес, смотрящий в интернет

Общая задача: разграничить обращение к интерфейсам различных скриптов

В чём собственно проблема: Если разные интерфейсы работают с разными подсетями, то всё относительно просто решается правилами iptables. Но в нашем случае оба интерфейса работают с одинаковыми адресами.

Для чего возникает такая задача:
Реальная задача 1:
Нужно обновлять A-записи на Яндекс.DNS для обоих адресов. На br1, условно д.б. domain.ru и sub1.domain.ru. Тот, что на маршрутизаторе, условно д.б. sub2.domain.ru.
При этом нужен скрипт, в котором можно было бы прописать:
1) обратись по интерфейсу br0, узнай белый адрес, отправь запрос в DNS с интерфейса br0.
2) обратись по интерфейсу br1, узнай белый адрес, отправь запрос в DNS с интерфейса br1.

Реальная задача 2:
Разрешить SSH-доступ только по интерфейсу br0 и только с адресов локалки. Вариант рубить только по адресам не катит: имеется техническая возможность для злоумышленников имитировать такую же локалку на интерфейсе br1.

Заранее спасибо всем, кто откликнется. Заранее прошу прощения, если нечто подобное уже рассматривалось и есть готовый ответ. Честно искал - не нашел. Как вы уже догадались, в Linuxе я начинающий. Прошу не пинать больно.

[AnrDaemon]

Реальная задача 2 решается именно так, как изложена.

[fisher74]

Нужно обновлять A-записи на Яндекс.DNS для обоих адресов.
...
При этом нужен скрипт, в котором можно было бы прописать:

Я предполагаю, что есть соответствующий софт от Яндекса. Доки к нему и курить.
Предполагаю, потому что никогда не сталкивался с этим Яндекс-сервисом

[sensei88]

Я предполагаю, что есть соответствующий софт от Яндекса. Доки к нему и курить.
Предполагаю, потому что никогда не сталкивался с этим Яндекс-сервисом

Вопрос не в том, как обращаться к яндексу. Там все решается простейшим bash-скриптом с парой https запросов.
Вопрос в том, как работать с несколькими интерфейсами. Т.е. как выполнить один скрипт с https-запросами с одного интерфейса, второй скрипт - с другого. Оба скрипта обращаются к одному и тому же серверу, поэтому таблицей маршрутизации вопрос не решить.
Там еше есть ряд подзадач, которые я не написал. Например, Apache должен работать только с br1. Т.е. в общем задача разрешать разному ПО работать через разные интерфейсы. Или вообще пока определить интерфейс только для одного конкретного запроса.

Один знакомый Linuxоид вспрмнил, что в какой-то версии iptables можно было назначать маршруты только для отделтных программ и скриптов. Но он не помнит как и вроде в последних версиях Ubuntu Server эту фичу убрали. Сам в доках по iptables ничего такого не нашел. Может, есть более изящное решение?

[fisher74]

Вопрос не в том, как обращаться к яндексу.

А я и не говорю, что вопрос был как обращаться к Яндексу.

Там все решается простейшим bash-скриптом с парой https запросов.
Вопрос в том, как работать с несколькими интерфейсами. Т.е. как выполнить один скрипт с https-запросами с одного интерфейса, второй скрипт - с другого. Оба скрипта обращаются к одному и тому же серверу, поэтому таблицей маршрутизации вопрос не решить.

так проанализируйте скрипт и посмотрите, как он определяет адрес клиента.

Один знакомый Linuxоид вспрмнил, что в какой-то версии iptables можно было назначать маршруты только для отделтных программ и скриптов. Но он не помнит как и вроде в последних версиях Ubuntu Server эту фичу убрали. Сам в доках по iptables ничего такого не нашел. Может, есть более изящное решение?

Плохо искали. Только меняется не маршрут, а source-address, хотя если промаркировать и заюзать iproute2...
Но Вам это не поможет, так как скорее всего на интернет-интерфейсе работает маскарадинг.

[sensei88]

Сформулирую вопрос по-другому.
Как составить отдельные правила маршрутизации для отдельного процесса (демона или скрипта)?

[fisher74]

Вам это всё равно не поможет, так как source-address будет один и тот же.
нужно разобраться в механизме обновления на Яндексе. Вполне вероятно, что это невозможно

[sensei88]

Вам это всё равно не поможет, так как source-address будет один и тот же.
нужно разобраться в механизме обновления на Яндексе. Вполне вероятно, что это невозможно

Тогда, получается, также невозможно будет в дальнейшем, допустим, использовать в качестве ip route add default dev br0, а для отдельных служб, таких, как Apache и FTP назначить dev br1?

[fisher74]

У Вас в голове каша из уровней OSI (если Вы, конечно, вообще знаете что это такое). Освежите на досуге представление о ней.
Маршруты делаются не  для сервисов, а для сетевых пакетов.
Сервисы же открывают свои порты на определённых интерфейсах и с какой стороны к ним будут стучаться им совершенно фиолетово. И в какую сторону полетит пакет с интерфейса на котором они работают так же по барабану.
Из-за того, что заблудились в пакетной маршрутизации, Вы смотрите на маршруты (routes - дороги) и никак не сообразите поднять голову и узнать, что есть ещё шоры для сетевых пакетов, которые называются netfilter (который управляется iptables)
И опять же. Если веб-сервер будет работать на ip-адресе локальной сети, то снаружи к нему никто не попадёт, так как локальные адреса в интернет не попадают.

(Нажмите, чтобы показать/скрыть)

P.S. Объяснения немного грубые и в некоторых моментах возможно кривлю душой, но это для "начальной школы"

[sensei88]

У Вас в голове каша из уровней OSI (если Вы, конечно, вообще знаете что это такое). Освежите на досуге представление о ней.
Маршруты делаются не  для сервисов, а для сетевых пакетов.
Сервисы же открывают свои порты на определённых интерфейсах и с какой стороны к ним будут стучаться им совершенно фиолетово. И в какую сторону полетит пакет с интерфейса на котором они работают так же по барабану.
Из-за того, что заблудились в пакетной маршрутизации, Вы смотрите на маршруты (routes - дороги) и никак не сообразите поднять голову и узнать, что есть ещё шоры для сетевых пакетов, которые называются netfilter (который управляется iptables)

Про семиуровневую, конечно же, знаю. Если бы сам не пришел сюда с вопросом, посчитал бы ваш ответ оскорблением. Не до такой степени я тёмный человек, хотя с Linuxом пока ещё на Вы. Вопрос в другом - какая утилита Linuxа чем управляет: и вот тут, признаюсь, я, действительно, путаюсь. Читаю доки вечерами, постепенно все встает на места, но ответа на свой вопрос пока не нашел.

И опять же. Если веб-сервер будет работать на ip-адресе локальной сети, то снаружи к нему никто не попадёт, так как локальные адреса в интернет не попадают.

Про локальный адрес: на нем web-сервер работать не будет. Ранее я писал:

а для отдельных служб, таких, как Apache и FTP назначить dev br1?

где

br1 - динамический белый адрес, смотрящий в интернет

Интерфейс с локальным адресом нужен этой машине для администрирования, для Samba в локалке и, возможно, для Asterisk в обозримом будуем. Делать все на одном сервере - это, на мой взгляд, приемлемое SOHO-решение.
Локальная сеть сидит за бытовым роутером, через который можно спокойно стучаться во вне. Внешний адрес этого роутера динамический, на нем планируется поднять VPN-сервер плюс на нем проброшены порты для машин в локалке со своими собственными службами, к которым сейчас доступ извне идет через бесплатный аккаунт на dyndns. С dyndns переходим на Яндекс для доступа под своим доменным именем и без тараканов бесплатного dyndns. Средствами роутера обновлять записи в DNS яндекса не получается: там curl куцый стоит, а добытый из сторонних источников не захотел работать вообще. При этом пулять по кронтабу пару https-запросов со стороны машины к яндексу через dev br0 не сильно сложно? но решило бы проблему. Делать из машины еще и роутер, когда есть нормально работающая железка, не хотелось бы. На нее итак планируется навешать немало задач. Отдельное аппаратное решение справится с задачами розлива инета по машинам лучше.
P.S.: Ну я уже вообще все описал вам.
Пользователь решил продолжить мысль 21 Сентября 2013, 00:21:24:Спасение утопающих - дело рук самих утопающих.
В демоне обновления данных DNS прописываем:

Код: [Выделить]

curl -s --interface br0 АДРЕСИ на всякий случай в iptables добавляем:

Код: [Выделить]

PID=`ps aux |grep ИМЯ_СКРИПТА |head -n 1 |cut -b 10-14`
iptables -A OUTPUT -p TCP -o br0 -m owner --pid-owner $PID -j ACCEPT
iptables -A OUTPUT -p TCP -o br1 -m owner --pid-owner $PID -j DROP

[ArcFi]

iptables -A OUTPUT -p TCP -o br0 -m owner --pid-owner $PID -j ACCEPT
iptables -A OUTPUT -p TCP -o br1 -m owner --pid-owner $PID -j DROP

Что-то вы не то делаете, "--pid-owner" уже давно выпилили.

[fisher74]

Спасение утопающих - дело рук самих утопающих.
В демоне обновления данных DNS прописываем:

Код: [Выделить]

curl -s --interface br0 АДРЕС

Извините, мы так и не смогли стелепатить каким же скриптом Вы обновляете DNS.