LINUX.ORG.RU
Форум — Admin  

Проблемы с настройкой маршрутизации в Centos7 - 3 внешних канала

 , ,


0

1

Маленькая предыстория: был сервак с настроенными правилами - 3 внешних канала, openvpn, локалка с серваками все было хорошно, но сервак устарел - он налит в 2005ом Centos 4

на новую железку был налит Centos7 и тут начались проблемы: а именно проблема с пробросом портов на дополнительные каналы

те есть канал основной - оптика и есть пара медных резевов внутри локальной сети есть сервера, порты которых выставляются наружу к примеру ip 10.10.10.100 - маршрутизируется на основной канал
ip 10.10.10.101 - маршрутизируется на резерв 1
ip 10.10.10.102 - маршрутизируется на резерв 2
ну и обратно - порт 80 резерва 1 идет на 10.10.10.101:80 итд

  • 1. исходящие пакеты прекрасно уходят с сервера, маршрутизируются и выходят с нужного интерфейса ответы приходят на нужный интерфейс и тут начинается мистика

    те на интерфейсе (tcpdump) пакет есть
    далее в таблице MANGLE:PREROUTING тоже есть
    далее отрабатывается правило
    -A PREROUTING -m state --state ESTABLISHED,RELATED -j ACCEPT
    но вот в NAT:PREROUTING пакетов уже нет

  • 2. обработка входящего соединения на пробрасываемый порт
    MANGLE:PREROUTING - есть
    NAT:PREROUTING - есть
    отрабатвается правило с DNAT на локальный сервер
    далее пакеты теряются те не приходят ни в MANGLE:INPUT ни в MANGLE:FORWARD
  • 3. обработка входящего соединения на порт обрабатываемый локально - тут все проходит без проблем

если по п2 можно предположить, что пакеты куда-то зароутились с концами, то пропадание пакетов по п1 вообще не понятно тк согласно документации после MANGLE:PREROUTING идет NAT:PREROUTING

соответственно вопросы

  • что поменялось в iptables и iproute2, что ранее рабочая конфигурация отказывается работать и таким странным образом?
  • куда копать - те как устранить эту проблему ?


Последнее исправление: cetjs2 (всего исправлений: 2)
← Оплатил настройку шлюза centos 7 инет + локаль + Wi-Fi
упала система (initramfs) после запуска victoria →

поменялись ядра, модули, их названия, переменные sysctl, дети выросли за 15 лет... проще переписать

и чисто поржать, зачем в мангл прероуте ESTABLISHED,RELATED ?

anonymous
()
Ответ на: комментарий от anonymous

давайте конкретнее те какие изменения влияет на маршрутизацию и работу iptables ?

касаемо MANGLE:PREROUTING
она используется для маркировки пакетов и первичной фильтрации
те в нем все входные порты итд итп
и политика у нее :PREROUTING DROP [0:0]

-m state --state конечно устарел, но замена на современный аналог результата не дает.

согласно схемы http://inai.de/images/nf-packet-flow.png
это вполне корректно

или я что-то пропустил ?

да, таблицы raw и security имеют политику accept
аналогично и ebtables
arptables не установлено

Nagisa
() автор топика

Красивое описание, чего-то не хватает правда... Ах да, самой мелочи, выхлопа следующих команд:

ip addr
ip rule
ip route
ip route show table t1 (и так по каждой таблице маршрутизации для каждого канала)
iptables-save
Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

не могу сказать, что конфиги сильно большие, но только iptables весит почти 50КБ, соответственно напрягать чтением такого объема будет просто невежливо с моей стороны.

еще выявил проблему с маршрутизацией из основной сети в сеть через тоннель openvpn

те интерфейс удаленной сети есть, а вот подсети не маршрутизируется совсем.

в связи с этим родилось подозрение что, что-то поменялось в iproute2 и мои конфиги неверны в современном понимании

итак
основной канал - AAA.AAA.AAA
резерв 1 - BBB.BBB.BBB
резерв 2 - CCC.CCC.CCC 

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:19:bb:3e:2e:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global enp3s0
       valid_lft forever preferred_lft forever
    inet6 fe80::219:bbff:fe3e:2ef0/64 scope link
       valid_lft forever preferred_lft forever
3: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:19:bb:3e:2e:da brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global enp5s0
       valid_lft forever preferred_lft forever
