LINUX.ORG.RU

Сообщения drunken_cowboy

 

Несколько маршрутов по умолчанию

Добрый день. Тут производственная задача - проверять время от времени, живой ли у нас резервный канал, пытаюсь вот сделать, и что-то не получается - подскажите, пожалуйста, в чём тут проблема.

Конфигурация:

2 openvpn-сети: 10.17.17.0/24 и 10.17.30.0/24, по умолчанию траффик идёт через 10.17.30.1, резервный шлюз, соответственно - 10.17.17.20.

Как я собираюсь решить задачу:iptables транслирует, например, 888-й порт в 80-й и ставить метку, а с помощью iproute2 по этой метке юзать отдельную таблицу с дефолтным маршрутом через 10.17.17.20. Конфигурация:

ip route show

default via 10.17.30.1 dev tap0 
10.17.17.0/24 dev tap1  proto kernel  scope link  src 10.17.17.10 
10.17.18.0/24 via 10.17.17.1 dev tap1 
10.17.30.0/24 dev tap0  proto kernel  scope link  src 10.17.30.3 

ip rule show

0:      from all lookup local 
32765:  from all fwmark 0x2 lookup rt_vpn 
32766:  from all lookup main 
32767:  from all lookup default 

ip route show table rt_vpn
default via 10.17.17.20 dev tap1 
10.17.17.0/24 dev tap1  scope link  src 10.17.17.10 

iptables -t nat -S

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A OUTPUT -p tcp -m tcp --dport 888 -j MARK --set-xmark 0x2/0xffffffff
-A OUTPUT -p tcp -m tcp --dport 888 -j DNAT --to-destination :80

Коннект проверяется с помощью «nc -z 93.158.134.11 888 ». Глухо. tcpdump на 10.17.17.20 почему-то показывает, что пакеты идут с адреса 10.17.30.3 - мистика!

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:13:37.389236 IP (tos 0x0, ttl 64, id 15685, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xdde0 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946229544 ecr 0,nop,wscale 7], length 0
11:13:37.389254 IP (tos 0x0, ttl 63, id 15685, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xdde0 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946229544 ecr 0,nop,wscale 7], length 0
11:13:38.390532 IP (tos 0x0, ttl 64, id 15686, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xd9f6 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946230546 ecr 0,nop,wscale 7], length 0
11:13:38.390542 IP (tos 0x0, ttl 63, id 15686, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xd9f6 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946230546 ecr 0,nop,wscale 7], length 0

А, и правила на 10.17.17.20: 

iptables -t nat -S

-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A POSTROUTING -s 10.17.16.0/22 -o eth0 -j SNAT --to-source <внешний_ip>

 ,

drunken_cowboy
()
4 комментария

iptables и ACK-пакеты

Столкнулся с каким-то странным поведением iptables. Соль, в общем, вот в чём: есть два правила 

-A INPUT -i eth0 -m state --state NEW -p tcp --tcp-flags SYN,FIN,RST RST -j ACCEPT

-A INPUT -i eth0 -m state --state NEW -p tcp ! --tcp-flags SYN,ACK,FIN SYN -j LOG --log-prefix "[ IPT STEALTH ] "
Предназначенные для того, чтобы дропать соединения, начинающиеся не с SYN-пакета (но не дропать RST). В остальном конфиг iptables стандартный с DROP-политикой по умолчанию и ACCEPT для established и related. В субботу возникли проблемы с доставкой почты, и глянув в логи, увидел тонны вот такого:

Dec 24 03:23:37 debian-60 kernel: [4885234.900208] [ IPT STEALTH ] IN=eth0 OUT= MAC=4c:72:b9:25:25:ab:78:fe:3d:47:02:9d:08:00 SRC=94.100.176.126 DST=*.*.*.* LEN=90 TOS=0x00 PREC=0x00 TTL=59 ID=48118 DF PROTO=TCP SPT=25 DPT=27000 WINDOW=11584 RES=0x00 ACK PSH URGP=0
Dec 24 03:24:14 debian-60 kernel: [4885271.346275] [ IPT STEALTH ] IN=eth0 OUT= MAC=4c:72:b9:25:25:ab:78:fe:3d:47:02:9d:08:00 SRC=94.100.176.75 DST=*.*.*.* LEN=89 TOS=0x00 PREC=0x00 TTL=59 ID=654 DF PROTO=TCP SPT=25 DPT=61440 WINDOW=26064 RES=0x00 ACK PSH URGP=0
Dec 24 03:24:37 debian-60 kernel: [4885295.133934] [ IPT STEALTH ] IN=eth0 OUT= MAC=4c:72:b9:25:25:ab:78:fe:3d:47:02:9d:08:00 SRC=94.100.176.170 DST=*.*.*.* LEN=89 TOS=0x00 PREC=0x00 TTL=59 ID=49776 DF PROTO=TCP SPT=25 DPT=5101 WINDOW=26064 RES=0x00 ACK PSH URGP=0
Dec 24 03:25:08 debian-60 kernel: [4885325.959640] [ IPT STEALTH ] IN=eth0 OUT= MAC=4c:72:b9:25:25:ab:78:fe:3d:47:02:9d:08:00 SRC=94.100.176.190 DST=*.*.*.* LEN=90 TOS=0x00 PREC=0x00 TTL=59 ID=19982 DF PROTO=TCP SPT=25 DPT=5446 WINDOW=26064 RES=0x00 ACK PSH URGP=0
Dec 24 05:20:02 debian-60 kernel: [4892219.805235] [ IPT STEALTH ] IN=eth0 OUT= MAC=4c:72:b9:25:25:ab:78:fe:3d:47:02:9d:08:00 SRC=94.100.176.60 DST=*.*.*.* LEN=89 TOS=0x00 PREC=0x00 TTL=59 ID=42536 DF PROTO=TCP SPT=25 DPT=53871 WINDOW=17376 RES=0x00 ACK PSH URGP=0

Преимущественно с адресов mail.ru. Или я дурак, или лыжи не едут: получается, что mail.ru начинает соединения с ACK-пакетов или как?

P.S. Вдогонку - полный конфиг iptables 

-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1195 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1195 -j ACCEPT
-A INPUT -p udp -m udp --dport 25 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 1195 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 1500 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p udp -m udp --dport 1195 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p udp -m udp --dport 25 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 17 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 13 -j DROP
-A INPUT -p icmp -m length --length 1492:65535 -j DROP
-A INPUT -p icmp -m icmp --icmp-type any -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 6 --hashlimit-mode srcip --hashlimit-name ICMP_FLOOD --hashlimit-htable-expire 60000 -j ACCEPT
-A INPUT -s 10.17.16.0/22 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m hashlimit --hashlimit-upto 1/min --hashlimit-burst 6 --hashlimit-mode srcip --hashlimit-name SSH_BRUTEFORCE --hashlimit-htable-expire 60000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j LOG --log-prefix "[SSH BRUTEFORCE]"
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j DROP
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --tcp-flags FIN,SYN,RST RST -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp ! --tcp-flags FIN,SYN,ACK SYN -j LOG --log-prefix "[ IPT STEALTH ] "
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp ! --tcp-flags FIN,SYN,ACK SYN -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -f -m limit --limit 5/min --limit-burst 7 -j LOG --log-prefix " [ IPT Fragmented ]"
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -m state --state INVALID -j DROP

 ,

drunken_cowboy
()
1 комментарий

Проброс icmpv6 neighbour discovery

Houston, we've got a problem!

Проблема такова: в гараже имеется VPS от хетцнера (debian) с /64-подсетью, openvpn, криворукий я и два стакана виски. Целью было - настроить openvpn так, чтобы подключающиеся клиенты получали белые ipv6-адреса из той же подсети, что и сервер. Что я сделал: поделил имеющуюся /64 сеть на две по /65, одну повесил на eth0, другую на tap0. Таким образом клиенты openvpn получали ipv6 без особых заморочек, и если на других VPS такая схемка спокойно работала, то hetzner меня, скажем так, неприятно удивил: внутри tap0 сервер и клиент взаимно пинговались, пакеты наружу шли, а ответные - нет. Снаружи tap0 не пинговалась.

В итоге выяснилось, что гейтвей хетцнера вместо того, чтобы просто слать в сеть весь приходящий на него траффик, сначала зачем-то бросает туда neightbor solicitation, на которые в случае с повешенной на tap0 сеткой, ессесно, ответить некому.

Вопщем, прошу помочь с решением проблемы: либо каким-то образом пробрасывать neighbor discovery пакеты, либо найти чото другое. Спасибо.

ЗЫ. Сначала думал объединить интерфейсы в бридж, но при добавлении в бридж интерфейс ложится, а редактировать /etc/network/interfaces боюсь, ибо если чото сломаю - накрылся мой впс медным тазом.

 , neighbor solicitation,

drunken_cowboy
()
1 комментарий

RSS подписка на новые темы