2014-12-18 Internet свързаността на initlab
by Vasil Kolev(алтернативното заглавие беше “мизерии, които правим като нямаме 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 адреси, да ги раздаваме на потребителите и те да избират от кой да излизат (което ще е интересно да се тества колко добре работи, ако работи изобщо).
December 18th, 2014 at 23:19
Малко встрани от основната тема, но все пак да те питам… И при мен OnlineDirect в последно време се превърнаха от перфектния ми доставчик в редовен кореспондент по телефона, та взеха да ми минават мисли за смяна. Имаш ли добър опит с TBC.bg, че избра(хте) тях, или е експеримент? За сефте ги виждам, но от пръв поглед изглеждат добре. Ако пък в крайна сметка реша да се вържа към тях, може да спомена подходящия човек, че ми е препоръчал услугата, за да се възползва initLab от 10% отстъпка “Доведи приятел” :)
December 18th, 2014 at 23:52
@Neter, от един ден ги имаме, избрахме ги, щото бяха едни от малкото, които можеха да ни пуснат свързаност до лаба. Ще ги видим как се държат (то може да се гледа и на pnag.ludost.net) и ще можем да кажем нещо.
December 19th, 2014 at 01:09
Мерси, ще почакам, пък и трудно се сменя доставчик, който ползваш от създаването му :) Между другото (макар че това си е повече по темата), ако не пропускам нещо от целта на сините кутийки, на схемата на мрежата се съмнявам, че информацията за eth0.5 е вярна.
December 19th, 2014 at 01:16
@Neter, вярно, оправих я.
December 19th, 2014 at 09:33
Въпросът е кога админите на тези доставчици ще им мине мързела и ще почнат да раздават IPv6 адреси.
December 19th, 2014 at 11:10
Всъщност, OnlineDirect известно време раздаваха, макар че се водеше тестово и само при поискване (стига да разбереш някак, че има). Аз се възползвах, услугата беше много стабилна, беше на ръба на официалното пускане, засилих IP-та и към вътрешната ми мрежа и DNS-ите на няколко домейна при мен, но… в един момент някой реши, че е ненужна услуга, и угасна :)
December 19th, 2014 at 21:03
Утре, събота, има ли някъде откъдето мога да си взема/или да отида на място за лайф/рескю сд за линукс-десктоп машина? Намират ли се такива мили хора в София в събота? :)
December 19th, 2014 at 21:17
@v7000, по принцип в initlab (initlab.org) може да има някой, погледни на https://fauna.initlab.org/ и така. Не съм сигурен, ама може да се търкалят някакви такива cd-та или някой да ти напише едно такова нещо я на cd, я на flash-ка (щото на flash-ка е по-лесно).