Propojení poboček

[havrosd]

Zdravím,

mám problém a prosím o radu. Hledal jsem už všude, ale pořád nic
Situace je taková:
Centrála RB433UAH eth1(wan1) internet od RIOMEDIA (DHCP Client),
eth2(lan1) vnitřní síť (192.168.140.0/24),
eth3(wan2) je záložní internet, pří výpadku první konektivity (statická ip),
NAT
0 chain=srcnat action=masquerade out-interface=wan_1
1 chain=srcnat action=masquerade out-interface=wan_2

ROUTE
1 A S 0.0.0.0/0 89.31.10.17 1
0 DS 0.0.0.0/0 188.175.2.1 0

BRIDGE
0 pptp_havirov.hrcentrum.cz bridge_1 0x80 10 none
1 lan_1 bridge_1 0x80 10 none
2 wlan_1 bridge_1 0x80 10 none

Pobočka RB450G eth1(wan1)
eth2-5(lan2-5)
NAT
0 chain=srcnat action=masquerade out-interface=wan_1

BRIDGE
0 lan_1 bridge_1 0x80 10 none
1 lan_2 bridge_1 0x80 10 none
2 lan_3 bridge_1 0x80 10 none
3 lan_4 bridge_1 0x80 10 none

Na centrále běží DHCP server, PPTP server(192.168.98.1). Pobočka se připojuje na centrálu přes PPTP a má IP 192.168.98.2. A nyní potřebuji vyřešit problém, aby klienti na pobočce dostávali IP z centrály. Lépe řečeno, aby celá síť vypadala jako jedná. Aby nikdo nepoznal, že sedí na pobočce nebo v centrále. Na síti je totiž mnoho VOIP zařízení, servery atd.... když je pouze pptp tak nefunguje. Prosím o radu za každou radu budu vděčný. Děkuji

[Maxik]

ppt a p2lt nejsou moc bezpecne tunely a pokud uz v ceste je pouzit pptp nelze je pouzit, me se osvedcil ovpn, nebo ipsec.

[judzin]

Zdravim,

pouzivam na nekolik pobocek ipsec tunely, dhcp server teda extra na kazdem zarizeni, voip telefony se pripojuji na centralu, zadny problem v tom nevidim.

doporucuji vyhledat zde http://gregsowell.com/ ipsec a trochu si s tim pohrat

[Majklik]

Přesně požadované jde udělat tak, aby se to tvářilo celé jako jedna lokální síť, že se ten propoj mezi nima udělá pomocí EoIP tunelu a ten se přes bridge připojí do těch lokálních lan sítí. EoIP je nutno něčím zabezpečit, nejrozumnější je k tomu použít IPsec v transportním režimu. Jde využít i té záložní konektoivity použitím dvou EoIP tunelu, všechny propojené přes bridge do smyšky a aktivovaný RSTP na těch bridge tak, aby defaultně se rozpojil ten záložní, pokud hlavní jede.
Nicméně to znamená, že pokud nepojede ta spojka nebo centrála lehne, tak pobočna bude vyřízená a nic neudělá.
Vylepšit to jde tak, že i když teda bych dělal prasárnu a propojoval to celé jako jeden segment, tak na obou pobočkách mít puštěné DHCP servery a ten na pobočce nastaven tak, aby každý obhospodařovl svoji část. Také je to ideálně nutno udělat tak, aby počítatč jako defualt gateway ven dostal adresu toho lokálního RBčka, jinak ti to do netu půjde přes centrálu všechno (z pobočky prvně tunelem na centrálu a ta to maškarne ven), což je otázka zda ne/chceš (menší to obvykle neřeší a pouští vše nejbližší bránou, větší spíše vše tlačí do centály tunelem a tam to filtruje proxy server, co ne/může jít ven centrálně). Je třeba pak podle toho dávat různou gate podle toho, kde je klient v DHCP odpovědích u tvé konfigurace.