4: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 6c:b3:11:31:d6:6a brd ff:ff:ff:ff:ff:ff
    inet AAA.AAA.AAA.57/29 brd AAA.AAA.AAA.63 scope global ens1f0
       valid_lft forever preferred_lft forever
    inet AAA.AAA.AAA.58/29 brd AAA.AAA.AAA.63 scope global secondary ens1f0
       valid_lft forever preferred_lft forever
    inet AAA.AAA.AAA.59/29 brd AAA.AAA.AAA.63 scope global secondary ens1f0
       valid_lft forever preferred_lft forever
    inet AAA.AAA.AAA.60/29 brd AAA.AAA.AAA.63 scope global secondary ens1f0
       valid_lft forever preferred_lft forever
    inet AAA.AAA.AAA.61/29 brd AAA.AAA.AAA.63 scope global secondary ens1f0
       valid_lft forever preferred_lft forever
5: ens1f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 6c:b3:11:31:d6:6b brd ff:ff:ff:ff:ff:ff
6: ens2f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 6c:b3:11:31:d5:50 brd ff:ff:ff:ff:ff:ff
    inet BBB.BBB.BBB.56/27 brd BBB.BBB.BBB.63 scope global ens2f0
       valid_lft forever preferred_lft forever
7: ens2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 6c:b3:11:31:d5:51 brd ff:ff:ff:ff:ff:ff
    inet CCC.CCC.CCC.70/24 brd CCC.CCC.CCC.255 scope global ens2f1
       valid_lft forever preferred_lft forever
37: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 192.168.1.1 peer 192.168.1.2/32 scope global tun0
       valid_lft forever preferred_lft forever

OpenVPN - 192.168.1.1
подсеть подключенная через OpenVPN - 192.168.9.1

ens1f1 и enp5s0 - в резерве

# ip rule
0:      from all lookup local
30817:  from all to DNS fwmark 0xbf3 lookup T3
30818:  from DNS fwmark 0xbf3 lookup T3

30841:  from all to BBB.BBB.BBB.1 fwmark 0x3e8 lookup T0
30842:  from BBB.BBB.BBB.1 fwmark 0x3e8 lookup T0

30852:  from 192.168.0.102 fwmark 0x66 lookup T2
30853:  from 192.168.0.101 fwmark 0x65 lookup T0
30854:  from 192.168.0.100 fwmark 0x64 lookup T3

30863:  from AAA.AAA.AAA.61 lookup T3
30864:  from AAA.AAA.AAA.60 lookup T3
30865:  from AAA.AAA.AAA.59 lookup T3
30866:  from AAA.AAA.AAA.58 lookup T3
30867:  from AAA.AAA.AAA.57 lookup T3
30868:  from CCC.CCC.CCC.70 lookup T2
30869:  from BBB.BBB.BBB.56 lookup T0
32766:  from all lookup main
32767:  from all lookup default

30817: from all to DNS fwmark 0xbf3 lookup T3
30818: from DNS fwmark 0xbf3 lookup T3
прочее это маршруты к DNS-ам и прочему локальному у провайдеров

# ip route
default via AAA.AAA.AAA.62 dev ens1f0 metric 9
BBB.BBB.BBB.32/27 dev ens2f0 proto kernel scope link src BBB.BBB.BBB.56 metric 100
CCC.CCC.CCC.0 dev ens2f1 scope link src CCC.CCC.CCC.70
CCC.CCC.CCC.0/24 dev ens2f1 proto kernel scope link src CCC.CCC.CCC.70 metric 100
AAA.AAA.AAA.56/29 dev ens1f0 scope link src AAA.AAA.AAA.57
AAA.AAA.AAA.56/29 dev ens1f0 proto kernel scope link src AAA.AAA.AAA.57 metric 100
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.1 metric 100
192.168.1.0/24 via 192.168.1.2 dev tun0
192.168.1.2 dev tun0 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev enp5s0 proto kernel scope link src 192.168.2.1 metric 100
192.168.9.0/24 via 192.168.1.2 dev tun0
192.168.34.0/24 via 192.168.1.2 dev tun0

таблицы соответственно T0 T2 - резервы, T3 основной

# ip route show table T0
default via BBB.BBB.BBB.33 dev ens2f0
BBB.BBB.BBB.32 dev ens2f0 scope link src BBB.BBB.BBB.56
127.0.0.0/8 dev lo scope link
192.168.0.0/24 dev enp3s0 scope link src 192.168.0.1
192.168.1.0/24 dev tun0 scope link src 192.168.1.1
192.168.9.0/24 dev tun0 scope link src 192.168.1.1
192.168.34.0/24 dev tun0 scope link src 192.168.1.1


# ip route show table T2
default via CCC.CCC.CCC.1 dev ens2f1
CCC.CCC.CCC.0 dev ens2f1 scope link src CCC.CCC.CCC.70
127.0.0.0/8 dev lo scope link
192.168.0.0/24 dev enp3s0 scope link src 192.168.0.1
192.168.1.0/24 dev tun0 scope link src 192.168.1.1
192.168.9.0/24 dev tun0 scope link src 192.168.1.1
192.168.34.0/24 dev tun0 scope link src 192.168.1.1



