2014-12-18 Internet свързаността на initlab
Thursday, December 18th, 2014(алтернативното заглавие беше “мизерии, които правим като нямаме BGP”)
След доста мъки с onlinedirect в initlab си пуснахме втора връзка, през TBC.bg. За да можем да ползваме и двете, се наложи малко бърникане по setup-а и забавни неща, които съм описал по-долу, разделени на v4 и v6.
Преди всичко може да погледнете схемата на мрежата.
За IPv4 имаше два проблема: трафикът, влизащ от един доставчик трябва да излиза пак през него (нормален policy routing), и трябва по някакъв начин да се избира през кой интерфейс да се излиза (чрез gwping).
Policy routing-а е стандартен, описан е на хиляда места и за това без много подробности, идеята е че се прави routing таблица за всеки доставчик, в нея се вкарват пътя до самия доставчик, default през него и пътищата към локалните вътрешни мрежи, след което се слагат правила, че ip адреса от тоя доставчик изходящия трафик ползва определената таблица. Или, погледнато на cassie:
vasil@cassie:~$ cat /etc/iproute2/rt_tables|grep -v # 255 local 254 main 253 default 0 unspec 2 od 3 tbc vasil@cassie:~$ ip r show table od default via 93.152.128.1 dev eth0.5 93.152.128.0/17 dev eth0.5 scope link 172.31.190.0/24 dev eth0.2 scope link vasil@cassie:~$ ip r show table tbc default via 94.26.100.129 dev eth0.6 94.26.100.128/27 dev eth0.6 scope link 172.31.190.0/24 dev eth0.2 scope link vasil@cassie:~$ ip rule 0: from all lookup local 32764: from 94.26.100.155 iif lo lookup tbc 32765: from 93.152.143.66 iif lo lookup od 32766: from all lookup main 32767: from all lookup default
За изходящия трафик проблемът се решава чрез gwping (който намерих от тук и ми спести час-два писане на нещо такова). Това е прост скрипт, който ping-ва през двете връзки нещо определено (например google) и ако през едната го няма, я маха от routing-а, а иначе държи два default route-а с различна тежест, т.е.
vasil@cassie:~$ ip r
default
nexthop via 93.152.128.1 dev eth0.5 weight 1
nexthop via 94.26.100.129 dev eth0.6 weight 2
...
(докато чертаех схемата, едната връзка падна за малко и като гледам никой не го е усетил)
За IPv6 нещата се оказаха малко по-сложни (но по-изчистени), понеже свързаността ни идва от един тунел до моя машина в telepoint (бяхме на HE.net, ама ни омръзна да ни се отваря немския google). От там имаме една наша /64, която се появява във вътрешната мрежа на лаба. За да мога да прекарам тунела да работи и през двете връзки, просто пуснах два отделни тунела от cassie до tyler през двата доставчика, след което в/у тях пуснах с quagga OSPFv3. В него от страната на cassie announce-вам префикса на локалната мрежа, от другата страна – default route. В общи линии в конфигурацията имам следните неща:
cassie (тук вътрешния ми интерфейс е eth0.2):
interface vk-ipv6-od ipv6 ospf6 priority 0 ! interface vk-ipv6-tbc ipv6 ospf6 priority 0 ! router ospf6 router-id 255.1.1.1 redistribute connected route-map internal interface vk-ipv6-od area 0.0.0.0 interface vk-ipv6-tbc area 0.0.0.0 ! route-map internal permit 10 match interface eth0.2 ! route-map internal deny 20
tyler (тук външния ми интерфейс за IPv6 е eth1, а правя redistribute kernel, понеже default route се вижда като такъв):
interface lab-ipv6-od ipv6 ospf6 priority 0 ! interface lab-ipv6-tbc ipv6 ospf6 priority 0 ! router ospf6 router-id 255.1.1.2 redistribute kernel route-map external redistribute connected route-map external interface lab-ipv6-od area 0.0.0.0 interface lab-ipv6-tbc area 0.0.0.0 ! route-map external permit 10 match interface eth1 ! route-map external deny 20
Учудващо, но работи и даже не успях да си отрежа клона, докато го подкарвах. Има няколко дребни момента, например че OSPFv3 няма auth. на пакетите (или поне го няма реализиран в quagga) и ще му трябва ipsec в един момент, или че може да е по-интересно да вземем от двата доставчика IPv6 адреси, да ги раздаваме на потребителите и те да избират от кой да излизат (което ще е интересно да се тества колко добре работи, ако работи изобщо).