Вопросы Теги

маршрутизировать трафик по определенному порту через определенный интерфейс?

Для справки посмотрите man sudo, man sudoers и т.д.

Вот пример для Linux, как настроить файл sudoers для выполнения служебного скрипта SYSV Linux от имени root.

Отредактируйте/создайте файл sudoers для пользователя (я буду использовать theusername):

visudo /etc/sudoers.d/theusername

Формат такой

# <user list> <host list> = <operator list> <tag list> <command list>

Вы захотите добавить эту строку:

theusername ALL = (root:root) NOPASSWD: /usr/sbin/service

Возможно, потребуется добавить пользователя theusername в группу sudo; подробности см. в другом моем ответе.

UPDATE

ОП (через комментарии) хочет выполнить следующее:

ProcessBuilder ntpProcessBuilder = new ProcessBuilder(
    "/bin/sh", "-c",
    "echo " + PUB_PASSWORD + 
    "| sudo -S bash -c \"cp -f " + ntp_conf_file_temp + " " + ntp_conf_file +
    "; service ntp reload\"" );

Для этого потребуется установить права доступа к файлам, чтобы иметь возможность переопределить ntp_conf_file, который, как мы предполагаем, принадлежит root. Подробности см. в другом ответе. Однако вот альтернативное решение, использующее скрипт, помещенный в /etc/ntp-update.sh:

#!/bin/bash
/bin/cp /etc/managed-ntp/temp.conf /etc/ntpd/ntp.conf
/usr/sbin/service ntp reload

Как вы видите, пути к файлам закодированы для безопасности.

Чтобы настроить его, мы редактируем файл sudoers для пользователя, чтобы дать ему доступ для запуска этого скрипта от имени root:

theusername ALL = (root:root) NOPASSWD: /etc/ntp-update.sh

И создаем каталог:

mkdir /etc/managed-ntp
chmod 2775 /etc/managed-ntp
chown theusername:theusergroup /etc/managed-ntp

2 в 2775 - это бит setgid, который гарантирует, что файлы, созданные в этом каталоге, будут принадлежать группе каталога. При работе от имени root это не обязательно, но может пригодиться.

Теперь приложение может сделать следующее:

// Make sure you write ntp_conf_file_tmp in /etc/managed-ntp/temp.conf!    
ProcessBuilder ntpProcessBuilder = new ProcessBuilder(
    "/usr/bin/sudo", "/etc/ntp-update.sh"
);
0
05.07.2018, 04:18
1 ответ

Маршрутизация осуществляется на уровне IP 3. TCP — на уровне 4, поэтому одной маршрутизации недостаточно для решения этой проблемы.

Короче говоря, :интересующий трафик должен быть помечен iptables, а помеченные пакеты выбраны с помощьюip ruleс fwmarkдля использования отдельной таблицы маршрутизации. Затем необходимо применить еще два исправления для случая локально инициированного/полученного трафика, что сложнее, чем случай с маршрутизацией. Все настройки, разумеется, выполняются в локальной системе.

Таблица маршрутизации80(соответствующее символическое имя может быть добавлено в /etc/iproute2/rt_tables, но это не обязательно )и метка 0x80была выбрана "произвольно". 

ip route add table 80 192.168.1.0/24 dev eth0 scope link src 192.168.1.56
ip route add table 80 default dev eth0 via 192.168.1.1

Использование -I, чтобы правила iptables не добавлялись слишком поздно. Вы должны проверить свои текущие правила, как изменить порядок, если это необходимо:

iptables -t mangle -N markports
iptables -t mangle -I PREROUTING 1 -j CONNMARK --restore-mark
iptables -t mangle -I OUTPUT 1 -m mark --mark 0 -j markports
iptables -t mangle -I OUTPUT 2 -j CONNMARK --save-mark
iptables -t mangle -A markports -p tcp --dport 80 -j MARK --set-mark 0x80
iptables -t mangle -A markports -p tcp --dport 443 -j MARK --set-mark 0x80

ip rule add fwmark 0x80 lookup 80

Этот блог:Netfilter Connmark » В Linux и дальше! дает хорошую информацию о CONNMARK.

Это должно было работать, но на самом деле при первом решении о маршрутизации был выбран неправильный исходящий IP-адрес по умолчанию, потому что маршрут должен был проходить через tun0. При проверке перенаправления, выполненной из-за метки mangle/OUTPUT(, см. этот Поток пакетов в схеме Netfilter and General Networking для разъяснения ), этот IP-адрес не изменится. Если бы обрабатываемый трафик маршрутизировался, а не инициировался локально, эта проблема не возникла бы (с использованием отдельного сетевого пространства имен, чтобы убедиться, что это решение для служб, а не для рабочего стола ). Так что это требует также слояMASQUERADE(или SNATдля более сложных случаев )поверх него:

iptables -t nat -I POSTROUTING 1 -m mark --mark 0x80 -j MASQUERADE

Теперь, когда исходящий IP-адрес правильный, он по-прежнему не работает :фильтр обратного пути срабатывает на обратном пути примерно по той же причине, :решение о маршрутизации, принятое ранее PREROUTINGпока не знает fwmark(, несмотря на предыдущую схему , помещающую mangle/PREROUTINGперед решением о маршрутизации,очевидно, это не так ), поэтому считает пакеты обратного трафика поддельными и отбрасывает их раньше. Интерфейс eth0rp_filterдолжен быть переведен в свободный режим, чтобы это было разрешено. Это может иметь некоторые (очень незначительные проблемы с безопасностью за NAT ), но я считаю это неизбежным для этого случая без -маршрутизации:

echo 2 > /proc/sys/net/ipv4/conf/eth0/rp_filter

Вам придется найти, как установить его на постоянной основе (например, echo net.ipv4.conf.eth0.rp_filter=2 > /etc/sysctl.d/90-local-loose-mode.conf, если ничего больше не изменит его позже ).

Протестировано нормально при использовании пространств имен с настройками, аналогичными параметрам операционной системы.

ПРИМЕЧАНИЕ. :DNS-запросы по-прежнему будут проходить через туннель. Некоторые геолокализованные веб-сервисы могут работать не так, как ожидалось.

2
28.01.2020, 04:19

Теги

Похожие вопросы