# ip route show table T3
default via AAA.AAA.AAA.62 dev ens1f0 src AAA.AAA.AAA.60
127.0.0.0/8 dev lo scope link
192.168.0.0/24 dev enp3s0 scope link src 192.168.0.1
192.168.1.0/24 dev tun0 scope link src 192.168.1.1
192.168.9.0/24 dev tun0 scope link src 192.168.1.1
192.168.34.0/24 dev tun0 scope link src 192.168.1.1

продолжение следует

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

Обрезал iptables дабы сохранить смысл но и не засорять 

*mangle
:PREROUTING DROP [0:0]
# маркировка исходящего трафика для маршрутизации (iproute2)
-A PREROUTING -i enp3s0 -s 192.168.0.100 -j MARK --set-mark 100
-A PREROUTING -i enp3s0 -s 192.168.0.101 -j MARK --set-mark 101
-A PREROUTING -i enp3s0 -s 192.168.0.102 -j MARK --set-mark 102
# принимаем все с локального интерфейса
-A PREROUTING -i enp3s0 -j ACCEPT
-A PREROUTING -i lo -j ACCEPT    
# принимаем все с OpenVPN
-A PREROUTING -i tun+ -j ACCEPT  
-A PREROUTING -i tap+ -j ACCEPT 
# принимаем установивщиеся соединения
-A PREROUTING -m conntrack --ctstate ESTABLISHED -j ACCEPT 
#icmp - пока на все отвечаем
-A PREROUTING -d BBB.BBB.BBB.56   -p icmp --icmp-type any -j ACCEPT	
итд
#фильтры подробно
#web 
-A PREROUTING -i ens2f0 -d BBB.BBB.BBB.56 -p tcp --destination-port 80 -j ACCEPT 
-A PREROUTING -i ens2f0 -d BBB.BBB.BBB.56 -p tcp --destination-port 443 -j ACCEPT 
-A PREROUTING -i ens2f1 -d CCC.CCC.CCC.70  -p tcp --destination-port 80 -j ACCEPT 
-A PREROUTING -i ens2f1 -d CCC.CCC.CCC.70  -p tcp --destination-port 443 -j ACCEPT 
-A PREROUTING -i ens1f0 -d AAA.AAA.AAA.57 -p tcp --destination-port 80  -j ACCEPT 
-A PREROUTING -i ens1f0 -d AAA.AAA.AAA.57 -p tcp --destination-port 443 -j ACCEPT 

:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# маркировка внутренних процессов
# DNS 
-A OUTPUT -d DNS -j MARK --set-mark 1000
# DNS 
-A OUTPUT -d DNS  -j MARK --set-mark 2000
-A OUTPUT -d DNS  -j MARK --set-mark 2000
-A OUTPUT -d DNS  -j MARK --set-mark 2000
-A OUTPUT -d DNS  -j MARK --set-mark 2000
# DNS 
-A OUTPUT -d DNS    -j MARK --set-mark 3000
-A OUTPUT -d DNS    -j MARK --set-mark 3000
COMMIT
#############################################################################################
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i enp3s0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 53 -j ACCEPT
-A INPUT -p tcp --dport 25 -j ACCEPT	
итд итп
# принимаем все с тунеля openvpn
-A INPUT -i tun+ -j ACCEPT 
-A INPUT -i tap+ -j ACCEPT  
# отвечаем на все ICMP
-A INPUT -p icmp --icmp-type any -j ACCEPT
# поддерживаем установленные соединения
-A INPUT -m conntrack --ctstate ESTABLISHED  -j ACCEPT
#остатки убиваем
-A INPUT -j DROP
#форвардим
#WEB ens1f0
-A FORWARD -p tcp --destination-port 80    -d 192.168.0.100 -j ACCEPT	
-A FORWARD -p tcp --destination-port 443   -d 192.168.0.100 -j ACCEPT	
#WEB ens2f0
-A FORWARD -p tcp --destination-port 80    -d 192.168.0.101 -j ACCEPT	
-A FORWARD -p tcp --destination-port 443   -d 192.168.0.101 -j ACCEPT	
#WEB ens2f1
-A FORWARD -p tcp --destination-port 80    -d 192.168.0.102 -j ACCEPT	
-A FORWARD -p tcp --destination-port 443   -d 192.168.0.102 -j ACCEPT	
-A FORWARD -j DROP
COMMIT
#############################################################################################
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -s 192.168.0.100    --out-interface ens1f0 -j SNAT --to-source  AAA.AAA.AAA.60
-A POSTROUTING -s 192.168.0.101    --out-interface ens2f0 -j SNAT --to-source  BBB.BBB.BBB.56
-A POSTROUTING -s 192.168.0.102    --out-interface ens2f1 -j SNAT --to-source  CCC.CCC.CCC.70
# маршрутизация внутренних процессов
-A POSTROUTING  -m mark --mark 1000  --out-interface ens2f0   -j SNAT --to-source BBB.BBB.BBB.56
-A POSTROUTING  -m mark --mark 2000  --out-interface ens2f1   -j SNAT --to-source CCC.CCC.CCC.70
-A POSTROUTING  -m mark --mark 3000  --out-interface ens1f0   -j SNAT --to-source AAA.AAA.AAA.58
###########################################################################################################

