Adott 3 hálózat (később még becsatlakozik 3, majd még 5), amit 1-1 VPN köt össze. Van értelme ilyen felállással létrehozott belsőhálózatra BGP-t használni? Vagy van ennél jobb megoldás?
+1 csak pl Miki-n érdemes volt a routolt forgalmat kisebb prioritásba rakni, mint a gw-gw közöttt célzott forgalmat, mert ha bedugult a VPN, akkor az OSPF csomagok elmaradhadtak és linkszakadást érzékelt aminek hála tényleg meg is szakította a forgalmat. Legalább forgalomütemezés nélkül nekem gyakran szakadt a kapcsolat OSPF-fel.
Ok, te tudod :)
Nálunk a telephelyek közötti forgalom, az, hogy mindent el lehessen érni a másik telephelyről, mintha helyben lennének, lehetőleg ugyanolyan sebességgel :D
Szerintem a kérdés az volt, hogy van-e egy központi hely, ahová minden telephely felcsatol VPN-el, vagy minden telephely rendelkezik VPN kapcsolattal minden másik telephely felé. Azaz minden telephelyen van összes_telephely-1 VPN kapcsolat.
Jah, én úgy értelmeztem, hogy az a kérdés, hogy VPN-en keresztül megy-e ki mindenki netre is.
A harmadik a sorban lesz a VPN szerver új helye és innentől minden telephely erre VPN-ezik be. és mivel még várható további 3 becsatlakozása pár héten belül, és még 5 másik, külföldi is, ezért gondolkodtam el valami értelmes routingon.
Hát nem specifikáltad túl, szóval a válasz: attól függ.
1.: Ha lesz lokális internet-kijárat a site-okon (default route), akkor a specifikusabb subneteket hirdetned kell a VPN-en keresztül.
versus
ha nem lesz, akkor behirdetsz egy default-ot, és jó vagy (ha HUB-and-spoke a topológia, és nem any-to-any).
2.: ha redundáns a site-ok VPN-kapcsolata, akkor kell/érdemes valamilyen dinamikus routing használata. Ez lehet BGP is, kérdés, hogy támogatják-e az eszközök. Vagy OSPF. Mindegyik működhet.
3.: IP-space milyen, lehet summarisation-t csinálni? Ha igen, akkor használj, és old meg a legegyszerűbben, kevés prefix-szel!
4.: mennyi subnetről beszélünk összesen? 20 vagy 10.000? Ha 10.000, akkor ne használj OSPF-et (nyilván függ az eszköztől, meg a designtól, de az OSPF nem erre való; sok prefixre a BGP van kitalálva, és ott van egy csomó lehetőséged a route-manipulációra)!
A lényeg, hogy minél egyszerűbben oldd meg, az segít az üzemeltetésnél később!
1, Minden site saját kapcsolatán netezik. Továbbiakban sem kívánok változtatni ezen, hogy ne a VPN teljen be.
2, Úgy került tervezésre a dolog, hogy ha a VPN szerver kiesik, akkor úgy sincs rá szükség.
3, IP-k helyileg 192.168.x.0/16-ból vannak reszelgetve. van amelyiken 5 /24 is van ebből a tartományból. (ezen sajnos változtatni nem tudok, csak az újakba lesz beleszólásom)
4, Összesen jelenleg 10 van kiosztva, gőzöm sincs mi lesz a továbbiakban. A rengeteg static routetól akarom magam megkímélni valami intelligens megoldással.
Nekem is hasonló működik, bár nem ekkorában. De szerintem nem kell túlbonyolítani.
1., A központi VPN routeren nyilván fel kell venned minden külső telephely subnet-jeire a static route-ot - így legalább egy helyen, központilag, nem a telephelyek felől hirdetve
2., A telephelyi routereken meg beállítasz egy metric 2-es static route-ot a teljes 192.168.0.0/16-ra a VPN központ felé (default route meg - természetesen - marad az internet felé)
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ha openvpn, és mindegyik becsatlakozik egy központi helyre, akkor nem kell egyesével konfigurálgatni a route-okat. Tudod egy helyen: a szerveren. ccd -ben végpont szerint tudsz route-okat push-olni. Aztán ha újabb prefix kerül be a hálózatba, akkor azt is hozzáírod a kliensek ccd-jéhez.
Sőtt, ekkora szintű konfignál már akár érdemes lehet ezt a részét a ccd-nek scriptből generáltatni: leírod egy fájlba, hogy:
cn1: prefix1
cn1: prefix2
cn2: prefix3
cn2: prefix4
cn2: prefix5
it dag dalie
Aztán a scriptbe meg teszel egy ennyi logikát, hogy:
hasznaljuk itten, igy eri el az iroda a datacenter belsohalos gepeket: iroda routeren van vpn datacenterbe, bgpn megkapja hogy az ottani belsohalo vpnbe kell route-olni, a datacenterben meg le van kezelve hogy az irodai halonak szant csomagot az ottani vpn servernek kell kuldeni.
amire figyelni kellett hogy openvpnnek is meg kellett adni az iroda belsohalo tartomany az iroute parameterrel a serveren!
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Én régebben OSPF-et futtattam egy ~10 telephelyből álló VPN hálózaton. Ma már inkább static route-olok ennél jóval nagyobb VPN hálózatokban is, ugyanis előfordult (szolgáltatói hiba miatt) hogy egyes telephelyeken az internet 2-3 percenként szakadt, ami nagyon nem tett jót a VPN hálózatnak.
Hozzászólások
OSPF?
Végülis, miért is ne?...
--
openSUSE 42.2 x86_64
+1 csak pl Miki-n érdemes volt a routolt forgalmat kisebb prioritásba rakni, mint a gw-gw közöttt célzott forgalmat, mert ha bedugult a VPN, akkor az OSPF csomagok elmaradhadtak és linkszakadást érzékelt aminek hála tényleg meg is szakította a forgalmat. Legalább forgalomütemezés nélkül nekem gyakran szakadt a kapcsolat OSPF-fel.
A VPN-en gyakorlatilag semmi extra nem fog menni, csak a telephelyek közti forgalom, pont azért gondolkodtam így meg, hogy ne tudjon eldugulni a VPN.
--
openSUSE 42.2 x86_64
Ok, te tudod :)
Nálunk a telephelyek közötti forgalom, az, hogy mindent el lehessen érni a másik telephelyről, mintha helyben lennének, lehetőleg ugyanolyan sebességgel :D
Az álmoskönyv szerint az OSPF-nek, mint network management protokollnak illik magasabb prión menni. Kell a QoS
+1 OSPF erre epp jo
Eszköze válogatja. Kérdés, hogy milyen eszköz
Supportált tűzfalon úgy is GRE over IPSEC van direkt ezért. Mikrotikről lövésem sincs, hogy hogy húzza fel a tunnelt ipsecben pld.
Ha központi VPN koncentrátor van és a csillag külső tagjai default gw-ként ide küldenek mindent tovább, akkor nincs sok előnye.
Nope. Mindenki a saját kapcsolatát használja mindenre, a vpn-en csak a telephelyek közti kommunikáció megy.
--
openSUSE 42.2 x86_64
vagy Te vagy Én nem értjük amire válaszoltál.
Szerintem a kérdés az volt, hogy van-e egy központi hely, ahová minden telephely felcsatol VPN-el, vagy minden telephely rendelkezik VPN kapcsolattal minden másik telephely felé. Azaz minden telephelyen van összes_telephely-1 VPN kapcsolat.
Jah, én úgy értelmeztem, hogy az a kérdés, hogy VPN-en keresztül megy-e ki mindenki netre is.
A harmadik a sorban lesz a VPN szerver új helye és innentől minden telephely erre VPN-ezik be. és mivel még várható további 3 becsatlakozása pár héten belül, és még 5 másik, külföldi is, ezért gondolkodtam el valami értelmes routingon.
--
openSUSE 42.2 x86_64
őszintén szólva ezt a mondatot sem sikerült maradéktalanul kihámoznom. ha egy skiccet grafikus formában tudnál produkálni...
Ha lenne, biztos lenne.
--
openSUSE 42.2 x86_64
Hát nem specifikáltad túl, szóval a válasz: attól függ.
1.: Ha lesz lokális internet-kijárat a site-okon (default route), akkor a specifikusabb subneteket hirdetned kell a VPN-en keresztül.
versus
ha nem lesz, akkor behirdetsz egy default-ot, és jó vagy (ha HUB-and-spoke a topológia, és nem any-to-any).
2.: ha redundáns a site-ok VPN-kapcsolata, akkor kell/érdemes valamilyen dinamikus routing használata. Ez lehet BGP is, kérdés, hogy támogatják-e az eszközök. Vagy OSPF. Mindegyik működhet.
3.: IP-space milyen, lehet summarisation-t csinálni? Ha igen, akkor használj, és old meg a legegyszerűbben, kevés prefix-szel!
4.: mennyi subnetről beszélünk összesen? 20 vagy 10.000? Ha 10.000, akkor ne használj OSPF-et (nyilván függ az eszköztől, meg a designtól, de az OSPF nem erre való; sok prefixre a BGP van kitalálva, és ott van egy csomó lehetőséged a route-manipulációra)!
A lényeg, hogy minél egyszerűbben oldd meg, az segít az üzemeltetésnél később!
Üdv.
1, Minden site saját kapcsolatán netezik. Továbbiakban sem kívánok változtatni ezen, hogy ne a VPN teljen be.
2, Úgy került tervezésre a dolog, hogy ha a VPN szerver kiesik, akkor úgy sincs rá szükség.
3, IP-k helyileg 192.168.x.0/16-ból vannak reszelgetve. van amelyiken 5 /24 is van ebből a tartományból. (ezen sajnos változtatni nem tudok, csak az újakba lesz beleszólásom)
4, Összesen jelenleg 10 van kiosztva, gőzöm sincs mi lesz a továbbiakban. A rengeteg static routetól akarom magam megkímélni valami intelligens megoldással.
--
openSUSE 42.2 x86_64
Nekem is hasonló működik, bár nem ekkorában. De szerintem nem kell túlbonyolítani.
1., A központi VPN routeren nyilván fel kell venned minden külső telephely subnet-jeire a static route-ot - így legalább egy helyen, központilag, nem a telephelyek felől hirdetve
2., A telephelyi routereken meg beállítasz egy metric 2-es static route-ot a teljes 192.168.0.0/16-ra a VPN központ felé (default route meg - természetesen - marad az internet felé)
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ez így jól hangzik. De ha mégis kell másik subnet, ami nincs benne a /16-ban, máris úgy érzem, hogy szopó lesz.
--
openSUSE 42.2 x86_64
Ha openvpn, és mindegyik becsatlakozik egy központi helyre, akkor nem kell egyesével konfigurálgatni a route-okat. Tudod egy helyen: a szerveren. ccd -ben végpont szerint tudsz route-okat push-olni. Aztán ha újabb prefix kerül be a hálózatba, akkor azt is hozzáírod a kliensek ccd-jéhez.
Sőtt, ekkora szintű konfignál már akár érdemes lehet ezt a részét a ccd-nek scriptből generáltatni: leírod egy fájlba, hogy:
cn1: prefix1
cn1: prefix2
cn2: prefix3
cn2: prefix4
cn2: prefix5
it dag dalie
Aztán a scriptbe meg teszel egy ennyi logikát, hogy:
az alant lévő iroute-os kommentről jutott eszembe, hogy akár így is lehet a split-es utáni sor, helyett kicsit komplexebb logika:
Kötekedés on: az az it dag dalie milyen nyelven íródott?
A google translate nem boldogult vele.
Én csak úgy ismerem, hogy и так дальше :)
hasznaljuk itten, igy eri el az iroda a datacenter belsohalos gepeket: iroda routeren van vpn datacenterbe, bgpn megkapja hogy az ottani belsohalo vpnbe kell route-olni, a datacenterben meg le van kezelve hogy az irodai halonak szant csomagot az ottani vpn servernek kell kuldeni.
amire figyelni kellett hogy openvpnnek is meg kellett adni az iroda belsohalo tartomany az iroute parameterrel a serveren!
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Én régebben OSPF-et futtattam egy ~10 telephelyből álló VPN hálózaton. Ma már inkább static route-olok ennél jóval nagyobb VPN hálózatokban is, ugyanis előfordult (szolgáltatói hiba miatt) hogy egyes telephelyeken az internet 2-3 percenként szakadt, ami nagyon nem tett jót a VPN hálózatnak.