Thank you for reading this post, don't forget to subscribe!
И так есть у меня сервер, он же ОпенВПН сервер в одной организации. и вот упёрлась организация в ширину канала, собственно беда в том, что по этому же каналу ходил SIP трафик, и сильно “лагал” когда ширины канала не хватало
Подключаем ещё один канал от второго провайдера. есть сервер в нём внешний канал (eth1), локальная сеть(eth0), ещё ходит OpenVPN (tun0) для связи с остальными филиалами.
Добавился ещё один внешний провайдер (eth4). для его подключение я сделал так.
Напомню, что linux умеет работать с несколькими таблицами маршрутизации
Тоесть для удобства я могу для каждого своего филиала создать табилцу маршрутизации, и в ней уже удобно управлять маршрутами, потом мне не надо будет листать простыню маршрутов таблицы main
в файл
/etc/iproute2/rt_tables
Добавил 2 таблицы
202 T2
У каждого провайдера будет своя таблица маршрутизация
Т1 – первый провайдер
Т2 – второй
Создал скрипт, что будет заведовать маршрутизацией.
[codesyntax lang="php"]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#!/bin/sh IP1=217.111.111.99 IP2=94.11.111.81 P1=217.111.111.97 P2=94.11.111.82 IF1=eth1 IF2=eth4 # добавим дефаулт гетвей в каждую таблицу. ip route add default via $P1 table T1 ip route add default via $P2 table T2 # Говорим, что по дефолту будем ходить через первого провайдера. ip route add default via $P1 ip rule add from $IP1 table T1 ip rule add from $IP2 table T2 #Перечисляю хосты, что будут ходить через новый интерфейс вот так #Но не забываем их указывать в NAT iptables ip rule add from 192.168.5.107 table T2 ip rule add from 192.168.5.108 table T2 ip rule add from 192.168.5.112 table T2 ip rule add from 192.168.5.199 table T2 #Это так на всякий случай echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects |
[/codesyntax]
Где
IP# это ИП адрес на интерфейсе,
P# шлюз на интерфейсе
после этого сервер отвечает по обоим интерфейсам. также пинги/трацерты с сервера ходят через нужный интерфейс.
теперь мне нужно что нужные мне клиенты ходили через этот интерфейс наружу. в iptables.up.rules у меня есть правила НАТа
-A POSTROUTING -s 10.10.10.6 -o eth4 -j MASQUERADE
-A POSTROUTING -s 192.168.0.0/255.255.0.0 -o eth1 -j MASQUERADE
-A POSTROUTING -s 10.10.0.0/255.255.0.0 -o eth1 -j MASQUERADE
первыми 2мя строками я хочу чтоб вот 192.168.5.102 и 10.10.10.6 НАТились через нового провайдера. rp_filter выключаем вот так в sysctrl
net.ipv4.conf.all.rp_filter = 0
Теперь, надо понимать, что если идёт пакет на 192.168.5.108, то он попадает в таблицу T2 а в ней у нас что? правильно один только дефаултгетвей! а что такое другие подсети филиалов и ОпенВПН мы знать не знаем, поэтому тоже необходимо добавить маршрут в таблицу Т2 для указания где у нас ходятся 10.10.10.0
Всё это кидаем в первый скрипт, а скрипт в автозагрузку. Теперь ещё важный момент, браузер у нас работает прозрачно через squid3 и получается, что весь трафик ходит через один интерфейс, а хттп трафик ходит через другой, не хорошо получается. поэтому читаем дальше:
squid на два внешних интерфейса
что надо сделать для Squid чтоб он использовал оба внешних канала.
Мне нужно было зарулить только определённый набор ИП адресов внутренней сети.
Объявим 2 списка, укажем в каждом диапазон ип адресов, которые куда будем отправлять.
acl provider2 src 16.0.0.0/24
Чуть ниже скажем что нам можно что не можно
http_access allow provider2
И дальше
tcp_outgoing_address 10.1.0.2 provider2
10.1.0.1 10.1.0.2 – это внешние адреса сервера с разными интерфейсами.
Собственно всё