#персональный NAT для fido
#ens1f0 WEB
-A PREROUTING -i ens1f0  -d  AAA.AAA.AAA.57 -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.100:80
-A PREROUTING -i ens1f0  -d  AAA.AAA.AAA.57 -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.100:443
#ens2f0 WEB
-A PREROUTING -i ens2f0  -d  BBB.BBB.BBB.56 -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.101:80
-A PREROUTING -i ens2f0  -d  BBB.BBB.BBB.56 -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.101:443
#ens2f1 WEB
-A PREROUTING -i ens2f1  -d  CCC.CCC.CCC.70  -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.102:80 
-A PREROUTING -i ens2f1  -d  CCC.CCC.CCC.70  -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.102:443
###########################################################################################################
COMMIT

вроде тег cut вставил а спойлера не получилось

Nagisa
() автор топика
Ответ на: комментарий от Nagisa 
-A FORWARD -p tcp --destination-port 80    -d 192.168.0.100 -j ACCEPT

это разрешает запрос к веб серверу, а где ответ?

*mangle :PREROUTING DROP [0:0]

Это нафига? Вроде как фильтровать принято в filter:INPUT и filter:FORWARD

А как раз filter у вас ACCEPT по умолчанию (хоть и в конце цепочки DROP есть)...

вроде тег cut вставил а спойлера не получилось

он вроде как только в новостях работает

samson ★★
()
Последнее исправление: samson (всего исправлений: 1)
Ответ на: комментарий от samson

Тсс. Он же показал картинку, что контрек в мангле есть. А то что разработчики пишут не фильтовать в мангле, так то для остальных)

anonymous
()
Ответ на: комментарий от anonymous

Не вдавался в подробности маршрутизации, mark connection итд...

Тупо на форвард хотел обратить внимание: 

-A FORWARD -p tcp --destination-port 80    -d 192.168.0.100 -j ACCEPT	
-A FORWARD -p tcp --destination-port 443   -d 192.168.0.100 -j ACCEPT	
#WEB ens2f0
-A FORWARD -p tcp --destination-port 80    -d 192.168.0.101 -j ACCEPT	
-A FORWARD -p tcp --destination-port 443   -d 192.168.0.101 -j ACCEPT	
#WEB ens2f1
-A FORWARD -p tcp --destination-port 80    -d 192.168.0.102 -j ACCEPT	
-A FORWARD -p tcp --destination-port 443   -d 192.168.0.102 -j ACCEPT	
-A FORWARD -j DROP
Этого же уже не достаточно, что бы не зарезать (разрешить) транзитные пакеты.

samson ★★
()
Ответ на: комментарий от samson

Этого же уже не достаточно, что бы не зарезать (разрешить) транзитные пакеты.

интересно, прошу конкретнее но, я уже писал, что на основном-то канале проблем нет те с основного канала все сервисы работают и маршрутизируются куда надо, проблема локализована _только_ на резервных каналах. (это работает тк сейчас там политика ACCEPT)

это разрешает запрос к веб серверу, а где ответ?

cм исходное п1 - исходящие пакеты прекрасно уходят, входящие на основной канал тоже.

А то что разработчики пишут не фильтовать в мангле, так то для остальных

да я в курсе, просто фильтровать на входе удобнее - тк получается _один_ формализованный список сервисов (и не важно локальные они или маршрутизируемые куда-то на другие железки) (да и за 12 лет никаких проблем не выявлено, собственно единственное основание замены сервера - стали дохнуть SCSI винты - тк они уже на «втором круге» - те >65535 часов отработали)

а DROP-ы и ACCEPT это следы поиска глюков

ps: перечитал еще раз настоятельные рекомендации не использовать MANGLE для фильтрации - попробую переписать в фильтр.

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

имел ввиду, что у вас в forward все режется - это как минимум. Сами посмотрите, что разрешают вышепиведенные правила? 

-p tcp --destination-port 80    -d 192.168.0.100

а в конце чепочки forward стоит -j DROP.

