- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 08:42 , 23-Авг-12 (1)
сначала проверь что openvpn у тебя по tcp настроен, у всех бывают досадные мелкие ошибки :)tcpdump по интерфейсам eth1, там увидишь уходят ли пакеты по нужным тебе интерфейсам и что приходит в ответ (и приходит ли вообще). Дальше проще копать будет. это мне кажеться лишним совсем т.к. основные сети и гейты для каждой таблицы указаны выше: ip route add $P1_NET dev $IF1 table PROV1 ip route add $P2_NET dev $IF2 table PROV1 ip route add $P3_NET dev $IF3 table PROV1 ip route add 127.0.0.0/8 dev lo table PROV1 ip route add $P1_NET dev $IF1 table PROV2 ip route add $P2_NET dev $IF2 table PROV2 ip route add $P3_NET dev $IF3 table PROV2 ip route add 127.0.0.0/8 dev lo table PROV2 ip route add $P1_NET dev $IF1 table PROV3 ip route add $P2_NET dev $IF2 table PROV3 ip route add $P3_NET dev $IF3 table PROV3 ip route add 127.0.0.0/8 dev lo table PROV3 максимум туда локальные сети включить можно. т.к. исходящий пакет пойдёт по гейту а входящий из инета в другой канал инета не пойдёт (не должен если сам не перенаправишь...), максимум в локалку или в table local ещё осядет не дойдя до твоих таблиц так? следовательно и эти маршруты не будут использоваться никогда
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 08:44 , 23-Авг-12 (2)
тупанул, у тебя же это локалки так что правила оставлять :)
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 09:34 , 23-Авг-12 (3)
> сначала проверь что openvpn у тебя по tcp настроен, у всех бывают > досадные мелкие ошибки :) Да, проверял. Везде установлен протокол TCP. > tcpdump по интерфейсам eth1, там увидишь уходят ли пакеты по нужным тебе > интерфейсам и что приходит в ответ (и приходит ли вообще). > Дальше проще копать будет. выполняю коннект к ххх.ххх.ххх.ххх порт 333 - Это соединение должно маркироваться как 3 и отправляться через PROV3 (eth1:0) запускаю tcpdump так: tcpdump -i eth1:0 -n| grep "xxx.xxx.xxx.xxx\.333" получаю: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes 09:23:52.049027 IP 192.168.1.100.38201 > xxx.xxx.xxx.xxx.333: S 1640052958:1640052958(0) win 5840 <mss 1460,sackOK,timestamp 7045169 0,nop,wscale 6> 09:23:55.049115 IP 192.168.1.100.38201 > xxx.xxx.xxx.xxx.333: S 1640052958:1640052958(0) win 5840 <mss 1460,sackOK,timestamp 7045920 0,nop,wscale 6> 09:24:01.048535 IP 192.168.1.100.38201 > xxx.xxx.xxx.xxx.333: S 1640052958:1640052958(0) win 5840 <mss 1460,sackOK,timestamp 7047420 0,nop,wscale 6> 09:24:07.049353 IP 192.168.1.100.38202 > xxx.xxx.xxx.xxx.333: S 1875663028:1875663028(0) win 5840 <mss 1460,sackOK,timestamp 7048920 0,nop,wscale 6> 09:24:10.052531 IP 192.168.1.100.38202 > xxx.xxx.xxx.xxx.333: S 1875663028:1875663028(0) win 5840 <mss 1460,sackOK,timestamp 7049670 0,nop,wscale 6> Есть мысли к размышлению?
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 10:08 , 23-Авг-12 (4)
если правильно понимаю схему сверху на интерфейсе eth1:0 должен быть адр 192.168.2.100.команда проще: tcpdump -i eth1:0 -n tcp port 333 мысли: в output у пакета уже есть src адрес 1.100 меткой ты его перенаправляешь в сетку 2.х там он уходит на нужный гейт а вот возвращаясь на гейт он(новый пакет того же соединения) обратно приводиться к адресу 1.100 и вот этот адрес для гейта загадка он не знает куда его послать и отправляет обратно в инет по своему дефолтному гейту. выход - попробуй snat.
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 10:11 , 23-Авг-12 (5)
возможно в настройках openvpn сразу можно прописать интерфейс с которого выходить, попробуй это поищи, тогда сразу нормлаьный адрес пакета будет без snat - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 10:18 , 23-Авг-12 (6)
> если правильно понимаю схему сверху на интерфейсе eth1:0 должен быть адр 192.168.2.100. угу, в eth1:0 192.168.2.100 > команда проще: tcpdump -i eth1:0 -n tcp port 333 с этим разобрался уже! ;) > мысли: в output у пакета уже есть src адрес 1.100 меткой ты > его перенаправляешь в сетку 2.х там он уходит на нужный гейт > а вот возвращаясь на гейт он(новый пакет того же соединения) обратно > приводиться к адресу 1.100 и вот этот адрес для гейта загадка > он не знает куда его послать и отправляет обратно в инет > по своему дефолтному гейту. выход - попробуй snat. То есть так? iptables -t nat -A POSTROUTING -s x.x.x.x --sport 333 -d 192.168.1.100 -j SNAT --to-source 192.168.2.100
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 10:23 , 23-Авг-12 (7)
То есть так iptables -t nat -A POSTROUTING -p tcp --dport 111 -j SNAT --to-source 192.168.0.100 iptables -t nat -A POSTROUTING -p tcp --dport 222 -j SNAT --to-source 192.168.1.100 iptables -t nat -A POSTROUTING -p tcp --dport 333 -j SNAT --to-source 192.168.2.100
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 10:25 , 23-Авг-12 (8)
снова косяк :) везде нужно -d xxx.xxx.xxx.xxx добавить это адрес твоего сервака
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 10:25 , 23-Авг-12 (9)
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 10:36 , 23-Авг-12 (11)
> твоего vpn сервака Угу, сделал! Тоже самое, что и настройка в самом Openvpn! Спасибо, пригодиться на будущее! Но по прежнему не работает :(
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 10:37 , 23-Авг-12 (12)
а может лучше так iptables -t nat -A POSTROUTING -o eth0 ! -d 192.168.0.0/24 -j SNAT --to-source 192.168.0.100 так все инет соединения на этого прова пойдут c правильными адресами и аналогично другиеiptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.1.0/24 -j SNAT --to-source 192.168.1.100 iptables -t nat -A POSTROUTING -o eth1:0 ! -d 192.168.2.0/24 -j SNAT --to-source 192.168.2.100
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 10:48 , 23-Авг-12 (15)
> а может лучше так > iptables -t nat -A POSTROUTING -o eth1:0 ! -d 192.168.2.0/24 -j SNAT > --to-source 192.168.2.100 С алиасами это не прокатывает...
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 10:58 , 23-Авг-12 (16)
>> а может лучше так >> iptables -t nat -A POSTROUTING -o eth1:0 ! -d 192.168.2.0/24 -j SNAT >> --to-source 192.168.2.100 > С алиасами это не прокатывает...Походу не только это не прокатывает! Я тестировал соединение через eth1:0 - через это не работает, а вот с eth0 и eth1 работает! Надо думать как eth1:0 (alias) запустить...
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 11:22 , 23-Авг-12 (17)
> Надо думать как eth1:0 (alias) запустить...попробуй так iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.1.0/24 -m ! --mark 3 -j SNAT --to-source 192.168.1.100 и одну из iptables -t nat -A POSTROUTING -m --mark 3 -j SNAT --to-source 192.168.2.100 iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.2.0/24 -m --mark 3 -j SNAT --to-source 192.168.2.100 на eth1:0 будет ходить только по метке 3
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 12:25 , 23-Авг-12 (18)
>> Надо думать как eth1:0 (alias) запустить... > попробуй так > iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.1.0/24 -m ! > --mark 3 -j SNAT --to-source 192.168.1.100 > и одну из > iptables -t nat -A POSTROUTING -m --mark 3 -j SNAT --to-source 192.168.2.100 > iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.2.0/24 -m --mark > 3 -j SNAT --to-source 192.168.2.100 > на eth1:0 будет ходить только по метке 3 Попробовал, не фурыкает. метку правильней так указывать: ... -m mark --mark 3 ... З.Ы. Спасибо тебе за терпение и неоценимую помощь! Думаем дальше... :)
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 13:11 , 23-Авг-12 (19)
> метку правильней так указывать: ... -m mark --mark 3 верно я по памяти и без проверки... тогда давай tcpdump что показывает с фильтром по 333 порту на eth1:0 - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 14:18 , 23-Авг-12 (20)
> тогда давай tcpdump что показывает с фильтром по 333 порту на eth1:0 В качестве IP сервера взял 8.8.4.4 iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.1.0/24 -m mark ! --mark 3 -j SNAT --to-source 192.168.1.100 iptables -t nat -A POSTROUTING -m mark --mark 3 -j SNAT --to-source 192.168.2.100 проверряю трасертом пот TCP: # tracert 8.8.4.4 -p 333 -T Результат # tcpdump -i eth1:0 -n host 8.8.4.4 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes 14:14:06.783410 IP 192.168.2.100.38870 > 8.8.4.4.333: S 2215836622:2215836622(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783493 IP 192.168.2.100.60182 > 8.8.4.4.333: S 2228501733:2228501733(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783530 IP 192.168.2.100.48093 > 8.8.4.4.333: S 1471125268:1471125268(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783563 IP 192.168.2.100.58545 > 8.8.4.4.333: S 2833435517:2833435517(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783594 IP 192.168.2.100.36424 > 8.8.4.4.333: S 432224733:432224733(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783625 IP 192.168.2.100.47092 > 8.8.4.4.333: S 4294386555:4294386555(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783658 IP 192.168.2.100.42506 > 8.8.4.4.333: S 2288915606:2288915606(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783689 IP 192.168.2.100.60482 > 8.8.4.4.333: S 1256061207:1256061207(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783717 IP 192.168.2.100.42826 > 8.8.4.4.333: S 3719530699:3719530699(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783751 IP 192.168.2.100.51600 > 8.8.4.4.333: S 586762961:586762961(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783785 IP 192.168.2.100.50263 > 8.8.4.4.333: S 1455313317:1455313317(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2> 14:14:06.783813 IP 192.168.2.100.60522 > 8.8.4.4.333: S 68378390:68378390(0) win 5840 <mss 1460,sackOK,timestamp 1332826539 0,nop,wscale 2>
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 14:46 , 23-Авг-12 (21)
ну и что ты посмотрел этими командами? только то что пакеты уходят вроде как правильно. а нужно проверить устанавливается ли соединение с впн сервером. так что включай свой впн клиент и его пакеты смотри тспдампом и лог сюда.
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 15:51 , 23-Авг-12 (22)
> ну и что ты посмотрел этими командами? только то что пакеты уходят > вроде как правильно. > а нужно проверить устанавливается ли соединение с впн сервером. так что включай > свой впн клиент и его пакеты смотри тспдампом и лог сюда. Не устанавливается vpn соединение и с 8.8.4.4 тоже не работает Проверял и так так....
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 15:59 , 23-Авг-12 (23)
>> ну и что ты посмотрел этими командами? только то что пакеты уходят >> вроде как правильно. >> а нужно проверить устанавливается ли соединение с впн сервером. так что включай >> свой впн клиент и его пакеты смотри тспдампом и лог сюда. > Не устанавливается vpn соединение и с 8.8.4.4 тоже не работает > Проверял и так так....парень либо логи либо ковыряй сам. адрес свой можешь заменить на что хочешь, важно что _реально_ ходит когда конектится впн клиент. а не мозгоклюйство с 8.8.4.4
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 16:08 , 23-Авг-12 (25)
>>> ну и что ты посмотрел этими командами? только то что пакеты уходят >>> вроде как правильно. >>> а нужно проверить устанавливается ли соединение с впн сервером. так что включай >>> свой впн клиент и его пакеты смотри тспдампом и лог сюда. >> Не устанавливается vpn соединение и с 8.8.4.4 тоже не работает >> Проверял и так так.... > парень либо логи либо ковыряй сам. адрес свой можешь заменить на что > хочешь, важно что _реально_ ходит когда конектится впн клиент. а не > мозгоклюйство с 8.8.4.4 Вот с vpn соединением. На [сервер 2] ничего не приходит. :~# tcpdump -i eth1:0 -n host xxx.xxx.xxx.xxx and dst port 333 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes 16:05:06.125683 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 3768307221:3768307221(0) win 5840 <mss 1460,sackOK,timestamp 5356820 0,nop,wscale 6> 16:05:07.890308 IP 192.168.2.100.45834 > xxx.xxx.xxx.xxx.333: S 3800988509:3800988509(0) win 5840 <mss 1460,sackOK,timestamp 5357261 0,nop,wscale 6> 16:05:09.122753 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 3768307221:3768307221(0) win 5840 <mss 1460,sackOK,timestamp 5357570 0,nop,wscale 6> 16:05:10.886762 IP 192.168.2.100.45834 > xxx.xxx.xxx.xxx.333: S 3800988509:3800988509(0) win 5840 <mss 1460,sackOK,timestamp 5358011 0,nop,wscale 6> 16:05:15.122750 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 3768307221:3768307221(0) win 5840 <mss 1460,sackOK,timestamp 5359070 0,nop,wscale 6> 16:05:21.125910 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 4002686079:4002686079(0) win 5840 <mss 1460,sackOK,timestamp 5360570 0,nop,wscale 6> 16:05:24.122749 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 4002686079:4002686079(0) win 5840 <mss 1460,sackOK,timestamp 5361320 0,nop,wscale 6> 16:05:24.820013 IP 192.168.2.100.45835 > xxx.xxx.xxx.xxx.333: S 4071401219:4071401219(0) win 5840 <mss 1460,sackOK,timestamp 5361494 0,nop,wscale 6> 16:05:27.819251 IP 192.168.2.100.45835 > xxx.xxx.xxx.xxx.333: S 4071401219:4071401219(0) win 5840 <mss 1460,sackOK,timestamp 5362244 0,nop,wscale 6> 16:05:30.122749 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 4002686079:4002686079(0) win 5840 <mss 1460,sackOK,timestamp 5362820 0,nop,wscale 6> 16:05:33.819256 IP 192.168.2.100.45835 > xxx.xxx.xxx.xxx.333: S 4071401219:4071401219(0) win 5840 <mss 1460,sackOK,timestamp 5363744 0,nop,wscale 6> 16:05:36.126193 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 4237065420:4237065420(0) win 5840 <mss 1460,sackOK,timestamp 5364320 0,nop,wscale 6> 16:05:39.122746 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 4237065420:4237065420(0) win 5840 <mss 1460,sackOK,timestamp 5365070 0,nop,wscale 6> 16:05:39.820334 IP 192.168.2.100.45836 > xxx.xxx.xxx.xxx.333: S 12268998:12268998(0) win 5840 <mss 1460,sackOK,timestamp 5365244 0,nop,wscale 6> 16:05:42.819246 IP 192.168.2.100.45836 > xxx.xxx.xxx.xxx.333: S 12268998:12268998(0) win 5840 <mss 1460,sackOK,timestamp 5365994 0,nop,wscale 6> 16:05:45.122749 IP 192.168.2.100.333 > xxx.xxx.xxx.xxx.333: S 4237065420:4237065420(0) win 5840 <mss 1460,sackOK,timestamp 5366570 0,nop,wscale 6>
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 16:37 , 23-Авг-12 (26)
1. > :~# tcpdump -i eth1:0 -n host xxx.xxx.xxx.xxx and dst port 333 с dst ты снова режешь трафик только исходящий смотришь. ты уже и так убедился что траф уходит куда надо, зачем тебе dst? тебе нужны _все_ пакеты с портом 333 что уходит и что приходит в ответ. так кажется надо (нет возможности проверить) #tcpdump -i eth1:0 -n host xxx.xxx.xxx.xxx and port 333 2. также командой смотришь на своём втором сервере что ходит на этом порту в оба направления #tcpdump -i ethХХХ port 333 и проверь что фаер пропускает. з.ы. нех краить инфу, не деньги, достаточно убрать айпишник. - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 18:09 , 23-Авг-12 (27)
старнно, пробую пинговать:# ping -I eth1 ya.ru PING ya.ru (77.88.21.3) from 192.168.1.100 eth1: 56(84) bytes of data. 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=1 ttl=59 time=2.78 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=2 ttl=59 time=2.93 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=3 ttl=59 time=2.91 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=4 ttl=59 time=3.10 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=5 ttl=59 time=3.04 ms ~# ping -I eth1:0 ya.ru VVVVVVVVVVVV - Почему тут 192.168.0.100???? PING ya.ru (77.88.21.3) from 192.168.0.100 eth1:0: 56(84) bytes of data. 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=1 ttl=59 time=3.35 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=2 ttl=59 time=2.72 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=3 ttl=59 time=3.01 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=4 ttl=59 time=2.79 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=5 ttl=59 time=3.46 ms # ping -I 192.168.2.100 ya.ru PING ya.ru (77.88.21.3) from 192.168.2.100 : 56(84) bytes of data. 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=1 ttl=59 time=2.87 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=2 ttl=59 time=2.72 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=3 ttl=59 time=2.82 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=4 ttl=59 time=3.00 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=5 ttl=59 time=2.89 ms Судя по откликам, во всех случаях пинги уходят через eth1 (192.168.1.100) Пинг через eth0 (jnrkbr 5-6 мс): ping -I eth0 ya.ru PING ya.ru (77.88.21.3) from 192.168.0.100 eth0: 56(84) bytes of data. 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=1 ttl=57 time=5.09 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=2 ttl=57 time=5.51 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=3 ttl=57 time=5.47 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=4 ttl=57 time=5.12 ms 64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=5 ttl=57 time=5.86 ms Через eth1:0 (192.168.2.100) должен быть отклик не менее 30 мс. Не работает направление трафика в нужные шлюзы... :( - Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 22:29 , 23-Авг-12 (29)
попробуй tcptraceroute #tcptraceroute -i eth1:0 -p 333 xxx.xxx.xxx.xxx через правильный шлюз идёт? на стороне впн сервера должны приходить пакеты с адреса твоего 3го прова.
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 16:03 , 23-Авг-12 (24)
> ну и что ты посмотрел этими командами? только то что пакеты уходят > вроде как правильно. > а нужно проверить устанавливается ли соединение с впн сервером. так что включай > свой впн клиент и его пакеты смотри тспдампом и лог сюда. так же на самом [сервере 2] проверял tcpdump'ом, пакеты до него не доходят... - Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 22:26 , 23-Авг-12 (28)
#tcptraceroute -i eth1:0 -p 333 xxx.xxx.xxx.xxx через правильный шлюз идёт?
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 22:53 , 23-Авг-12 (30)
> #tcptraceroute -i eth1:0 -p 333 xxx.xxx.xxx.xxx > через правильный шлюз идёт?Ругается на алиас... Если так #tcptraceroute -p 333 xxx.xxx.xxx.xxx то первый шаг на 192.168.0.1 и далее пошло по хостам, но сдается мне не по tcp это... если делать #tracert -p 333 xxx.xxx.xxx.xxx -T 1 192.168.2.1 (192.168.2.1) 2.770 ms 2.728 ms 2.660 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * ... Вот скриптик: $IPT -t mangle -A OUTPUT -o $IF1 -j CONNMARK --set-mark 1 $IPT -t mangle -A OUTPUT -o $IF2 -j CONNMARK --set-mark 2 $IPT -t mangle -A OUTPUT -p tcp -d $SERVER_IP --dport $SERVER_PORT1 -j CONNMARK --set-mark 1 $IPT -t mangle -A OUTPUT -p tcp -d $SERVER_IP --dport $SERVER_PORT2 -j CONNMARK --set-mark 2 $IPT -t mangle -A OUTPUT -p tcp -d $SERVER_IP --dport $SERVER_PORT3 -j CONNMARK --set-mark 3 $IPT -t mangle -A OUTPUT -j CONNMARK --restore-mark $IPT -t nat -A POSTROUTING -p tcp -d $SERVER_IP --dport $SERVER_PORT1 -j SNAT --to-source 192.168.0.100 # Это работает $IPT -t nat -A POSTROUTING -p tcp -d $SERVER_IP --dport $SERVER_PORT2 -j SNAT --to-source 192.168.1.100 # Это работает $IPT -t nat -A POSTROUTING -p tcp -d $SERVER_IP --dport $SERVER_PORT3 -j SNAT --to-source 192.168.2.100 iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.1.0/24 -m mark ! --mark 3 -j SNAT --to-source 192.168.1.100 iptables -t nat -A POSTROUTING -m mark --mark 3 -j SNAT --to-source 192.168.2.100
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 23:09 , 23-Авг-12 (35)
#tracert -p 333 xxx.xxx.xxx.xxx -T Если несколько раз подряд так делать, то иной раз на [сервер 2] проскакивают пакеты и трасерт показывает конечную точнку (сервер 2) Причем пакеты приходят от PROV1, а должно быть PROV3
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 23:13 , 23-Авг-12 (36)
> но сдается мне не по tcp это...это именно по tcp и поэтому будет отрабатывать --set-mark 3 > $IPT -t nat -A POSTROUTING -p tcp -d $SERVER_IP --dport $SERVER_PORT1 -j SNAT --to-source 192.168.0.100 # Это работает
вот эти пару правил закоментируй > $IPT -t nat -A POSTROUTING -p tcp -d $SERVER_IP --dport $SERVER_PORT2 -j SNAT --to-source 192.168.1.100 # Это работает > $IPT -t nat -A POSTROUTING -p tcp -d $SERVER_IP --dport $SERVER_PORT3 -j SNAT --to-source 192.168.2.100 а это оставь они заменяют пред 2 правила > iptables -t nat -A POSTROUTING -o eth1 ! -d 192.168.1.0/24 -m mark ! --mark 3 -j SNAT --to-source 192.168.1.100 > iptables -t nat -A POSTROUTING -m mark --mark 3 -j SNAT --to-source 192.168.2.100 - Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 23:15 , 23-Авг-12 (37)
да если использовать порт 333 то и интерфейс указывать уже не нужно по идее все должно уйти по 2.х сети получается #tcptraceroute -p 333 xxx.xxx.xxx.xxx
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 23:00 , 23-Авг-12 (31)
Вот еще информация к размышлению# ip rule 0: from all lookup local 32760: from all fwmark 0x3 lookup T3 32761: from all fwmark 0x2 lookup T2 32762: from all fwmark 0x1 lookup T1 32763: from 192.168.2.100 lookup T3 32764: from 192.168.1.100 lookup T2 32765: from 192.168.0.100 lookup T1 32766: from all lookup main 32767: from all lookup default # ip route 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.100 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.100 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.100 default via 192.168.0.1 dev eth0 напрягает, что для 192.168.1.0/24 и 192.168.2.0/24 указан девайс eth1...
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 23:04 , 23-Авг-12 (33)
> напрягает, что для 192.168.1.0/24 и 192.168.2.0/24 указан девайс eth1...все верно на самом деле. физически ты через eth1 отдаешь пакет в сеть.
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 13:49 , 24-Авг-12 (44)
>> напрягает, что для 192.168.1.0/24 и 192.168.2.0/24 указан девайс eth1... > все верно на самом деле. физически ты через eth1 отдаешь пакет в > сеть.Все, разобрался!!! Провода от роутеров были перепутаны!!! Теперь все поперло как надо! ОГРОМНОЕ спасибо за помощь!!!
- Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 23:05 , 23-Авг-12 (34)
>[оверквотинг удален] > 32764: from 192.168.1.100 lookup T2 > 32765: from 192.168.0.100 lookup T1 > 32766: from all lookup main > 32767: from all lookup default > # ip route > 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.100 > 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.100 > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.100 > default via 192.168.0.1 dev eth0 > напрягает, что для 192.168.1.0/24 и 192.168.2.0/24 указан девайс eth1...правильно напрягает. алиас - это только дополнительный IP на физический интерфейс - не более. т.е. сам алиас, как полноценный физический интерфейс операционной системой не рассматривается. PS т.е., что напрягся - это правильно, но так и должно быть: физический интерфейс один, но шлюзы разные.
- Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 23:01 , 23-Авг-12 (32)
>>> а может лучше так >>> iptables -t nat -A POSTROUTING -o eth1:0 ! -d 192.168.2.0/24 -j SNAT >>> --to-source 192.168.2.100 >> С алиасами это не прокатывает... > Походу не только это не прокатывает! > Я тестировал соединение через eth1:0 - через это не работает, а вот > с eth0 и eth1 работает! > Надо думать как eth1:0 (alias) запустить...как вариант - поднять vlan м/ду сервер1 и шлюзами - тогда интерфейсы виланов будут обработаны как физические (включить REORDER_HDR=yes), в отличие от алиасов
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 23:29 , 23-Авг-12 (38)
> как вариант - поднять vlan м/ду сервер1 и шлюзами - тогда интерфейсы > виланов будут обработаны как физические (включить REORDER_HDR=yes), в отличие от алиасов То есть вместо eth1 и eth1:0 сделать vlan1 и vlan2? Типа этого? auto vlan1 iface vlan1 inet static address 192.168.1.100 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 mtu 1500 vlan_raw_device eth1 auto vlan2 iface vlan2 inet static address 192.168.2.100 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 mtu 1500 vlan_raw_device eth1 - Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 23:54 , 23-Авг-12 (39)
>> как вариант - поднять vlan м/ду сервер1 и шлюзами - тогда интерфейсы >> виланов будут обработаны как физические (включить REORDER_HDR=yes), в отличие от алиасов > То есть вместо eth1 и eth1:0 сделать vlan1 и vlan2?именно. только лучше vlan ID отличными от 1 выбрать: vlan1001 и vlan1002 например. >[оверквотинг удален] > mtu 1500 > vlan_raw_device eth1 > auto vlan2 > iface vlan2 inet static > address 192.168.2.100 > netmask 255.255.255.0 > network 192.168.2.0 > broadcast 192.168.2.255 > mtu 1500 > vlan_raw_device eth1 точная настройка в дистрибутиве - это уже Ваша головная боль ) PS если eth0 и eth1 у Вас нормально работали (т.е проблема была только с алиасом), то все нормально должно получиться - я честно скажу всю тему посмотреть не осилил :) PSS REORDER_HDR должен быть включен (ethernet-заголовки будут перемещены в начало пакета и логический vlan-интерфейс будет для системы выглядеть как реальный ETHER). не знаю где в дебиане эта опция при поднятии вилана указывается. посмотреть текущую настройку скорей всего можно будет в cat /proc/net/vlan/ваш_вилан - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 02:22 , 24-Авг-12 (40)
создал vlan1 и vlan2, REORDER_HDR включен.Должны ли ходить пинги на [роутер 1 / 192.168.1.1] и [роутер 2 / 192.168.2.1] и должны ли быть видны сети 192.168.1.0/24 и 192.168.2.0.24 без дополнительных манипуляций # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:e0:4c:68:10:13 inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:4cff:fe68:1013/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:31866 errors:0 dropped:0 overruns:0 frame:0 TX packets:28065 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4615037 (4.4 MiB) TX bytes:2708034 (2.5 MiB) Interrupt:219 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 00:24:1d:83:10:91 inet6 addr: fe80::224:1dff:fe83:1091/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:484 errors:0 dropped:749931704 overruns:0 frame:0 TX packets:237 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:31914 (31.1 KiB) TX bytes:14868 (14.5 KiB) Interrupt:218 Base address:0x6000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:15520 errors:0 dropped:0 overruns:0 frame:0 TX packets:15520 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1404014 (1.3 MiB) TX bytes:1404014 (1.3 MiB) vlan1 Link encap:Ethernet HWaddr 00:24:1d:83:10:91 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::224:1dff:fe83:1091/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:207 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:9126 (8.9 KiB) vlan2 Link encap:Ethernet HWaddr 00:24:1d:83:10:91 inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::224:1dff:fe83:1091/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:936 (936.0 B)
- Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 04:02 , 24-Авг-12 (41)
> создал vlan1 и vlan2, REORDER_HDR включен. > Должны ли ходить пинги на [роутер 1 / 192.168.1.1] и [роутер 2 > / 192.168.2.1] и должны ли быть видны сети 192.168.1.0/24 и 192.168.2.0.24 > без дополнительных манипуляций а сам как думаешь?: eth1=vlan1 eth1:0=vlan2 - пинги до шлюзов ходить должны (если vlan встал) - надо править iptables c обеих сторон на предмет изменения имен интерфейсов (было eth? стало vlan?) - править таблицы роутов под новые имена интерфейсов на сервер1 - вилан только м/ду сервер1 и шлюзом => видимость сетей за шлюзом не меняется (как у Вас было - так и останется) - по умолчанию untagged vlan делается (по идее - ОС-зависимо, но сомневаюсь, что в дебиане по другому будет) PS Еще раз - не пользуй VLAN ID=1 - резервировано стандартом- эмуляция работы простого свича. Юзай vlan1001 и vlan1002 например. PSS было бы вообще классно, если бы показал таблицы маршрутизации и правила iptables на текущий момент. прочитал весь пост полностью, но уже каша получается - нужны текущие данные. - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 10:51 , 24-Авг-12 (42)
> а сам как думаешь?: > eth1=vlan1 > eth1:0=vlan2 Я честно говоря еще не сильно вник в вланы. Так бегло почитал, что влан должна сетевая карта поддерживать. Как узнать, что она поддерживает? - Или это не обязательно, т.к. линух умеет программно работать? > - пинги до шлюзов ходить должны (если vlan встал) влан встал, но по всей видимости не до конца, т.к. с сервера пингуются только сами IP-шники вланов и далее ничего не видно. > - надо править iptables c обеих сторон на предмет изменения имен интерфейсов Вот это не понятно. Что значит с обеих сторон? На сервере и на роутере? Напомню, к [серверу 1] к eth1 подключен [роутер 1], к этому роутеру подключен [роутер 2]... > PS > Еще раз - не пользуй VLAN ID=1 - резервировано стандартом- эмуляция работы > простого свича. Юзай vlan1001 и vlan1002 например. Угу. сделал. > PSS > было бы вообще классно, если бы показал таблицы маршрутизации и правила iptables > на текущий момент. прочитал весь пост полностью, но уже каша получается > - нужны текущие данные. ~# ip route 192.168.2.0/24 dev vlan1002 scope link src 192.168.2.100 192.168.1.0/24 dev vlan1001 scope link src 192.168.1.100 192.168.0.0/24 dev eth0 scope link src 192.168.0.100 default via 192.168.0.1 dev eth0 ~# ip rule 0: from all lookup local 32760: from all fwmark 0x3 lookup T3 32761: from all fwmark 0x2 lookup T2 32762: from all fwmark 0x1 lookup T1 32763: from 192.168.2.100 lookup T3 32764: from 192.168.1.100 lookup T2 32765: from 192.168.0.100 lookup T1 32766: from all lookup main 32767: from all lookup default
iptables пока пустой...
Параметры вланов: # cat /proc/net/vlan/vlan1001 vlan1001 VID: 1001 REORDER_HDR: 1 dev->priv_flags: 1 total frames received 0 total bytes received 0 Broadcast/Multicast Rcvd 0 total frames transmitted 272 total bytes transmitted 11640 total headroom inc 0 total encap on xmit 0 Device: eth1 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESSS priority Mappings: # cat /proc/net/vlan/vlan1002 vlan1002 VID: 1002 REORDER_HDR: 1 dev->priv_flags: 1 total frames received 0 total bytes received 0 Broadcast/Multicast Rcvd 0 total frames transmitted 9 total bytes transmitted 594 total headroom inc 0 total encap on xmit 0 Device: eth1 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESSS priority Mappings: # ifconfig eth0 Link encap:Ethernet HWaddr 00:e0:4c:68:10:13 inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:4cff:fe68:1013/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:35638 errors:0 dropped:0 overruns:0 frame:0 TX packets:32628 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5292387 (5.0 MiB) TX bytes:3128413 (2.9 MiB) Interrupt:219 Base address:0x2000 eth1 Link encap:Ethernet HWaddr 00:24:1d:83:10:91 inet6 addr: fe80::224:1dff:fe83:1091/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2553 errors:0 dropped:1517606601 overruns:0 frame:0 TX packets:328 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:198358 (193.7 KiB) TX bytes:20004 (19.5 KiB) Interrupt:218 Base address:0x6000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:19567 errors:0 dropped:0 overruns:0 frame:0 TX packets:19567 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1779542 (1.6 MiB) TX bytes:1779542 (1.6 MiB) vlan1001 Link encap:Ethernet HWaddr 00:24:1d:83:10:91 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::224:1dff:fe83:1091/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:303 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:12942 (12.6 KiB) vlan1002 Link encap:Ethernet HWaddr 00:24:1d:83:10:91 inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::224:1dff:fe83:1091/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:594 (594.0 B) - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 11:53 , 24-Авг-12 (43)
Сдается мне, что роутеры тоже должны поддерживать vlan?
- Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 23:00 , 24-Авг-12 (49)
> Сдается мне, что роутеры тоже должны поддерживать vlan?угу.
- Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 22:55 , 24-Авг-12 (47)
>> а сам как думаешь?: >> eth1=vlan1 >> eth1:0=vlan2 > Я честно говоря еще не сильно вник в вланы. Так бегло почитал, > что влан должна сетевая карта поддерживать. Как узнать, что она поддерживает? > - Или это не обязательно, т.к. линух умеет программно работать?Линух умеет. Это для винды сетевая карта должна виланы поддерживать. >> - пинги до шлюзов ходить должны (если vlan встал) > влан встал, но по всей видимости не до конца, т.к. с сервера > пингуются только сами IP-шники вланов и далее ничего не видно. >> - надо править iptables c обеих сторон на предмет изменения имен интерфейсов > Вот это не понятно. Что значит с обеих сторон? На сервере и > на роутере? > Напомню, к [серверу 1] к eth1 подключен [роутер 1], к этому роутеру > подключен [роутер 2]... по схеме у Вас все роутеры к сервер1 напрямую подключены.... ну если Вы вилан подняли, то у Вас название интерфейса сменилось как со стороны сервер1, так и со стороны роутера. Влан должен поддерживаться с обеих сторон, чтобы нормально заработал. >[оверквотинг удален] > fe80::224:1dff:fe83:1091/64 Scope:Link > UP BROADCAST > RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 > errors:0 dropped:0 overruns:0 frame:0 > TX packets:9 > errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 > (0.0 B) TX bytes:594 (594.0 B) - Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 13:50 , 24-Авг-12 (45)
Все, разобрался!!! Провода от роутеров были перепутаны!!! Теперь все поперло как надо! ОГРОМНОЕ спасибо за помощь!!!З.Ы. Обошелся без vlan'ов! Но vlan'ы, думаю в будущем пригодятся!
- Одновременно 3 оpenvpn-поединения через разные шлюзы, 1, 15:10 , 24-Авг-12 (46)
> Провода от роутеров были перепутаны!!! Теперь все поперло как надо!повеселились... :D - Одновременно 3 оpenvpn-поединения через разные шлюзы, LSTemp, 22:57 , 24-Авг-12 (48)
> Все, разобрался!!! > Провода от роутеров были перепутаны!!! Теперь все поперло как надо! > ОГРОМНОЕ спасибо за помощь!!! > З.Ы. Обошелся без vlan'ов! Но vlan'ы, думаю в будущем пригодятся!как всегда - засада была там, где не ждали :)
- Одновременно 3 оpenvpn-поединения через разные шлюзы, Павел, 10:31 , 23-Авг-12 (10)
>[оверквотинг удален] > с этим разобрался уже! ;) >> мысли: в output у пакета уже есть src адрес 1.100 меткой ты >> его перенаправляешь в сетку 2.х там он уходит на нужный гейт >> а вот возвращаясь на гейт он(новый пакет того же соединения) обратно >> приводиться к адресу 1.100 и вот этот адрес для гейта загадка >> он не знает куда его послать и отправляет обратно в инет >> по своему дефолтному гейту. выход - попробуй snat. > То есть так? > iptables -t nat -A POSTROUTING -s x.x.x.x --sport 333 -d 192.168.1.100 -j > SNAT --to-source 192.168.2.100 В общем да, в настройках openvpn есть параметр указывающий IP с которого соединяться. В tcpdump видно, что теперь пакет идет от 192.168.2.100 - остальное все тоже самое :(
|