LINUX.ORG.RU
решено Форум — Admin  

iproute2 миновать таблицу main

 , ,


0

1

Всех с праздником! Имеем: сервер NAT с 2-мя интерфейсами WAN и 1 LAN. Добавлены 2 таблицы T1 и T2:

#ip rule
0:      from all lookup local
100:    from all fwmark 0xa lookup T1
101:    from all fwmark 0x14 lookup T2
200:    from 87.250.250.242 lookup T1
201:    from 173.194.44.78 lookup T2
32766:  from all lookup main
32767:  from all lookup default
Трафик разруливаем маркируя пакеты в iptables: 
#исходящие соединения:
iptables -t mangle -A PREROUTING -m connmark --mark 0 -s 192.168.1.0/24 -j CONNMARK --set-mark 20
#входящие соединения
iptables -t mangle -A PREROUTING -m connmark --mark 0 -i $WAN1 -j CONNMARK --set-mark 10
iptables -t mangle -A PREROUTING -m connmark --mark 0 -i $WAN2 -j CONNMARK --set-mark 20
Из под NAT'а и за NAT все ходит верно, через нужные интерфейсы. Но сам шлюз при этом ходит в 0.0.0.0 через default gateway. Соответственно возникает проблема с локальными сервисами, размещенными на том же шлюзе (OpenVPN) - пакет поступает на интерфейс WAN2, а ответ отсылается через WAN1, который указан дефотным в таблице main. Собственно вопрос, как правильно направлять трафик самого шлюза?

← Будьте же вы людьми ответить на парочку вопросов о KVM
посоветуйте дистр софт роутера Linux c QOS →

Обычно для каждого ip-адреса на wan-интерфейсе своя таблица маршрутизации и все пакеты с src-адресом wan-интерфейса уходят в эту таблицу и по ней уходят в нужный wan.

Так как не известно, что у вас в T1 и T2, то непонятно, почему у вас проблемы. При этом нужно различать случай, когда сервер иницирует соединение, или когда отвечает на запрос. В первом случае, src-адрес пакета (соединения) будет взят на основании таблицы main (если приложение само не захочет другого).

mky ★★★★★
()
Ответ на: комментарий от mky 
# ip route show table T1
default via 87.250.192.1 dev lan1
87.250.192.0/18 dev lan1  scope link  src 87.250.250.242
192.168.1.0/24 dev lan0  proto kernel  scope link  src 192.168.1.1
# ip route show table T2
default via 173.194.44.1 dev lan2
173.194.44.0/24 dev lan2  scope link  src 173.194.44.78
192.168.1.0/24 dev lan0  proto kernel  scope link  src 192.168.1.1

# ip route show table main
default via 87.250.192.1 dev lan1
10.25.0.0/24 via 10.25.0.2 dev tun0
10.25.0.2 dev tun0  proto kernel  scope link  src 10.25.0.1
87.250.192.0/18 dev lan1  proto kernel  scope link  src 87.250.250.242
173.194.44.0/24 dev lan2  proto kernel  scope link  src 173.194.44.78
192.168.1.0/24 dev lan0  proto kernel  scope link  src 192.168.1.1
192.168.3.0/24 via 10.25.0.2 dev tun0
192.168.4.0/24 via 10.25.0.2 dev tun0

OpenVPN клиент стучится на 173.194.44.78 (lan2), не может авторизоваться (TLS handshake failed), смотрю в tshark, вижу: 

# tshark -i lan2 host 23.96.52.53
  1 0.000000000 23.96.52.53 -> 173.194.44.78 OpenVPN 84 MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
  2 31.501535273 23.96.52.53 -> 173.194.44.78 OpenVPN 84 MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
  3 33.424093699 23.96.52.53 -> 173.194.44.78 OpenVPN 84 MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
.................
# tshark -i lan1 host 23.96.52.53
  1 0.000000000 23.96.52.53 -> 87.250.250.242 TCP 66 53839 → 3053 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
  2 0.166426957 23.96.52.53 -> 87.250.250.242 TCP 66 53840 → 3053 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
  3 0.437935444 23.96.52.53 -> 87.250.250.242 TCP 66 47201 → 778 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=4
  4 1.452065240 87.250.250.242 -> 23.96.52.53 OpenVPN 96 MessageType: P_CONTROL_HARD_RESET_SERVER_V2
  5 2.999363121 23.96.52.53 -> 87.250.250.242 TCP 66 [TCP Retransmission] 53839 → 3053 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
  6 3.107524538 23.96.52.53 -> 87.250.250.242 TCP 66 [TCP Retransmission] 53840 → 3053 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
  7 3.269146168 87.250.250.242 -> 23.96.52.53 OpenVPN 92 MessageType: P_ACK_V1
  8 7.553528744 87.250.250.242 -> 23.96.52.53 OpenVPN 92 MessageType: P_ACK_V1
  9 8.526979479 23.96.52.53 -> 87.250.250.242 TCP 66 47206 → 778 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=4