разрешены только tcp пакеты с адресом назначения 192.168.0.100:80 (аналогично для других ip:port), все остальное зарезается правилом -j DROP. Трафик через filter:forward не ходит. Как вообще фоть что то в такой конфигурации рабоатет? Ни на основном ни на каком другом работать ничего не должно

samson ★★
()
Последнее исправление: samson (всего исправлений: 1)
Ответ на: комментарий от Nagisa

ps: да и остальные правила iptables составлены мягко говоря не айс. Метки ставьте в mangle, фильтруйте в filter, подмену адресов (nat) в nat. Все сразу станет понятно и логично. Таблицы же не просто так называются именно такими именами...

по поводу маршрутизации, если нет четкого понимания, что да как, посмотрите на хабре для начала: https://habrahabr.ru/post/108690/

там куча статей, где подробоно расжевывается про iproute2+iptables

samson ★★
()
Последнее исправление: samson (всего исправлений: 1)
Ответ на: комментарий от samson

итого вынес фильтрацию в FILTER проблема осталась.

Как вообще фоть что то в такой конфигурации рабоатет?

там была политика accept

по поводу маршрутизации, если нет четкого понимания, что да как, посмотрите на хабре для начала: https://habrahabr.ru/post/108690/

;-) у меня эти три канала появились куда раньше этой статьи и все _работало_ на Centos4.

вопрос почему рабочая конфигурация не работает на Centos7.4 особо интересно как пакет прошедший MANGLE:PREROUTING не может дойти до NAT:PREROUTING

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

там была политика accept

а завершающее действие -j DROP - то же самое что DROP по умолчанию.

интересно как пакет прошедший MANGLE:PREROUTING не может дойти до NAT:PREROUTING

далее отрабатывается правило
-A PREROUTING -m state --state ESTABLISHED,RELATED -j ACCEPT
но вот в NAT:PREROUTING пакетов уже нет

пробовали убрать из mangle ВСЕ КРОМЕ МЕТОК, в том числе и все -j ACCEPT? Ну и политика по умолчанию тоже accept должна быть (у вас там drop)

И вы уверены, что до NAT:PREROUTING действительно не доходит? Как мониторите это?

samson ★★
()
Последнее исправление: samson (всего исправлений: 1)
Ответ на: комментарий от samson

пробовали убрать из mangle ВСЕ КРОМЕ МЕТОК, в том числе и все -j ACCEPT? Ну и политика по умолчанию тоже accept должна быть (у вас там drop)

да, конечно, все переписал. там сейчас ничего кроме маркировки и политика ACCEPT

И вы уверены, что до NAT:PREROUTING действительно не доходит? Как мониторите это?

*mangle
-A PREROUTING  -i ens2f1 -s DDD.DDD.DDD.DDD   -j MARK --set-mark 9998
-A PREROUTING  -m mark --mark 9998    -j LOG --log-prefix "MANGLE:PREROUTING:46:BEGIN:"
....
*nat
-A PREROUTING  -m mark --mark 9998     -j LOG --log-prefix "NAT:PREROUTING:46:ALL:"

итд итп

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

По идее надо «метить» входящие соединения. Т.е. что бы избежать ситуации, когда пакет (соединение извне) пришел со второго канала, а ответ ушел в первый.

Алгоритм должен быть таков: если пакет (точнее соединение) пришел от определенного провайдера (например, на определенный интерфейс), делаем connection mark, далее через ip rule заворачиваем ответ в нужную таблицу.

А для того, что бы завернуть трафик с сервера 192.168.0.100 в нужную таблицу, достаточно сделать ip rule add from 192.168.0.100 table T3 и 192.168.0.100 будет ходить в инет через шлюз AAA.AAA.AAA.62. Тут iptables не нужен. Можно сделать dnat как то так: -i ens1f0 -d AAA.AAA.AAA.60 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.100 и все должно без меток работать, тк 192.168.0.100 все равно ходит через этот канал в инет.

samson ★★
()
Ответ на: комментарий от samson

Алгоритм должен быть таков: если пакет (точнее соединение) пришел от определенного провайдера (например, на определенный интерфейс), делаем connection mark, далее через ip rule заворачиваем ответ в нужную таблицу.

к 

30868:  from CCC.CCC.CCC.70 lookup T2
30869:  from BBB.BBB.BBB.56 lookup T0

добавил

опробовал явное указание интерфейсов те 

iptables
-A PREROUTING -i ens2f1 -d CCC.CCC.CCC.70  -j MARK --set-mark 5002
-A PREROUTING -i ens2f0 -d BBB.BBB.BBB.56  -j MARK --set-mark 5001

