Cramac Опубликовано 3 апреля, 2021 · Жалоба Всем привет. Помогите разобраться. Как обычно, все работало и вдруг сломали.... Есть сервер доступа, на нем два аплинка настроены сетевые: auto em1 iface em1 inet static address 188.х.х.242 netmask 255.255.255.0 gateway 188.х.х.241 auto vlan900 iface vlan900 inet static address 172.31.255.2 netmask 255.255.255.0 vlan_raw_device p3p1 up ip route add default dev vlan900 via 172.31.255.1 table wan2 up ip rule add from 172.31.255.2 table wan2 up ip rule add fwmark 2 table wan2 cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 10 wan1 20 wan2 30 wan3 маршрут выбирает правильный ip ro get 8.8.8.8 mark 2 8.8.8.8 via 172.31.255.1 dev vlan900 src 172.31.255.2 mark 2 cache трафик маркирую iptables -L -t mangle -nv Chain PREROUTING (policy ACCEPT 53M packets, 51G bytes) pkts bytes target prot opt in out source destination 20M 3918M MARK all -- * * 192.168.0.0/16 0.0.0.0/0 MARK set 0x4 16115 1972K MARK all -- * * 192.168.5.219 0.0.0.0/0 MARK set 0x3 6747K 1292M MARK all -- * * 192.168.1.213 0.0.0.0/0 MARK set 0x3 27193 4024K MARK all -- * * 192.168.6.145 0.0.0.0/0 MARK set 0x3 50820 8241K MARK all -- * * 192.168.1.200 0.0.0.0/0 MARK set 0x3 95M 18G MARK all -- * * 192.168.10.0/24 0.0.0.0/0 MARK set 0x3 75M 20G MARK all -- * * 192.168.5.0/24 0.0.0.0/0 MARK set 0x3 45M 5837M MARK all -- * * 192.168.11.0/24 0.0.0.0/0 MARK set 0x3 3528K 1885M MARK all -- * * 192.168.13.236 0.0.0.0/0 MARK set 0x3 278M 126G MARK all -- * * 192.168.13.0/24 0.0.0.0/0 MARK set 0x3 278M 126G MARK all -- * * 192.168.13.0/24 0.0.0.0/0 MARK set 0x3 109M 20G MARK all -- * * 192.168.12.0/24 0.0.0.0/0 MARK set 0x3 81M 11G MARK all -- * * 192.168.7.0/24 0.0.0.0/0 MARK set 0x3 5816 4183K MARK all -- * * 192.168.7.120 0.0.0.0/0 MARK set 0x4 таблица ната: iptables -L -t nat -n Chain PREROUTING (policy ACCEPT) target prot opt source destination .... Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.0.0.0/8 0.0.0.0/0 to:188.х.х.242 SNAT all -- 172.0.0.0/8 0.0.0.0/0 to:188.х.х.242 SNAT all -- 192.168.0.0/16 0.0.0.0/0 to:188.х.х.242 SNAT all -- 192.168.0.0/16 0.0.0.0/0 to:172.31.255.2 SNAT all -- 192.168.0.0/16 0.0.0.0/0 to:178.х.х.213 но ничего не ходит через второй аплинк, пока не сделаю echo 0 >/proc/sys/net/ipv4/conf/vlan900/rp_filter хотя до этого все работало без этой команды. Что я упускаю? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 3 апреля, 2021 · Жалоба Почитаете это. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 4 апреля, 2021 · Жалоба rp фильтр - гадость, которую бездумно понавключали ради секурности везде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 апреля, 2021 · Жалоба Смущает то, что до установки второй сетевой, все работало без данного рп фильтра Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 4 апреля, 2021 · Жалоба Так до установки второй сетевой платы и маршрут видимо был один. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 апреля, 2021 · Жалоба 1 час назад, alibek сказал: Так до установки второй сетевой платы и маршрут видимо был один. в том то и дело, что нет. Была сетевуха, с двумя интерфейсами. Одна в локалку, другая к аплинку. Поднял влан на интерфейсе что в локалку, в этом влане шел второй аплинк. Настроил маршруты, все работало. Про rp_filter даже не думалось. Вот только не помню, работал ли пинг типо: ping -I vlan900 8.8.8.8 сейчас так не пингует, тспдамп показывает только ARP, Request who-has dns.google tell 172.31.255.2 а если пустить пинг ping -I 172.31.255.2 8.8.8.8 тогда есть ответы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 5 апреля, 2021 · Жалоба Встречалось нечто похожее -- локалка + линк, добавили 2 линк, всё работало несколько лет до перезагрузки, потом как отрезало. на удалённой стороне айпишка шлюза была прописана как секондари, потом её убрали, трафик так и ходил до перезагрузки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dryukov Опубликовано 6 апреля, 2021 (изменено) · Жалоба Ну это значит что на интерфейс приходят пакеты с адресом назначения от другого интерфейса во входящий цепочке INPUT про FORWARD нескажу с лета. Или из локалки или из интернета, задампай tpcdump-ом интерфейсы. В 04.04.2021 в 12:42, Cramac сказал: ARP, Request who-has dns.google tell 172.31.255.2 так может быть только если route dev а не route via, а вот dev мог получиться если не сработал default GW, если в правилах PREROUTING адрес источника пока пуст или 127.0.0.1 Изменено 6 апреля, 2021 пользователем dryukov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dryukov Опубликовано 6 апреля, 2021 · Жалоба у тебя фильтрации по портам нет, а тупо по подсетям вроде, можно было бы упростить. ip rule add from 192.168.0.0/24 table wan2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 7 апреля, 2021 · Жалоба да, только подсети в разные аплинки направляю. п.с. Второй вопрос. На этом сервере помирает хдд, решил обновить. Поставил убунту 20. Все настроил как было, но при включении форварда и добавление правил snat, сервер начинает с потерями отвечать по локалке, а внешний, периодически выдает превышение жизни ттл Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dryukov Опубликовано 7 апреля, 2021 · Жалоба если превышене TTL то где то кольцо еще ))) видимо от туда откуда и rp_filter срабатывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 7 апреля, 2021 · Жалоба @dryukov чистая ос, даже до фильтра еще не дошел. Но тож грешу на кольцо. опять же, старая убунта стоит работает... от куда взялось кольцо. стоит 4 сетевые, включены три: лан1 - 10.10.10.1/24, 91.х.х.254/24 Роуты: 10.0.0.0/8 виа 10.10.10.254 172.20.0.0/16 виа 10.10.10.254 192.168.0.0/16 виа 10.10.10.254 лан2 - аплинк1 ип адрес и шлюз по умолчанию лан3 - аплинк2 Ип адрес пингую из вне 91.х.х.254, 10 нормально 10 превышен ттл вот такой старый, перенес в нетплан: Скрытый текст # The primary network interface auto p3p1 iface p3p1 inet static address 10.10.10.1 netmask 255.255.255.0 network 10.10.10.0 broadcast 10.10.10.255 #gateway 10.10.10.254 up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.10.10.254 up route add -net 172.40.0.0 netmask 255.255.0.0 gw 10.10.10.254 up route add -net 172.20.0.0 netmask 255.255.0.0 gw 10.10.10.254 up route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.10.10.254 auto p3p1:0 iface p3p1:0 inet static address 91.х.х.254 netmask 255.255.255.0 auto em1 iface em1 inet static address 188.х.х.242 netmask 255.255.255.0 gateway 188.х.х.241 auto vlan900 iface vlan900 inet static address 172.31.255.2 netmask 255.255.255.0 vlan_raw_device p3p1 up ip route add default dev vlan900 via 172.31.255.1 table wan2 up ip rule add from 172.31.255.2 table wan2 up ip rule add fwmark 2 table wan2 auto p262p1 iface p262p1 inet static address 178.х.х.213 netmask 255.255.255.254 up ip route add default dev p262p1 via 178.х.х.212 table wan3 up ip rule add from 178.х.х.213 table wan3 up ip rule add fwmark 4 table wan3 auto p262p2 iface p262p2 inet static address 10.10.0.51 netmask 255.255.255.0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dryukov Опубликовано 7 апреля, 2021 · Жалоба кольцо снаружи ) вы друг другу кидаете пакеты уменьшая ttl и потом получаешь ICMP мол кончился ttl. Запусти tcpdump -i xxxx -n всё будет наглядно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 7 апреля, 2021 · Жалоба странно это, как тут образуется кольцо. Кольцо получается на внутреннем интерфейсе, на нем висит адрес что с превышением ттл пингуется и внутренний адрес, который пингуется с потерями огромными. Хочу по большее теории собрать, а то ночью не хочется в просак опять попасть. Может у меня настройки изначально не верные? Раз в разные аплинки не может ходить без rp_filter? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 11 июля, 2021 · Жалоба Вернусь к данной теме. Теперь беда в том что клиенты с одного аплинка, не могут зайти на адреса в другом аплинке. т.е. Есть блок адресов, выдал, работают через первый аплинк. Все абоненты с серыми адресами, через второй. В итоге, с серого адреса, трасерт до белого адреса (на первом аплинке) идет через второй аплинк и упирается в неизвестность... в итоге доступа к внутренним серверам нет у абонентов с серыми адресами... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lugoblin Опубликовано 14 июля, 2021 · Жалоба @Cramac , покажите вывод: ip addr ip rule ip route ip route show table wan1 ip route show table wan2 ip route show table wan3 И уточните, с какого именно на какой адрес не проходит траффик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 июля, 2021 · Жалоба ip addr: Скрытый текст 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 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: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 90:e2:ba:8d:ed:68 brd ff:ff:ff:ff:ff:ff inet 178.x.x.213/31 scope global enp1s0f0 valid_lft forever preferred_lft forever inet6 fe80::92e2:baff:fe8d:ed68/64 scope link valid_lft forever preferred_lft forever 3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 10000 link/ether 00:1e:67:79:9c:01 brd ff:ff:ff:ff:ff:ff inet 188.x.x.242/24 brd 188.x.x.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::21e:67ff:fe79:9c01/64 scope link valid_lft forever preferred_lft forever 4: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 90:e2:ba:8d:ed:69 brd ff:ff:ff:ff:ff:ff inet 10.10.10.1/24 brd 10.10.10.255 scope global enp1s0f1 valid_lft forever preferred_lft forever inet 91.x.51.254/24 brd 91.x.51.255 scope global enp1s0f1 valid_lft forever preferred_lft forever inet6 fe80::92e2:baff:fe8d:ed69/64 scope link valid_lft forever preferred_lft forever 5: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 10000 link/ether 00:1e:67:79:9c:00 brd ff:ff:ff:ff:ff:ff 1144328: ipoe235: <POINTOPOINT,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 100 link/ether 90:e2:ba:8d:ed:69 peer ff:ff:ff:ff:ff:ff inet 10.10.10.1 peer 192.168.12.253/32 scope global ipoe235 valid_lft forever preferred_lft forever inet6 fe80::92e2:baff:fe8d:ed69/64 scope link valid_lft forever preferred_lft forever ... и еще клиенты с серыми адресами в сети 192.168.0.0/16 1143323: ipoe105: <POINTOPOINT,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 100 link/ether 90:e2:ba:8d:ed:69 peer ff:ff:ff:ff:ff:ff inet 10.10.10.1 peer 91.x.51.47/32 scope global ipoe105 valid_lft forever preferred_lft forever inet6 fe80::92e2:baff:fe8d:ed69/64 scope link valid_lft forever preferred_lft forever ... и еще клиенты с белыми адресами в сети 91.х.51.0/24 ip rule 0: from all lookup local 32764: from all fwmark 0x4 lookup wan3 32765: from 178.x.x.213 lookup wan3 32766: from all lookup main 32767: from all lookup default ip route Скрытый текст default via 188.x.x.241 dev eno1 proto static 10.0.0.0/8 via 10.10.10.254 dev enp1s0f1 proto static 10.10.10.0/24 dev enp1s0f1 proto kernel scope link src 10.10.10.1 10.254.3.2 dev ipoe492 scope link src 10.10.10.1 10.254.3.4 dev ipoe21 scope link src 10.10.10.1 .... 91.x.51.0/24 dev enp1s0f1 proto kernel scope link src 91.x.51.254 91.x.51.2 dev ipoe297 proto kernel scope link src 10.10.10.1 .... 172.20.0.0/16 via 10.10.10.254 dev enp1s0f1 proto static 172.20.0.2 dev ipoe142 scope link src 10.10.10.1 172.20.0.5 dev ipoe65 scope link src 10.10.10.1 172.20.0.6 dev ipoe58 scope link src 10.10.10.1 172.20.0.7 dev ipoe561 scope link src 10.10.10.1 172.20.0.9 dev ipoe579 scope link src 10.10.10.1 .... 172.31.255.0/24 dev vlan900 proto kernel scope link src 172.31.255.101 172.40.0.0/16 via 10.10.10.254 dev enp1s0f1 proto static 172.40.2.14 dev ipoe582 scope link src 10.10.10.1 172.40.2.20 dev ipoe463 scope link src 10.10.10.1 172.40.4.9 dev ipoe576 scope link src 10.10.10.1 ...... 178.x.x.212/31 dev enp1s0f0 proto kernel scope link src 178.x.x.213 188.x.x.0/24 dev eno1 proto kernel scope link src 188.x.x.242 192.168.0.0/16 via 10.10.10.254 dev enp1s0f1 proto static 192.168.0.108 dev ipoe487 proto kernel scope link src 10.10.10.1 192.168.0.136 dev ipoe344 proto kernel scope link src 10.10.10.1 192.168.1.5 dev ipoe39 proto kernel scope link src 10.10.10.1 192.168.1.8 dev ipoe471 proto kernel scope link src 10.10.10.1 .... ip route show table wan3 default via 178.x.x.212 dev enp1s0f0 сейчас делю по аплинкам так: iptables -L -n -t mangle Chain PREROUTING (policy ACCEPT) target prot opt source destination MARK all -- 192.168.0.0/16 0.0.0.0/0 MARK set 0x4 MARK all -- 192.168.13.233 0.0.0.0/0 MARK set 0x3 MARK all -- 192.168.12.55 0.0.0.0/0 MARK set 0x3 MARK all -- 192.168.7.120 0.0.0.0/0 MARK set 0x3 всех с серыми отправляю в аплинк2, всех остальных (с белыми) в аплинк1 в итоге серые адреса не могут зайти на белые адреса. Перенаправив нужного абонента с серым адресом в аплинк1, доступ появляется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lugoblin Опубликовано 15 июля, 2021 · Жалоба 19 hours ago, Cramac said: всех с серыми отправляю в аплинк2 Во первых, вот для этого вам не требуется морочиться с маркировкой пакетов. Если критерий для выбора маршрута это src_addr, то это можно делать непосредственно в ip rule. 19 hours ago, Cramac said: 32765: from 178.x.x.213 lookup wan3 ... ip route show table wan3 default via 178.x.x.212 dev enp1s0f0 Во вторых, у вас таблица wan3 куцая. Проверьте сниффером, но я подозреваю что пакеты из серой сети до 178.x.x.213 добираются, а вот ответные уходят в дефолтный маршрут wan3, т.к. к ним сразу применяется правило 32765. В упрощённом случае, таблица wan3 должна содержать копию таблицы main, и отличаться только дефолтным маршрутом. Проверьте, если дело в этом то надо будет понять зачем в вас так много всего в таблице main и придумать как бы описать по аккуратнее то что ван нужно. Предположу, что адрес 188.x.x.242 отвечает серым сетям как надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 15 июля, 2021 · Жалоба 13 часов назад, lugoblin сказал: Во вторых, у вас таблица wan3 куцая. Проверьте сниффером, но я подозреваю что пакеты из серой сети до 178.x.x.213 добираются, а вот ответные уходят в дефолтный маршрут wan3, т.к. к ним сразу применяется правило 32765. Подскажите, где смотреть, чет не пойму... Если смотреть ипое интерфейс, там типо 18:25:45.915898 IP 192.168.7.120 > 87.250.250.242: не понять через какой интерфейс идет. если смотреть интерфейс аплинка, там все идет с адреса аплинка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lugoblin Опубликовано 15 июля, 2021 · Жалоба 4 hours ago, Cramac said: Подскажите, где смотреть, чет не пойму... Если смотреть ипое интерфейс, там типо 18:25:45.915898 IP 192.168.7.120 > 87.250.250.242: не понять через какой интерфейс идет. если смотреть интерфейс аплинка, там все идет с адреса аплинка. Так вы, кажется, всё уже увидели. Если пакет пришёл на внутренний интерфейс для внешнего адреса, то ответ, хоть и от внешнего адреса, должен уходить с внутреннего же итерфейса. А если он уходит с внешнего интерфейса, значит по нему принято неверное решение о маршрутизации и следующий хоп его похерит. Как понять через какой интерфейс: смотрите на один интерфейс за раз. На какой смотрите, через тот и идёт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 16 июля, 2021 · Жалоба @lugoblin так сервер рабочий, был бы тестовый, можно было отследить, а тут трафик с обоих интерфейсов идет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lugoblin Опубликовано 16 июля, 2021 · Жалоба 9 hours ago, Cramac said: @lugoblin так сервер рабочий, был бы тестовый, можно было отследить, а тут трафик с обоих интерфейсов идет Фильтрами же. server# tcpdump -i интерфейс port 31337 client# telnet 178.x.x.213 31337 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 16 июля, 2021 · Жалоба да я уж потом про это подумал, но судя по всему, запросы уходят и приходят в нужный интерфейс: Скрытый текст tcpdump -i enp1s0f0 -nn 'port 3306' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes 21:42:24.562430 IP 178.х.х.213.55654 > 91.х.50.8.3306: Flags , seq 915493358, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 21:42:24.615878 IP 91.х.50.8.3306 > 178.х.х.213.55654: Flags [R.], seq 0, ack 915493359, win 0, length 0 21:42:25.129450 IP 178.х.х.213.55654 > 91.х.50.8.3306: Flags , seq 915493358, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 21:42:25.182952 IP 91.х.50.8.3306 > 178.х.х.213.55654: Flags [R.], seq 0, ack 1, win 0, length 0 21:42:25.692785 IP 178.х.х.213.55654 > 91.х.50.8.3306: Flags , seq 915493358, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 21:42:25.746258 IP 91.х.50.8.3306 > 178.х.х.213.55654: Flags [R.], seq 0, ack 1, win 0, length 0 21:42:26.254610 IP 178.х.х.213.55654 > 91.х.50.8.3306: Flags , seq 915493358, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lugoblin Опубликовано 17 июля, 2021 · Жалоба @Cramac Подключение с 178.х.х.213 на 91.х.50.8:3306 это то что вы пытаетесь починить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 17 июля, 2021 · Жалоба Нет, это адрес в другом сегменте, на другом НАСе Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
