Блог - Балансиране на множество канали с O-VPN и свързване в ROS
Много често в ИТ средата има заявки за изграждане на съвкупност от няколко комуникационни канала, свързани с факта, че единISP не работи стабилно и/или трябва да получите повече честотна лента. Мечтите и комбинацията от тези два фактора, като получаване на стабилност и едновременно увеличаване на пропускателната способност на канала поради агрегация, остават мечти, но все още може да се направи известно движение в тази посока.
Да предположим, както често се случва, че имате няколко интернет доставчика, свързани у дома и автоматичното прехвърляне на активния канал е конфигурирано, ако един отISP внезапно спре да работи. Схемата е доста жизнеспособна, но има един недостатък - един или повече канали остават неактивни. Какво може да се направи в този случай? Като се има предвид, че нямаме динамично маршрутизиране на наше разположение, остават ни две възможности - статично разпръскване на маршрути по канали или изграждане на агрегация с външен рутер, разположен например на вашата работа или в център за данни. Първата опция незабавно зачерква гъвкавостта на функционалността за резервация, но ще говорим за втората по-подробно.
Лично аз самият съм привърженик на транспортирането в пространството на ядрото в меките рутери, включителноROS, тоест драйверът трябва да е в пространството на ядрото (ko), за да осигури най-добра производителност. Следователно, когато избираме технологии за агрегиране вROS, изглежда, че трябва да вземем предвидEoIP, GRE и т.н. Има обаче случаи, когато стабилността на отделен канал започва да куца, появяват се загуби. Тогава "bonding " или "bridging " не може да проследи адекватно подобно поведение и трябва ръчно да изключите временно дефектния канал, което е изключително неудобно. Как може да се преодолее този недостатък? Задължително за влизанеизлишна проверка на здравето на тунела. И тукOpenVPN идва на помощ, като щедро проверява неговата жизнеспособност с пакети за поддържане на активността.
Страхотно! Да започваме.
/ip адрес добавете адрес=1.1.1.2/24 интерфейс=ether1/ip адрес добавете адрес=1.1.1.3/24 интерфейс=ether1/ip маршрут добавете dst-address=0.0.0.0/0 шлюз=1.1.1.1
/ip route add dst-address=1.1.1.2/32 gateway=1.1.2.1/ip route add dst-address=1.1.1.3/32 gateway=1.1.3.1
В настройкитеR1 имаме два шлюза1.1.2.1 и1.1.3.1. Нека те бъдат шлюзове на доставчика заR1. Така посочихме, че до1.1.1.2 минаваме през1.1.2.1, и до1.1.1.3 минаваме през1.1.3.1.
След това нека преминем към настройките на основните тунелиOpenVPN.
/ppp profile add name=light-ovpn only-one=yes use-compression=no use-encryption=no use-mpls=no/ppp secret add local-address=1.1.4.1 name=ovpn-over-isp1 password=YOURPASS profile=light-ovpn remote-address=1.1.4.2 service=ovpn/ppp secret add local-address =1.1.4.3 name=ovpn-over-isp2 password=YOURPASS profile=light-ovpn remote-address=1.1.4.4 service=ovpn/interface ovpn-server server set auth="" certificate=none cipher="" default-profile=light-ovpn enabled=yes keepalive-timeout=360 mode=ethernet port=8085 require-client -certificate=no/interface ovpn-server add name=ovpn-over-isp1 user=ovpn-over-isp1/interface ovpn-server add name=ovpn-over-isp2 user=ovpn-over-isp2
Нека започнем да конфигурираме R1, трябва да дублираме всички тунели в раздела на клиентаOpenVPN.
/ppp profile add name=light-ovpn only-one=yes use-compression=no use-encryption=no use-mpls=no/interface ovpn-client add add-default-route=no auth=none certificate=none cipher=none connect-to=1.1.1.2 max-mtu=1500 mode=ethernet name=ovpn-over-isp1 password=YOURPASS port=8085 profile=light-ovpn user=ovpn-over-isp1/inter face ovpn-client add add-default-route=no auth=none certificate=none cipher=none connect-to=1.1.1.3 max-mtu=1500 mode=ethernet name=ovpn-over-isp2 password=YOURPASS port=8085 profile=light-ovpn user=ovpn-over-isp2
Страхотен! Тунелите са готови, статусът им може да се проследи в съответните секции, време е за агрегиране. Създавайки тази схема у дома, дълго време мислех - имам ли нужда от агрегиране под формата на еквивалентно натоварване на всички оператори или ще ми е достатъчно да включа необходимите канали в моста и съответно да разредя теглата иpath-cost. Въпреки това, след като тествах пълноценно агрегиране наOpenVPN, бях доволен от резултата и предлагам своята схема в тази статия.
/interface bonding add link-monitoring=none mode=balance-rr mtu=1500 name=BOND-OVPN primary=none slaves=ovpn-over-isp1,ovpn-over-isp2
В този пример създадохме интерфейс, който комбинира няколко каналаovpn-over-isp1 иovpn-over-isp2 според принципаRoundRobin (balance-rr). Това означава, че всеки пакет, пристигащ на интерфейсаBOND-OVPN ще отиде първо къмovpn-over-isp1 и след това къмovpn-over-isp2, зареждайки и двата канала равномерно.
Страхотно! Ние сме почти на целта. Остана много малко.
Не забравяйте, че на каналитеISP1 иISP2 могат да се наблюдават различни закъснения при преминаването на пакети и следователно могат да настъпят неблагоприятни времена за протоколи, които са чувствителни към пренареждане.
Можем да завършим нашия процес на изграждане на тунел, като създадемедин допълнителен тунел в режимTCP, преминаващ презBOND-OVPN.
/ip адрес добави адрес=1.1.5.2/30 интерфейс=BOND-OVPN
/ip адрес добави адрес=1.1.5.1/30 интерфейс=BOND-OVPN
/ppp secret add local-address=1.1.6.1 name=ovpn-mainchannel password=YOURPASS profile=light-ovpn remote-address=1.1.6.2 service=ovpn/interface ovpn-server add name=ovpn-mainchannel user=ovpn-mainchannel
/interface ovpn-client add add-default-route=no auth=none certificate=none cipher=none connect-to=1.1.5.1 max-mtu=1500 mode=ethernet name=ovpn-mainchannel password=YOURPASS port=8085 profile=light-ovpn user=ovpn-mainchannel
Трябва да се отбележи, че ако планирате да предавате мултисервизни услуги от DC, напримерmulticast иIP, тогаваovpn-mainchannel може да бъде отделен чрезVLAN, например:
/interface vlan add interface=ovpn-mainchannel name=MainChannel-Internet vlan- >/interface vlan add interface=ovpn-mainchannel name=MainChannel-IPTV vlan- >
И така получихме работеща версия на агрегиране и малко отказоустойчивост, остава да подкараме всички услуги. Тук ще се опитам да не обръщам много внимание на детайлите, т.к. те трябва да са ясни, ако ще създавате такива схеми.
/ip адрес добави адрес=1.1.7.1/30 интерфейс=MainChannel-Internet/ip адрес добави адрес=1.1.8.1/30 интерфейс=MainChannel-IPTV/ip route добави dst-address=1.1.1.4/32 gateway=1.1.7.2
В този случай водим доR1 IP, предоставен ни отDC -1.1.1.4.
/ip адрес добавете адрес=1.1.7.2/30 интерфейс=MainChannel-Internet /ip адрес добавете адрес=1.1.8.2/30 интерфейс=MainChannel-IPTV /интерфейс br >/ipадрес добавяне на адрес=1.1.1.4/32 интерфейс=Обратно обратно /ip маршрут добавяне на dst-адрес=0.0.0.0/0 шлюз=1.1.7.1 pref-src=1.1.1.4 /ip защитна стена nat добавяне на действие=src-nat chain=srcnat out-interface=Обратно src-адрес=192.168.0.0/16 към реклама рокли= 1.1.1.4
Тук "приземяваме" полученияIP върху създаденияLoopback от моста и изпълнявамеNAT на посоченияIP.
Забележка : в правилото/ip firewall nat add action=src-nat chain=srcnat out-interface=Loopback src-address=192.168.0.0/16 to-addresses=1.1.1.4 стойносттаout-interface може да е различна в зависимост от версията наROS (iptables). Това може да е Loopback на по-стари версии на ROS (5.x) и може да еMainChannel-Internet на по-нови версии наROS (6.x).
Е, ако говорим заIPTV.
/routing igmp-proxy interface add alternative-subnets=0.0.0.0/0 interface=MainChannel-IPTV upstream=yes /routing igmp-proxy interface add interface=ether2
/routing igmp-proxy интерфейс add alternative-subnets=0.0.0.0/0 interface=ether2 upstream=yes /routing igmp-proxy интерфейс add interface=MainChannel-IPTV
Заключение
Разбира се, създадената схема по никакъв начин не претендира да бъдеEnterprise решение, но в домашни условия, когато прекъсванията са недопустими, тя се оказа отлична. Също така, дълго време се опитвах да реша проблема с излишъка, използвайкиEoIP тунели, комбинирани вBridge, но това не даде необходимата стабилност. Имаше моменти, в които в мрежата на някой от операторите имаше "падове" от 10-15%, които побъркваха моста. И тогава единственото решение изглеждашеOpenVPN. Струва си обаче да се отбележи, че към момента на писане на това,EoIP вече имашеkeep-alive, но толкова съм свикнал с маркираната схема поради използването наTCP и възможността за смяна на работещия порт, че е малко вероятно да превключа обратно къмEoIP. Освен това, в моя случай, на старияIntel Atom, успях да получа около210 Mbit/s симплексен трафик, което според мен е добро постижение.
СъстезателАлександър
Всеки, който чете статии, участващи в конкурса, се моли да ги оцени.