ip rule
30579:  from all to BBB.BBB.BBB.56 fwmark 0x1389 lookup T0
30580:  from all to CCC.CCC.CCC.70 fwmark 0x138a lookup T2

ситуация изменилась
теперь входящие пакеты стали пропадать после MANGLE:PREROUTING
(хотя до этого доходили до NAT:PREROUTING)

в результате это наводит на мысль что схема
http://inai.de/images/nf-packet-flow.png
неточна
и после MANGLE:PREROUTING есть что-то
иначе куда пакеты делись ?

А для того, что бы завернуть трафик с сервера 192.168.0.100 в нужную таблицу, достаточно сделать ip rule add from 192.168.0.100 table T3 и 192.168.0.100 будет ходить в инет через шлюз AAA.AAA.AAA.62.

это уже сделано - cм выше 

30696:  from 192.168.0.102 fwmark 0x66 lookup T2
30697:  from 192.168.0.101 fwmark 0x65 lookup T0
30698:  from 192.168.0.100 fwmark 0x64 lookup T3

Алгоритм должен быть таков: если пакет (точнее соединение) пришел от определенного провайдера (например, на определенный интерфейс), делаем connection mark, далее через ip rule заворачиваем ответ в нужную таблицу.

те вот такая методика теперь не работает ? 

*nat
-A POSTROUTING -s 192.168.0.100    --out-interface ens1f0 -j SNAT --to-source  AAA.AAA.AAA.60
-A POSTROUTING -s 192.168.0.101    --out-interface ens2f0 -j SNAT --to-source  BBB.BBB.BBB.56
-A POSTROUTING -s 192.168.0.102    --out-interface ens2f1 -j SNAT --to-source  CCC.CCC.CCC.70

#ens1f0 WEB
-A PREROUTING -i ens1f0  -d  AAA.AAA.AAA.57 -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.100:80
-A PREROUTING -i ens1f0  -d  AAA.AAA.AAA.57 -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.100:443
#ens2f0 WEB
-A PREROUTING -i ens2f0  -d  BBB.BBB.BBB.56 -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.101:80
-A PREROUTING -i ens2f0  -d  BBB.BBB.BBB.56 -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.101:443
#ens2f1 WEB
-A PREROUTING -i ens2f1  -d  CCC.CCC.CCC.70  -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.102:80 
-A PREROUTING -i ens2f1  -d  CCC.CCC.CCC.70  -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.102:443

или я не понял мысль?

распишу проблему 1
те пакет вышел через 

-A POSTROUTING -s 192.168.0.102    --out-interface ens2f1 -j SNAT --to-source  CCC.CCC.CCC.70
пришел ответ на CCC.CCC.CCC.70
прошел MANGLE:PREROUTING - там ACCEPT
но вот в NAT:PREROUTING он уже не попал

проблема 2 выглядит MANGLE:PREROUTING - есть
NAT:PREROUTING - есть
далее пакета нет ни в MANGLE:INPUT ни в MANGLE:FORWARD

что примечательно - это кается только резервов
основной - прекрасно работает

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

Если правильно распарсил, то вроде логично. У вас уже есть запись в conntrack в соответствии с ней и будет обратное преобразование. емнип в nat попадает только первый пакет, потом в текущем соединении он не проходит цепочку повторно.

anc ★★★★★
()
Ответ на: комментарий от anc

мысль не понял - что именно логично ?

входящий (не ответный) пакет на AAA проходит и через MANGLE:PREROUTING и NAT:PREROUTING итд и выходит куда надо на локальную железку
а входящий пакет на CCC проходит через MANGLE:PREROUTING и NAT:PREROUTING и исчезает

а если добавить

iptables
-A PREROUTING -i ens2f1 -d CCC.CCC.CCC.70  -j MARK --set-mark 5002
-A PREROUTING -i ens2f0 -d BBB.BBB.BBB.56  -j MARK --set-mark 5001

ip rule
30579:  from all to BBB.BBB.BBB.56 fwmark 0x1389 lookup T0
30580:  from all to CCC.CCC.CCC.70 fwmark 0x138a lookup T2

то он уже пропадает после MANGLE:PREROUTING

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

пришел ответ на CCC.CCC.CCC.70
прошел MANGLE:PREROUTING - там ACCEPT
но вот в NAT:PREROUTING он уже не попал

1. Не надо никаких -j ACCEPT в mangle. Но и политика по умолчанию, естественно, не DROP

проблема 2 выглядит MANGLE:PREROUTING - есть
NAT:PREROUTING - есть
далее пакета нет ни в MANGLE:INPUT ни в MANGLE:FORWARD

и после MANGLE:PREROUTING есть что-то
иначе куда пакеты делись ?

2. Он может и не дойти. Не забывайте про routing decision!