nike-tesla
() автор топика

выкинуть dgw из main, main всегда смотреть сразу после local!

дальше все специфические правила, а после них табличку с dgw

CONNMARK не маркирует пакеты, а ip ru не знает про conntrack

Если где-то дальше нет конструкции "-j CONNMARK --restore-mark", то "-j CONNMARK --set-mark" ничего не делает.

vel ★★★★★
()
Ответ на: комментарий от nike-tesla

Снаружи, допустим с того же openvpn клиента, пинг на оба внешних адреса (lan1 и lan2) работает? Если работает, то это уже больше похоже на проблемы openvpn.

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

Спасибо, то что нужно. Сделал так:

# ip rule
0:      from all lookup local
10:     from all lookup main
100:    from all fwmark 0xa lookup T1
101:    from all fwmark 0x14 lookup T2
200:    from 87.250.250.242 lookup T1
201:    from 173.194.44.78 lookup T2
300:    from all lookup T1
301:    from all lookup T2
32767:  from all lookup default

#ip ro show table main
10.25.0.0/24 via 10.25.0.2 dev tun0
10.25.0.2 dev tun0  proto kernel  scope link  src 10.25.0.1
192.168.1.0/24 dev lan0  proto kernel  scope link  src 192.168.1.2
192.168.3.0/24 via 10.25.0.2 dev tun0
192.168.4.0/24 via 10.25.0.2 dev tun0
Таблицы T1 и T2 не менялись (описывал выше). Однако! Уже сломал всю голову, ответы OpenVPN посылает через интерфейс не тот, на который приходит запрос, одновременно запускаю в 2-х консолях tshark, и вижу: 
# tshark -i lan2 host 217.118.95.105
Capturing on 'lan2'
  1 0.000000000 217.118.95.105 -> 173.194.44.78 UDP 84 23064 → 1194  Len=42
  2 2.209758018 217.118.95.105 -> 173.194.44.78 UDP 84 23064 → 1194  Len=42
  3 6.641472104 217.118.95.105 -> 173.194.44.78 UDP 84 23064 → 1194  Len=42
  4 15.035486625 217.118.95.105 -> 173.194.44.78 UDP 84 23064 → 1194  Len=42
  5 31.529552136 217.118.95.105 -> 173.194.44.78 UDP 84 23064 → 1194  Len=42
5 packets captured


# tshark -i lan1 host 217.118.95.105
Capturing on 'lan1'
  1 0.000000000 87.250.250.242 -> 217.118.95.105 UDP 96 1194 → 23064  Len=54
  2 2.209566808 87.250.250.242 -> 217.118.95.105 UDP 92 1194 → 23064  Len=50
  3 6.641263746 87.250.250.242 -> 217.118.95.105 UDP 92 1194 → 23064  Len=50
  4 15.035287560 87.250.250.242 -> 217.118.95.105 UDP 92 1194 → 23064  Len=50
  5 31.529358491 87.250.250.242 -> 217.118.95.105 UDP 92 1194 → 23064  Len=50
5 packets captured
OpenVPN стучится на интерфейс lan2, ответ получает от lan1. При этом, когда ложу интерфейс lan1, все заводится, пакеты начинают нормально уходить из lan2, куда и пришли. Ставлю Apache2 на тот же шлюз чтоб проверить - работает на всех интерфейсах, tshark показывает что ответы апача уходят с того интерфейса, на который пришли. Выходит что проблема только с OpenVPN, при этом специфических настроек самого OpenVPN сервера нет, т.е. интерфейсы в конфигах сервера не указаны, в конфигах клиента только 1 IP.

nike-tesla
() автор топика
Ответ на: комментарий от mky

Да, конечно ходят. Вот и я уже голову сломал, другие сервисы нормально работают, проблема только с OpenVPN, куда копать уже не знаю.

netstat -uapn | grep openvpn
udp        0      0 0.0.0.0:1194           0.0.0.0:*                           1157/openvpn

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

Опцию multihome в OpenVPN пробовал?

--multihome
    Configure a multi-homed UDP server. This option can be used when OpenVPN has been configured to listen on all interfaces, and will attempt to bind client sessions to the interface on which packets are being received, so that outgoing packets will be sent out of the same interface. Note that this option is only relevant for UDP servers and currently is only implemented on Linux.
Pinkbyte ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Будьте же вы людьми ответить на парочку вопросов о KVM
Admin
посоветуйте дистр софт роутера Linux c QOS →