Dotaz: HA VPN koncentratory a dynamicky routing

[iji]

Příloha:

• HA_VPN_koncentrator.png (206471 bytů)

Pratele, chtel bych pozadat o radu zkusenejsi, nebot me znalosti z oblasti siti jsou mizerne.

Soucasny stav:
Mejme firmu, kterou do internetu spojuji dve linky: 10GHz a zalozni ADSL od Kysliku. Firma ma cestaky, kteri se pripojuji pres OpenVPN. Firma ma take pobocky, ktere se do centraly pripojuji opet pres OpenVPN. "Zalozni linka" nyni znamena, ze funguje posta pres dalsi MX zaznam, cestaci a ostatni pobocky jsou mimo hru.


Problem:
Centrala sidli v oblasti, kde zuri (zatim) nezkrotna priroda a tak vypadky 10GHz jsou pomerne caste, obcas to odnese i energeticka sit (at uz ve firme, kde je UPS, ci u providera, kde je snad take neco). Dle manageru si "bussiness zada" vyssi spolehlivosti a bezpecnosti.


Reseni:
Do telehouse ve vetsim meste si umistime server a z nej udelame hlavni VPN koncentrator pro vsechny pobocky, centralu i cestaky (tj. do hvezdy). Protoze telehouse je daleko a nikdo tam nebude v pripade hw chyby ochotny jet okamzite, dame si servery hned dva (jeden novy vcetne NBD supportu, druhy postarsi). Tedy, tento telehouse ma dve budovy, tak si servery rozhodime mezi ne. Kazdy server bude mit vlastni verejnou IP pro management (dostanu jich nekolik, proc je tedy nevyuzit). Jelikoz mam zkusenosti s aplikacnimi clustery, je muj dalsi scenar nasledovny: tyto servery budou cleny clusteru, kde dalsi verejna IP (s patricnym verejnnym DNS zaznamenm) bude vysoce dostupnou sluzbou a na niz se budou pripojovat jak cestaci, tak si na ni budou stavet tunely pobocky. Kdyz primarni node umre, tak HA premigruje publikovanou IP na zalozni node a tunely se holt na ni postavi znova. Stejne tak firemni MX budou smerovany prave na tuto HA IP. Tady myslim nemam chybu.

Jako jsme si dali dva servery do telehouse, budeme mit dva VPN koncentratory v centrale (novy a starsi server), ktere budou pro centralu vychozi branou. Opet se bude jednat o aplikacni cluster. Do kazdeho z nodu povede 10GHz linka a zalozni ADSL (zde ani u jednoho nemam dve adresy, takze sekundarni server bude dostupny pro ssh pouze pres interconnect z primarniho a WANove IP se mu priradi az pri preklopeni).

Mezi aktivnim nodem v telehouse a aktivnim nodem se dvemi konektivitami v centrale budou postavene dva tunely (bud IPSec + GRE nebo OpenVPN) vzdy mezi HA IP v telehouse a jednou na verejnou IP 10GHz linky a druhy na ADSL. Jelikoz mame oba konce tunelu pod kontrolou, k osetreni proti vypadku jedne z linek premyslim o dynamicke routovani (OSPF, BGP je myslim kanon na vrabce). GRE nad IPSecem je prave kvuli nemu (dle meho pruzkumu je pri dynamickem routingu nutne).

Co se tyce LAN strany v centrale, jsou zde na vyber dve reseni, jak osetrit branu pro LANove uzivatele: bud opet jedna vysoce dostupna IP a jeji migrace v ramci clusteru nebo reseni na sitove vrstve pomoci VRRPd ci Keepalived (zminka o nich je zde v jinem vlakne). Osobne se mi vice zamlouva opet aplikacni cluster.

V telehouse bude i Squid, pres ktery budou vsichni (tj. centrala, pobocky i cestari) chodit na internet. Squid jako mission critical zalezitost bude dalsi HA sluzba pro clustering a bude se migrovat spolecne s verejnou IP a tunely (protoze pobezi na nodu, ktery bude mit postavene tunely). Vedle Squida tam bude jeste Postfix (zase clusterova sluzba) pro prijem posty z venku.


Pouzity SW:
CentOS, jako clusterware RedHat cluster suite


Pouzity HW:
Primarni nody budou 1x quadcore a 4 GB RAM, sekundarni pak 1x dualcore a 2 GB RAM



Prosim o nazor, zda tohle reseni ma smysl, je realizovatelne a zejmena, zda se nedrbu levou rukou za pravych uchem a neslo by udelat elegantneji. Pak bych chtel pozadat, zda nekdo nema zkusenosti s provozem OSPF pres IPSec ci OpenVPN.

Na otázku zatím nikdo bohužel neodpověděl.