LINUX.ORG.RU
ФорумAdmin

iproute2 почему не работает такая схемка?


0

0

Есть три интерфейса

eth0: 192.168.1.232/24 gw 192.168.1.2 - локалка
eth2: 194.44.200.229/28 gw 194.44.200.225 - радиоканал
eth1->ppp0: 82.207.108.130 gw 195.5.5.206 - земля

ip route list
195.5.5.207 dev ppp0 proto kernel scope link src 82.207.108.130
194.44.200.224/28 dev eth2 proto kernel scope link src 194.44.200.229
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.232
127.0.0.0/8 dev lo scope link
default via 195.5.5.207 dev ppp0

ip rule list
0: from all lookup local
32761: from all fwmark 0x1e lookup T2
32762: from all fwmark 0x15 lookup T2
32763: from all fwmark 0x14 lookup T2
32764: from 194.44.200.229 lookup T2
32765: from 82.207.108.130 lookup T1
32766: from all lookup main
32767: from all lookup default

ip route list table T1
192.168.1.0/24 dev eth0 scope link src 192.168.1.232
default via 195.5.5.207 dev ppp0

ip route list table T2
192.168.1.0/24 dev eth0 scope link src 192.168.1.232
default via 194.44.200.225 dev eth2

Немогу выйти в мир через eth2 хочу туда завернуть весь трафик кроме
почтового, почта будет по земле бегать, помогите нийти ошибку, а то
никак... Смотрю у людей практически тоже самое работает...

anonymous

>Немогу выйти в мир через eth2

ping -I 194.44.200.229 работает?

А так, ИМХО, вы наворотили лишнего. Зачем таблица T1, если и в ней и в default таблице маршрут по умолчанию через ppp0. И если вы хотите все трафик, кроме почтового пустить через eth2, то и пишите в default таблице маршрут по умолчанию через eth2...

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

Если у человека почтовик sendmail, то тот будет работать только по default маршруту.

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

Да видно все хосты из сети 194.44.200.224/28 Но дальше не идет... кода дефолтовым шлюзом ставлю 194.44.200.225 тогда все работает кроме выхода через 82.207.180.130...

Мыло у меня qmail...

Вроде по доках деалю но где-то что-то пропустил

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

>Ребята, так в чем проблема?