Nicméně v praxi bych si nikdy nedovolil to takto dělat s bridgem, vyjma pár hodně speciálních případů. Šel bych do normálně dvou samsotantých segmentů, každý svoje vlasntí DHCP, pouští data do netu pro danou pobočku atd. A provoz mezi pobočkama routuje ty RBčka skrz tunel. Pokud máš jen jendoduše dvě pobočky a jen jedno VPNko mezi nima nebo víc poboček a VPNko je čístá hvězda z každé pobočky jeden kanál do centrály, tak přímo k tomu je asi nejvhodnější IPsec v tunelovacím režimu, samozřejmě to jde dělat i přes PPTP/L2TP/SSTP/OVPN plus statický routing. Niméně ty první dva/tři trošku mají otazník s bezpečností (spíše už historický), poslední dva zase s propustností a odezvou díky použití TCP spojení. Pokud máš víc poboček a dělá se víc tunelů, smyčky nebo je víc víc tunelů různými cestami. Což teoreticky jsi schopen udělat i ty pomocí té záložní linky, tak je vhodnější použít mezi nima GRE nebo IPIP (ROS4 a starší) tunel, tento obalit IPsec transportem a do tunelů pustit klidně OSPF (nebo pro tak primitivní síť i klidně RIP) pro automatické vytvoření rout kudy co tlačit a i ošetření případného selhání nějakého VPN spoje.

[Maxik]

na co eoip ? Mam dojem ze jak ovpn tak i psec umi jet v rezimu eternet tedy transparentne.

[Majklik]

Ano, OpenVPN to umí, funguje buď na L2 nebo L3 vrstvě, dle toho, zda je to jako tun nebo tap rozhranní (v ROSu tomu, tuším, říkají ip a ethernet režim). Ale tím, že OpenVPN je v ROSu podporováno přes TCP spojení, tak pro vážnjší práci to není, protože nejrůznější kolize plynoucí z TCPinTCP přenosu tomu dávaji na frak při řadě zasekávání, jak se různě potkávají tcp okna a zvláště, pokud se někde paket ztratí. Je to jen nouzovka tam, kde je tak debilní NAT, že nic jiného, než TCP spojení rozumně neprojde. To samé platí pro SSTP tunel (i když ten L2 neumí). Takže pro větší a plynulejší tok je to nepoužitelné.
IPsec na L2 nefunguje, jede až L3. Sice dle toho, jak funguje a obchází routovací tabulku a krade pakety ze zásobníku dle svých asociací to vypadá jak L2, ale v žádném případě není. Sice s hodně násilnění by to šlo dokopat k pseudo bridge, ale z takové konfigurace by pěkně bolela hlava.
Proto návrh na EoIP/IPsec transprt. Ale opět bych do toho nešel a udělal to jako samostanté sítě, jak jsme uváděl předtím.

[hapi]

pokud neni třeba něco extra tak bych volil EoIP jako nejsnadnější tunel. Trochu horší je, že to neni system server-klient což je někdy i určitá výhoda.

[Maxik]

jenze eoip neresi zabezpeceni tj bys to musel resit dalsim ipsec nebo necim co zasifruje provoz ovpn i ipsec udelaji vse v 1

[Majklik]

Ale já od začátku píšu o kombinaci EoIP s IPsec dohromady. Protože samotný IPsec neumí udělat plnohodnotný L2 bridge (jak požaduje původní zadání) a OpenVPN přes TCP se po zkušenostech vyhýbám jak čert kříži (a pomíjím i určité bezpečnostní problémy, ale ty se týkají jen Windows server implementace). Proto OVPN nad TCP jen totální nouzovka a pokud možno jen pro road warrior, kde obvkyle netlačí současně víc různých datových toků tím tunelem. Kdežto u propojení poboček je oprávněné očekávat víc současných toků různými směry. Je na to řada materiálů o problému tunelování TCP in TCP. I v diskusi na openvpn.net je pár threadu na to téma, kde přiznivci TCP spojení po přechodu na UDP zjistili skoro dvounásobnou propustnost šifrované linky u některých přenosů (stalo se zejména těm, kdo má nějaké výpadky na lince, na dokonalé lince s nulovou ztrátou a nezahltitelné se problém TCP in TCP tolik neprojevuje).