это уже сделано - cм выше

30696: from 192.168.0.102 fwmark 0x66 lookup T2
30697: from 192.168.0.101 fwmark 0x65 lookup T0
30698: from 192.168.0.100 fwmark 0x64 lookup T3

Тут у вас в условиях не только from но и fwmark. Для начала пробуйте без fwmark.

Для начала надо разделить маршрутизацию и iptables. И понять: 

что пакет пришел, попал в MANGLE:PREROUTING (тут ставим метки) -> NAT:PREROUTING (тут подменяем адрес назначения) ->
далее принимается решение маршрутизации, далее это либо локальный пакет, либо транзитный, либо вообще !!может быть проигнорирован!! ->
далее MANGLE:INPUT или MANGLE:FORWARD ->
итд...

Если нет полного понимания, то прочитайте хотя бы тут: https://habrahabr.ru/post/108690/ В вашем случае, когда отдельные хосты ходят только через определенные каналы, даже метить в mangle ничего не надо. 

# маршрутизация:
ip rule add from 192.168.0.102 table T2 
# теперь сервер 192.168.0.102 ходит через Т2
# в T2 прописан маршрут по умолчанию через CCC.CCC.CCC.70

# NAT:
-A PREROUTING -i ens2f1  -d  CCC.CCC.CCC.70  -p tcp --destination-port 80    -j DNAT --to-destination 192.168.0.102:80 
-A PREROUTING -i ens2f1  -d  CCC.CCC.CCC.70  -p tcp --destination-port 443   -j DNAT --to-destination 192.168.0.102:443
-A POSTROUTING -s 192.168.0.102    --out-interface ens2f1 -j SNAT --to-source  CCC.CCC.CCC.70

А вот в случае, если у вас прописан маршрут через другой канал, либо через все три и 192.168.0.102 не обязан ходить только через свой канал, надо метить входящие соединения и потом на основании этих меток маршрутизировать (выбирать соответствующую таблиу).

ps: вот еще схемы, может покажутся нагляднее:
https://ru.wikipedia.org/wiki/Iptables#/media/File:Iptables-traversal.svg
https://ru.wikibooks.org/wiki/Iptables#/media/File:Netfilter-diagram-rus.png

samson ★★
()
Ответ на: комментарий от Nagisa

а входящий пакет на CCC проходит через MANGLE:PREROUTING и NAT:PREROUTING и исчезает

а если добавить
iptables
-A PREROUTING -i ens2f1 -d CCC.CCC.CCC.70 -j MARK --set-mark 5002
-A PREROUTING -i ens2f0 -d BBB.BBB.BBB.56 -j MARK --set-mark 5001
ip rule
30579: from all to BBB.BBB.BBB.56 fwmark 0x1389 lookup T0
30580: from all to CCC.CCC.CCC.70 fwmark 0x138a lookup T2
то он уже пропадает после MANGLE:PREROUTING

тут похоже имелось ввиду forward?

вот вам и ответ. Потому что нет правила 

from CCC.CCC.CCC.70 lookup T2
from BBB.BBB.BBB.56 lookup T0
Он не заворачивает в таблицу Т2. Скорее всего идет через таблицу по умолчанию. А когда добавили, то завернули его в T2 (через метки). Но это для случая когда определенный сервак всегда ходит только через определенный канал (не через канал по умолчанию).

И он, скорее всего, попадает в forward, но только на другом интерфейсе (идет по другому маршруту, не по нужному). Только мониторите вы его как то не так (для -j LOG не то условие используется). Хотя может и не попадать.

samson ★★
()
Последнее исправление: samson (всего исправлений: 4)
Ответ на: комментарий от samson

по поводу картинок и понимания - тут нет проблем
повторю - конфигурация 100% рабочая на Centos4

провел чистку правил
а именно удалил маркировку 

-A PREROUTING -i enp3s0 -s 192.168.0.100 -j MARK --set-mark 100
-A PREROUTING -i enp3s0 -s 192.168.0.101 -j MARK --set-mark 101
-A PREROUTING -i enp3s0 -s 192.168.0.102 -j MARK --set-mark 102

теперь mangle:PREROUTING чистый

и изменил правила 

30852:  from 192.168.0.102 fwmark 0x66 lookup T2
30853:  from 192.168.0.101 fwmark 0x65 lookup T0
30854:  from 192.168.0.100 fwmark 0x64 lookup T3
на 
30852:  from 192.168.0.102 lookup T2
30853:  from 192.168.0.101 lookup T0
30854:  from 192.168.0.100 lookup T3

видимо именно это и есть отличие Centos4 от Centos7 которое мешало работать тк в Centos4 маркировка была нужна