Возможно, что проблема в правилах iptables, выставляющих mark.
А может у вас включен rp_filter (посмотрите файлы /proc/sys/net/ipv4/conf/*/rp_filter).

Давайте по простому, сначала уберете все лишее, убедитесь что все работает, а потом уже будете "наворачивать".
То есть рекомендую сначала из всех правил (ip rule) оставить минимум:

ip rule list
0: from all lookup local
32764: from 194.44.200.229 lookup T2
32766: from all lookup main
32767: from all lookup default

добится, чтобы работал traceroute -n -s 194.44.200.229 ya.ru
смотрите пакеты с помощью tcpdump или аналога.

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

Хорошо попробую

правила вроде работают
Chain OUTPUT (policy ACCEPT 909K packets, 541M bytes)
num pkts bytes target prot opt in out source destination
1 1509 1658K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 MARK set 0xa
2 2573 149K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK set 0x14
3 1 60 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 MARK set 0x15
4 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 MARK set 0x1e

устанавливаю так
# ****** OUTPUT
iptables -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark 10
iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 20
iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 21
iptables -t mangle -A OUTPUT -p tcp --dport 21 -j MARK --set-mark 30


Вот такое прописано у меня?
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1

# Enable reverse path
net.ipv4.conf.all.rp_filter = 1

нужно выключить?

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

gateway ~ # traceroute -n -s 194.44.200.229 ya.ru traceroute to ya.ru (213.180.204.8), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * 194.44.212.34 20.232 ms 20.552 ms 6 195.35.65.88 20.873 ms 16.620 ms 16.554 ms 7 213.180.192.254 56.643 ms 48.611 ms 48.783 ms 8 213.180.204.8 53.113 ms 48.056 ms 47.916 ms

вот какая картина

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

И так сбросил я эти rp_filter и вроде все работает

Оставил только это
gateway ~ # ip route
195.5.5.206 dev ppp0 proto kernel scope link src 82.207.108.130
194.44.200.224/28 dev eth2 proto kernel scope link src 194.44.200.229
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.232
127.0.0.0/8 dev lo scope link
default via 195.5.5.206 dev ppp0

gateway ~ # ip route list table T2
192.168.1.0/24 dev eth0 scope link src 192.168.1.232
default via 194.44.200.225 dev eth2

Из вне есть доступ и к 82.207. и к 194.44.

Из сервера не идет разделение трафика.... тоесть 80 21 по радиоканалу...

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

>И так сбросил я эти rp_filter и вроде все работает

Да, rp_filter бесполезен, или даже вреден на внешнем (Интернетовском) интерфейсе. В принципе, его можно включить на eth0, если локалка "хулиганистая", а можно и не включать.

>Из сервера не идет разделение трафика.... тоесть 80 21 по радиоканалу...

В смысле http и ftp не идут по радиоканалу? ip rule fwmark прописаны? Если "да", то остается прописать SNAT правило для eth2:

iptables -t nat -A POSTROUTING -o eth2 -s ! 194.44.200.225 -j SNAT --to-source 194.44.200.225

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

Самое странное сейчас если включить rp_filter всеравно бегают пинги... видимо проблема была в общей наворочености правил...

Не работает построутинг... куда смотреть?

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

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

>Не работает построутинг...

Напишите подробнее, как вы определили, что построутинг (цепочка POSTROUTING в таблице nat?) не работает.

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

Да я все же выключил... эти фильтры...

Ну как сам фаервол отрабатывает, туда пакеты идут видно по счетчиках
но реакции при запуске загрузки файлов не происходит висит и все...
ждет чего-то... а как еще можно определить?


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

Запустите дампер пакетов на интерфейсе и смотрите, уходят ли пакеты и с какими ip-адресами, то есть на одном терминале запускаем:

# tcpdump -i eth2 -n -nn port 80

а на другом терминале запускаем

$ wget http://ya.ru

Вместо tcpdump можно использовать wireshark (a.k.a. ethereal)

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

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 68 bytes
17:35:35.403154 IP 194.44.200.225.53979 > 213.180.204.8.80: S 1691866599:1691866599(0) win 5808 <mss 1452,sackOK,timestamp 78086313[|tcp]>
17:35:38.399314 IP 194.44.200.225.53979 > 213.180.204.8.80: S 1691866599:1691866599(0) win 5808 <mss 1452,sackOK,timestamp 78087213[|tcp]>
17:35:44.398925 IP 194.44.200.225.53979 > 213.180.204.8.80: S 1691866599:1691866599(0) win 5808 <mss 1452,sackOK,timestamp 78089013[|tcp]>

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

Блин, я вам не правильное nat правило написал. Надо чтобы ip адрес был ваш (194.44.200.229) то есть правильно должно быть:

iptables -t nat -A POSTROUTING -o eth2 -s ! 194.44.200.229 -j SNAT --to-source 194.44.200.229

приношу свои извинения за эту ошибку.

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

Смотрю еще вот на это....

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

Это не может влиять? может быть врубыть эти значения?

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

tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 68 bytes 21:30:31.913085 IP (tos 0x0, ttl 64, id 24829, offset 0, flags [DF], proto TCP (6), length 60) 194.44.200.229.51128 > 213.180.204.8.80: S 3681249905:3681249905(0) win 5808 <mss 1452,sackOK,timestamp 82315916[|tcp]> 21:30:31.970213 IP (tos 0x0, ttl 56, id 2992, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:34.912572 IP (tos 0x0, ttl 64, id 24830, offset 0, flags [DF], proto TCP (6), length 60) 194.44.200.229.51128 > 213.180.204.8.80: S 3681249905:3681249905(0) win 5808 <mss 1452,sackOK,timestamp 82316816[|tcp]> 21:30:34.959778 IP (tos 0x0, ttl 56, id 6385, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:37.962078 IP (tos 0x0, ttl 56, id 9717, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:40.911553 IP (tos 0x0, ttl 64, id 24831, offset 0, flags [DF], proto TCP (6), length 60) 194.44.200.229.51128 > 213.180.204.8.80: S 3681249905:3681249905(0) win 5808 <mss 1452,sackOK,timestamp 82318616[|tcp]> 21:30:40.959849 IP (tos 0x0, ttl 56, id 12691, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:46.959202 IP (tos 0x0, ttl 56, id 19429, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:58.960661 IP (tos 0x0, ttl 56, id 33450, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]>

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

tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 68 bytes 21:30:31.913085 IP (tos 0x0, ttl 64, id 24829, offset 0, flags [DF], proto TCP (6), length 60) 194.44.200.229.51128 > 213.180.204.8.80: S 3681249905:3681249905(0) win 5808 <mss 1452,sackOK,timestamp 82315916[|tcp]> 21:30:31.970213 IP (tos 0x0, ttl 56, id 2992, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:34.912572 IP (tos 0x0, ttl 64, id 24830, offset 0, flags [DF], proto TCP (6), length 60) 194.44.200.229.51128 > 213.180.204.8.80: S 3681249905:3681249905(0) win 5808 <mss 1452,sackOK,timestamp 82316816[|tcp]> 21:30:34.959778 IP (tos 0x0, ttl 56, id 6385, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:37.962078 IP (tos 0x0, ttl 56, id 9717, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:40.911553 IP (tos 0x0, ttl 64, id 24831, offset 0, flags [DF], proto TCP (6), length 60) 194.44.200.229.51128 > 213.180.204.8.80: S 3681249905:3681249905(0) win 5808 <mss 1452,sackOK,timestamp 82318616[|tcp]> 21:30:40.959849 IP (tos 0x0, ttl 56, id 12691, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:46.959202 IP (tos 0x0, ttl 56, id 19429, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]> 21:30:58.960661 IP (tos 0x0, ttl 56, id 33450, offset 0, flags [DF], proto TCP (6), length 64) 213.180.204.8.80 > 194.44.200.229.51128: S 215957195:215957195(0) ack 3681249906 win 4096 <mss 1410,nop,wscale 0,nop,nop,timestamp[|tcp]>

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

Если wget не получает данные, либо у вас все таки включен rp_filter, либо пакеты рубит iptables.

accept_source_route не должен влиять. Врядли от ya.ru к вам приходят пакеты с source route.

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

net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth2.rp_filter = 0 net.ipv4.conf.eth1.rp_filter = 0 net.ipv4.conf.ppp0.rp_filter = 0

видимо, да отключил фаервол, прописал построутинг вроде работает хорошо где iptables может рубить пакеты?

может дадите електронку я скину вам конфиг фаервола, если не трудно посмотрите?

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

Dec 18 22:39:29 gateway IN=eth2 OUT= MAC=00:0e:2e:a9:37:16:00:30:05:04:29:5f:08:00 SRC=213.180.204.8 DST=82.207.108.130 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=15474 DF PROTO=TCP SPT=80 DPT=47333 WINDOW=4096 RES=0x00 ACK SYN URGP=0 Dec 18 22:39:32 gateway IN=eth2 OUT= MAC=00:0e:2e:a9:37:16:00:30:05:04:29:5f:08:00 SRC=213.180.204.8 DST=82.207.108.130 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=19742 DF PROTO=TCP SPT=80 DPT=47333 WINDOW=4096 RES=0x00 ACK SYN URGP=0

Вот видимо обратный путь лежит через 82.207.108.130.... но почему???

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

Эти пакеты (если -j LOG) стоят в таблице filter --- нормальное явление. Объясняю подробнее, wget запускается без указания ip-адреса с которого нужно отправлять запрос, поэтом этот ip-адрес выбирает ядро. При этом расматривается только таблица по умолчанию, а по ней до ya.ru будет путь через "ppp0: 82.207.108.130 gw 195.5.5.206". Поэтому от wget пакеты идут с адресом 82.207.108.130, далее они маркируются, заворачиваются в eth2 и при выходе NATятся. Обратные пакеты от ya.ru приходят на eth2 на адрес 194.44.200.229, при прохождении через conntrack идет "обратный NAT" и у пакета становится адрес 82.207.108.130.

Возможно у вас проблема из-за MTU (так как радиоканал), попробуйте урезать максимальный размер tcp пакета:

iptables -I OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 500

500 байт это, конечно, мало, это так, на время эксперимента.

Конфиг iptables я готов посмотреть, но только часов через 8 (сейчас пойду спать) почта: mky Собака mail.ru

Пока, если есть возможность и через маршрутизатор больше не идет другого трафика, можете попробовать запустить tcpdump на всех интерфейсах, и запустить wget. Может какие интерестные icmp пакеты приходя...

# tcpdump -n -nn port '! 22' # все, исключая 22 (если консоль по ssh)

P.S. Когда пишите сообшение с логами tcpdump'а не забывайте выбирать в выпадающем меню "User line break" и проверять что текст нормально выглядит с помощью кнопочки "Предпросмотр", а то очень тяжело читать...

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

Да нет там много чего бегает :)

TCPMSS менял ничего не дало...

Конфиги фаервола выслал

Да пробовал я так "User line break" но всеравно кидало как есть, попробую еще раз, извините за неудобства.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.