Navíc obalení EoIP IPsecem řeší i námítku Hapiho, že EoIP není klient-server, což může někdy ne/vadit. V kombinaci s IPsec tak může být. Pokud mám oba konce na pevných veřejných adresách, tak EoIP obalím IPsec transportem (konce EoIP tunelu jsou přímo ty veřejné IPčka) a oba konce jsou si rovnocenné. Pokud tam mám v cestě NAT nebo jedna strana má plovoucí IPčko, tak to obalím IPsec tunelem a EoIP pověsím na nějaký pár vymyšlených IP adres ze segmentu /30 a protlačení ke skutečným adresám NATem je záležitost toho IPsec tunelu a chová se to jako klient-server architektura (za cenu, že je na paketu větší režie o jedno celé IP záhlaví proti transport variantě, v případě NATu přibude ještě UDP záhlaví).

Ale tak či tak si stojím na tom, že řešení poboček propojením na L2 je spíše totální komplikace a nedělal bych to tak ve většině případů.

[ok2slc]

Já bych se naopak toho EoIP over OVPN zas tolik nebál, takto to provozuji roky a bez problémů. Prvotní je rozjet nějaký ten VPN tunel, pro začátek PPTP a nad něj EoIP a až bude jistota, že EoIP chodí tak jak má, pak bych zkoušel jiný VPN tunel.

[havrosd]

mám teď rozjetý eoip přes pptp teď všechno funguje jak má, ale RIO mě pořád odpojuje, že mám na portu switche více než 5 mac adres tak mi ho vždycky zablokujou. Přes záložní konektivitu to běží bez problému, ale ta zase nemá tak vysokou rychlost. Do budoucna plánuji mít spuštěný script na pobočce, který když nedostane odezvu od pptp serveru při výpadku tak aktivuje dhcp server na pobočce aby lokaní pc dostali IP a jel jim internet. Snažil jsem se rozjet i ovpn, ale vždycky skončím s chybou tls handskake. Nevíte co s tím OVPN a těmi mac adresami ať mě pořád neodpojujou? Nebo máte ještě někdo jinou variantu?

[hapi]

cože? vy chcete rozjíždět tunel v tunelu? to bude MTU pěkně v háji.

[Majklik]

Tunelovat EoIP uvnitř OVPN se mi také jeví trošku přitažené za vlasy, to už raději rovnou to OVPN v Ethernet režimu a prodloužím si tak MTU minimálně o 28 bajtů proti EoIP uvnitř OVPN v IP režimu.

To s tím RIO je nějak divné, to je na linku od RIO píchlý switch a tam vedle sebe několik zařízení? Očekával bych, že linka od RIO jde přímo do RBčka do WAN portu a RBčko vše schovává. Pokud u RIO vidí tolik MAC adres, tak odhaduji na nějakou chybičku v konfiguraci, kdy omylem je něco přes bridge připojeno na wan port.

[havrosd]

RIO SWITCH --> RIO GATEWAY --> WAN (RBčko) nic víc nic miň. Taky se pořád divím. V bridge mám pouze lan1 a wlan1 a v NATu je nastavené masquarde na WAN. Už mi to dělalo před časem když jsem měl router přes iptables na debianu. Tak jsem ho zrušil a koupil RB433UAH. Asi půl roku to všechno běželo bez jakýchkoliv problému a minulý týden s ničeho nic to začalo znova dělat.

[havrosd]

konečně se mi podařilo rozjet ovpn a funguje takže teď už mě jenom zajímá jestli někdo neví proč mám tolik MAC adres na portu switche u RIA?