осталось разобраться с OpenVPN - что там в конфигах теперь лишее ;-)

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

видимо именно это и есть отличие Centos4 от Centos7

Правильно сказать это разные версии iproute2. А не дистра. Вы напомнили мне, как-то пришлось вкорячивать правила на старый дистр у меня было с точностью до наоборот, «этого еще нет, этого нет...»
iproute2 достаточно «динамично» развивается, вот и приходиться на грабли регулярно наступать. :)

anc ★★★★★
()
Ответ на: комментарий от anc

Есть, хоть и сложная для понимания у не подготовленных :), >картинка https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg
Но она очень доступна для понимания, «что и куда». Рекомендую.

читайте внимательно я уже давал ссылку на оригинал этой картинки

и да, исходя из полученной информации в этой ситуации она не точна - те после mangle:prerouting есть routing declision

Правильно сказать это разные версии iproute2.

согласен, просто не ожидал, что будет концептуальное изменение

в принципе, изменение полезное тк я конкретно сократил объем скриптов и как результат - повысил их читаемость
из недостатков - с icmp на резервы пришлось повозиться

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

Насколько я понимаю решение маршрутизации после NAT.prerouting, те

Mangle.pre -> NAT.pre -> routing

У вас пакет «не попадал» в NAT.pre по какой то другой причине

Либо мониторите как то не так, а он там, либо это происходит за счёт фильтрации в mangle

PS: тут даже название чепочки говорит об этом - «preRouting»

samson ★★
()
Последнее исправление: samson (всего исправлений: 1)
28 июля 2019 г.

основная задача была сделана, но последняя проблема с доступом к локальным ресурсам сервера-маршрутизатора по резервным каналам так и не была решена, но тк это не было критичным то отложил до появления достаточного времени для решения. время появилось.

итак опишу проблему: Centos7, 4 внешних интерфейса, 1 внутренний; за внутренним интерфейсом сервера, ресурсы которых доступны через все внешние каналы. настроена маршрутизация и nat. тут все работает так как надо. проблема в следующем на сервере-маршрутизаторе стоят локальные сервисы, которые надо сделать доступными на резервных каналах

изучение документации дало понимание того, что многое скрыто - ну вот как пример: проход первого пакета транзитом (наименования цепочек буду сокращать)

man:pre  
nat:pre
man:for
fil:for
man:post
nat:post

всё по схемам

а вот второй идет уже по сокращенному пути:

man:pre  
man:for
fil:for
man:post

теперь к проблеме

отпавляю запрос к локальному сервису на 4й резерв он проходит

man:pre
nat:pre

и все - исчезает!

те он должен появится в man:input, но видимо на этапе routing declision он убивается

цель понять почему и как это исправить

подробная информация о конфигурации

табличка резерва 

ip route add DDD.DDD.DDD.0      dev ens1f1 src DDD.DDD.DDD.24   table T4 >/dev/null
ip route add 192.168.0.0/24   dev enp3s0 src 192.168.0.1    table T4 >/dev/null
ip route add 127.0.0.0/8      dev lo                        table T4 >/dev/null
ip route add default via DDD.DDD.DDD.1                        table T4 >/dev/null

main 

ip route add  AAA.AAA.AAA.AAA    dev ens2f0 src AAA.AAA.AAA.1   >/dev/null
ip route add BBB.BBB.BBB.BBB       dev ens2f1 src BBB.BBB.BBB.1 >/dev/null
ip route add DDD.DDD.DDD.DDD       dev ens1f1 src DDD.DDD.DDD.1    >/dev/null
ip route add CCC.CCC.CCC.CCC/29 dev ens1f0 src CCC.CCC.CCC.CCC  >/dev/null
ip route add default via  CCC.CCC.CCC.CCC metric 99 >/dev/null

из негативных факторов которые могут вмешиваться в маршрутизацию - на сервере установлен openvpn-сервер

вопрос - как проводить дальнейшую диагностику ? те как отловить почему пакет был убит на routing declision ?

тк сейчас на 4ом канале-резерве нет ничего критичного то я могу проводить на нем любые эксперименты. что опробовал

1. DNAT на локальные интерфейсы - пофиг. пакет не доходит до man:input

2. явное указание 

ip rule add to   84.22.140.24    fwmark 0x400 table T4 >/dev/null
ip rule add from 84.22.140.24    fwmark 0x400 table T4 >/dev/null
тоже пофиг

Nagisa
() автор топика
Ответ на: комментарий от Nagisa

Перечитывать всю тему двух годичной давности как-то лениво. Создайте лучше новую с полным описанием.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Оплатил настройку шлюза centos 7 инет + локаль + Wi-Fi
Admin
упала система (initramfs) после запуска victoria →