Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Pavouk106 22. 07. 2013, 16:12:14
-
Ahoj,
příští rok mě čeká stěhování a s ním spojené "rozdělení" dosavadní PC sítě na dvě. Na původním místě po mě zůstane Mikrotik s veřejnou IP a serverem (za sebou, maškaráda ale i IPv6). Tady je teď dobrá konektivita, DHCP server, DNSserver a podobný blbosti.
Na novém místě vznikne něco podobného, tedy Mikrotik (nejspíš bez VIP) a za ním server (maškaráda, pravděpodobně bez IPv6).
Fungování si představuju tak, že mezi Mikrotikama by byl bridge, obě sítě by měly stejnej rozsah IP podsítě (získávaly IP adresy z toho nynějšího DHCP serveru), byly by mezi nima teda přímý cesty, ale pro výstup do internetu by každá podsíť jela přes toho svýho Mikrotika.
Je to scifi? Věřím, že ne. VPN bych nerad, na co mít tři podsítě (jednu na starym místě, jednu na novym a VPN jako třetí)?
Problém je jště s IPv6. Teď mám tunel od HE na původní místo. Jak zařídit přidělení adres na novym místě a směrování paketů do internetu na novym msítě, když nemá vlastní IPv6 tunel do HE? Asi těžko, co?
Rád bych tu tak nahlas pouvažoval nad řešením, dostal se do problematiky. Předně jde tedy o to, jestli Mikrotik umí s jiným Mikrotikem udělat podsíť/bridge.
Mám na čem testovat, výše napsaná konfigurace je mi k dispozici: dva mikrotiky - z toho jeden s VIP - a běžící server s DHCP serverem a DNS serverem.
Beru jakýkoliv přípomínky, nápady, atd. ;-)
-
VPN bych nerad
Ano... (http://blogs.technet.com/blogfiles/andrew/WindowsLiveWriter/ReinventingtheWheel_AED6/wheel_2.jpg) ::)
-
Já o tom řešení (VPN) samozřejmě vím a nasadit ho by neměl být problém. Rád bych to ale vyřešil o stupeň výš. Tedy na úrovni těch Mikrotiků, ideálně pomocí nějaké jejich fíčury, o které nemám páru (pokud existuje, že?).
Teoreticky tedy zapnu na novém místě NTB. Požadavek na IP adresu pro DHCP pojede tedy:
NTB -> wlan na MK1
wlan na MK1 -> "bridge" na MK1 (bridge mezi dvěma MK)
(internet, resp. přenos mezi dvěma MK)
"bridge" na MK2 -> ether na MK2
ether na MK2 -> DHCP server
Je to pochopitelný? Jde mi o přemostění internetu mezi dvěma Mikrotiky, ne o vytvoření virtuální sítě jako takový. Nechci nad dvěma "fyzickýma" podsítěma postavit jednu virtuální, chtěl bych mít jednu "fyzickou" s virtuálním mostem mezi dvěma Mikrotikama.
Nebo máš na mysli VPN jen mezi MK a zroutovat to? Ale jak? To je právě to, co nevím... Potřebuju říct, ve který garáži najdu kolo a jak se k ní dostanu, nechci ho znova vymejšlet.
-
Nebo máš na mysli VPN jen mezi MK a zroutovat to? Ale jak? To je právě to, co nevím... Potřebuju říct, ve který garáži najdu kolo a jak se k ní dostanu, nechci ho znova vymejšlet.
Nevím, jestli je dobrej nápad mít ty dvě fyzicky oddělené sítě na stejném rozsahu. Jaký pro to máš důvod?
Já bych vůbec nic nevymýšlel, první síť bych dal jako 192.168.1.x, VPN mezi Mikrotiky jako 192.168.2.x a druhou fyzickou síť jako 192.168.3.x. K tomu, aby ti pakety chodily tak jak chceš*, potřebuješ pak jenom na každém z Mikrotiků nastavit jednu routu (aby věděl, že do té druhé sítě se dostane přes tu VPN síť) a všechno ostatní bude fungovat out of the box. Bude to standardní, bezproblémový a bezporuchový.
Měl by sis imho dobře rozmyslet, jakej důvod máš k tomu, vymýšlet nějaký jiný skopičiny.
* z jedné sítě do druhé přes tunel a do internetu vždycky přes tu příslušnou "lokální" bránu, pochopil jsem správně?
-
Je to scifi? Věřím, že ne. VPN bych nerad, na co mít tři podsítě (jednu na starym místě, jednu na novym a VPN jako třetí)?
VPN jde dát do bridge ;) (http://wiki.mikrotik.com/wiki/OpenVPN#Bridge_mode)
pro výstup do internetu by každá podsíť jela přes toho svýho Mikrotika.
Na to bude potřeba buď ošklivý hack ve firewallu, kdy se traffic na druhý router ukradne (v Linuxu to jde udělat, netuším, jestli to půjde vyklikat na Mikrotiku), nebo dva DHCP servery a rozdělený pool. Potom je ale úplně nejvhodnější už mít dvě oddělené, vzájemně proroutované sítě a nešaškovat s bridgem.
Problém je jště s IPv6. Teď mám tunel od HE na původní místo. Jak zařídit přidělení adres na novym místě a směrování paketů do internetu na novym msítě, když nemá vlastní IPv6 tunel do HE? Asi těžko, co?
Přesně tak :)
-
Nu, znám nejednu i hodně velkou síť (desítky poboček po několika kontinentech), které jsou řešeny jako jedna L2 doména - každý svého průseru strůjcem...
Co se požadavku týče, tak pomocí Mikrotiku, až na to IPv6 bez problémů.
Jak bylo zmíněno, jde udělat bridge přes VPN tunel. Pokud by obě strany měly veřejnou IP, tak je na to speciální typ tunelu EoIP (ethernet over IP), ten nemá bezpečnostní funkce, takže obalit pomocí IPsec transportu. Pokud je jedna strana neveřejná, je možno OpenVPN v ethernet módu nebo SSTP se zapnutým BCP. Jde použít i L2TP nebo PPTP v BCP módu (bridge control protocol). Nevýhoda OpenVPN a SSTP je, že to je jen TCP, což na větších rychlostech občas trochu vadí, nevýhodou L2TP a PPTP je, že je to pasivním odposlechem zlomitelné v Mikrotik implementaci. Slabší verze RBček zase v IPsecu nedají víc jak cca 10 Mbps (RB4xx/7xx/9xx).
Problém, aby IPv4 šlo ven přes lokální MKčko se řeší puštením DHCP na každém MKčku, kdy jedno bude dávat IP třeba 192.168.1.1-126 a druhé 192.168.1.128-253. MKčko má pak 192.168.1.127/24 a druhé 192.168.1.254/24 druhé. Na spojovací tunel se dá L2 firewall pravidlo blokující DHCP, takže v každé půlce jede DHCP nezávisle, á dává i příslušně lokální bránu ven.
S IPv6 tohle nejde, tam bych nechal to jedno s HE tunelem a přes něj vše půjde ven (respektive jde to řešit také, ale je to hodně nehezká a hnusná konfigurace a obě MKčka by musela mít svoji veřejnou IP).
-
Super, už se to tu vede směrem, kterým jsem si představoval :-)
Takže shrnuto a podtrženo edna možnost je zroutovat obě sítě dohromady a hnát je přes VPN(bridge), ve kterém budou pouze oba MK.
Druhá možnost je jak popisoval M. - to ještě musím projít a počíst si, abych to pochopil komplet. Rychlosti nepřesáhnou 10Mbit obousměrně tak jako tak, je to domácí použití, ne firemní sféra, rychlosti ISP tak vysoký nebudou (na jedný straně je up 8Mbit, na druhý nevim, jakej bude) ;-) Jde víceméně o to dokázat to tak udělat a mít pak pohodlí a stále jednu síť.
IPv6 jsem jen zmínil, neočekávám od toho funkčnost. Buď to necham ject přes toho jednoho MK, nebo v novym místě nebude IPv6. Možná budu mít i veřejnou i IPv6, ale to zjistím až za dlouho...
Díky za nápady, cokoliv dalšího i další diskuzi vítám :-)
-
edna možnost je zroutovat obě sítě dohromady a hnát je přes VPN(bridge)
Buď jedno, nebo druhé :) Buď routovat (=> oddělené subnety), nebo bridgovat (jeden subnet, fyzicky přebridgováno přes VPN).
ve kterém budou pouze oba MK.
Ajó! Já už to chápu, ty ses děsil té VPN jako že každý počítač by se do VPN hlásil zvlášť? To rozhodně ne. VPN použiješ jenom jako kanál mezi těmi dvěma sítěmi - jeden Mk bude server, druhý klient a počítače v síti o tom nebudou vůbec nic vědět.
-
Já o tom řešení (VPN) samozřejmě vím a nasadit ho by neměl být problém. Rád bych to ale vyřešil o stupeň výš. Tedy na úrovni těch Mikrotiků, ideálně pomocí nějaké jejich fíčury, o které nemám páru (pokud existuje, že?).
Teoreticky tedy zapnu na novém místě NTB. Požadavek na IP adresu pro DHCP pojede tedy:
NTB -> wlan na MK1
wlan na MK1 -> "bridge" na MK1 (bridge mezi dvěma MK)
(internet, resp. přenos mezi dvěma MK)
"bridge" na MK2 -> ether na MK2
ether na MK2 -> DHCP server
Je to pochopitelný? Jde mi o přemostění internetu mezi dvěma Mikrotiky, ne o vytvoření virtuální sítě jako takový. Nechci nad dvěma "fyzickýma" podsítěma postavit jednu virtuální, chtěl bych mít jednu "fyzickou" s virtuálním mostem mezi dvěma Mikrotikama.
Nebo máš na mysli VPN jen mezi MK a zroutovat to? Ale jak? To je právě to, co nevím... Potřebuju říct, ve který garáži najdu kolo a jak se k ní dostanu, nechci ho znova vymejšlet.
Teoreticky ... prakticky resis totalni kravinu. Uvedom si, ze konektivita na jedny nebo druhy strane neni stabilni, (predpokladam z tvyho popisu, ze jde o geograficky vzdalene lokality) a to uz je prvni problem ... neco se podela, a ty nedostanesj od DHCP ani IPcka = nebude ti fungovat NIC, a to presto, ze tvuj konec dratu funguje. Dale, bridge je zcela nesmyslny reseni i z dalsich duvodu - sireni broadcast domeny = zblazni se ti cokoli na jedny strane spoje kdekoli v siti a na 100% to zatizi celej spoj.
Na to bude potřeba buď ošklivý hack ve firewallu, kdy se traffic na druhý router ukradne (v Linuxu to jde udělat, netuším, jestli to půjde vyklikat na Mikrotiku), nebo dva DHCP servery a rozdělený pool. Potom je ale úplně nejvhodnější už mít dvě oddělené, vzájemně proroutované sítě a nešaškovat s bridgem.
Ani ne, staci jeden DHCP a pridelit routu per klient, ale je to samo kravovina.
Problém je jště s IPv6. Teď mám tunel od HE na původní místo. Jak zařídit přidělení adres na novym místě a směrování paketů do internetu na novym msítě, když nemá vlastní IPv6 tunel do HE? Asi těžko, co?
Přesně tak :)
Zridit si dalsi tunel. Nebo dokopat ISP k poskytnuti IPv6. Pripadne zprovoznit teredo nebo jiny prechodovy mechanismus. Jinak samo, Ipv6 bude pres VPNku fungovat taky, jen to bude znamenat, ze se ti traffic bude tlacit pres stavajici pripojku tam a pak zase ven, coz asi neni uplne idealni.
Jinak VPNka s klasickym routovanim funguje naprosto vpohode, dokonce ten spoj nemusi mit vlastni IPcka. Navic mas daleko vetsi moznosti jak nastavovat, co ma a co nema chodit pres.
Uvedom si, bridge je nejhorsi mozna varianta a pouziva se to jen v pripade, ze to jinak resit nejde. Osobne mam nektery casti site odroutovany (za pomoci vlanu) i na LANce. A to nejen kvuli bezpecnosti ( i kdyz to bylo v tomto pripade prioritni).
-
Mu to nezhazujte pořád. Je to používané řešení. Třeba má aplikaci, kde požaduje jednu L2 broadcast doménu a routing to neřeší nebo složitě... Když se chce pocvičit, ať si hraje, lepší jak kdyby kuchal nožem důchodce v průchodu po večerech...
Těch sítí, co přešlo z routovaného provozu na bridgovaný je řada v mém okolí, právě proto, že je routing, proxy arp, routing multicvastingu atd neuspokojil a chtějí mít to vše jako jedno. Někteří si kvůli tomu i zřizovali MPLS tunel na druhý konec světa přes sítě operátorů. :-)
Právě k ochraně rizika, že tunel nejede je použití DHCP serverů na obou stranách. Navíc v případě Mikrotiku to použít musí, protože DHCP server v Mikrotiku neumí poslat různým klientům rozdílnou default bránu na jednom segmentu. Přidělit napevno IP ano, ale ostatní parametry jsou společné pro celý segment. Proto na každé straně jeden DHCP, který přidělí s ohledme na lokální stranu a blokování DHCP v tunelu.
Pokud dostane na obě strany IPv6 veřejný blok (aŤ nativně nebo tunelem), pak je s jednou L2 doménou nahraný. Dá se řešit pomocí proxy ARP (čili z pohledu IPv6 je každá síť samostatná, z pohledu IPv4 je to jedna síť dohromady).
Ten šířený broadcast bordel se dá omezit, je na to několik metodik.Viděl jsme i šílenost s použitím OpenFlow, pro které má Mikrotik už podporu (v beta stádiu), ale vyžaduje to externí controller.
-
Oba MK půjdou do bridge, jakým způsobem, to si ještě musím načíst. VPN se jeví jako nejjednodušší, pokud je ale systematičtější možnost (= něco víc speciálního pro tuhle konkrétní funkci), zkusím nejdřív tu. Jisté ale je, že budou v bridge.
DHCP budou tak jako tak na obou stranách, ať už to bude dál fungovat jakkoliv. Buď bude jedno hlavní a druhé záložní (kdyby se rozbil bridge), nebo budou obě hlavní pro svou část sítě. DHCP může klidně běžet na zmíněném serveru za MK (na obou stranách bude server za MK, v podsíti), nemusí jím být přímo MK.
Mirek: Jo, toho jsem se bál, ale už jsem to pochopil správně :-)
M.: Nemám aplikaci, je to vysloveně hobby, prostě jsem si udělal představu a chtěl bych jí docílit ;-) Ale úplně neužitečný to taky nebude, mám doménu a chtěl bych přes doménový jména přistupovat k jednotlivým zařízením v síti. Zároveň zvenčí přes doménový jméno přistupovat k jednotlivým PC z internetu (port forwarding, zdaleka to neplat pro všechny PC v síti, spíš jen pro ty servery a MK).
Takže vyhlídka je taková, že bude jedna společná IPv4 podsíť (IP adresama) a bude nějakým způsobem zbridgovaná na úrovni MK. DHCP budou na každý straně jedno a buď budou hlavní/záložní se stejným rozsahem nebo hlavní/hlavní s jiným rozsahem.
IPv6 necháme stranou, nový místo bude bez IPv6, není to pro mě priorita.
Díky za nakopnutí, tak nějak jsem s to právě představoval ;-)
-
DHCP budou tak jako tak na obou stranách, ať už to bude dál fungovat jakkoliv. Buď bude jedno hlavní a druhé záložní (kdyby se rozbil bridge), nebo budou obě hlavní pro svou část sítě. DHCP může klidně běžet na zmíněném serveru za MK (na obou stranách bude server za MK, v podsíti), nemusí jím být přímo MK.
Tohle je první věc, kterou si tím bridgem zbytečně komplikuješ: ty DHCP servery by se ti hádaly, protože tam prostě "dvě sítě" mít nebudeš, bude to síť jedna -> budeš muset zabezpečit, aby každý DHCP server fakt ovládal jenom tu svoji síť. Asi nejspíš firewallováním. A budeš složitě řešit pravidla, abys zachytil jenom ty broadcasty, který zachytit chceš. Tak do týdne tě tady čekám s dotazem na tohle ;)
...a na takový věci budeš narážet pořád. Bridgování je prostě opruz a pokud k němu nemáš fakt pádnej důvod, tak bys ho používat neměl.
Ale úplně neužitečný to taky nebude, mám doménu a chtěl bych přes doménový jména přistupovat k jednotlivým zařízením v síti.
Zároveň zvenčí přes doménový jméno přistupovat k jednotlivým PC z internetu (port forwarding, zdaleka to neplat pro všechny PC v síti, spíš jen pro ty servery a MK).
K tomu ale vůbec nepotřebuješ bridgování.
Takže vyhlídka je taková, že bude jedna společná IPv4 podsíť (IP adresama) a bude nějakým způsobem zbridgovaná na úrovni MK.
Mám pocit, že ses na to bridgování úplně zbytečně upnul a nevíš, na jaký vidle si nabíháš... No, každý svého štěstí strůjcem :)
-
Add to šílené filtrování pronikání dhcp do druhé půlky. Myslím že v případě ROSu (Mikrotik), že plně stači toto:
/interface bridge filter add action=drop chain=forward dst-port=67-68 ip-protocol=udp mac-protocol=ip out-interface=eoip1
Dát na obě strany, eoip1 nahradit jménem iface tvořícícho tunel...
A to hádání, zda L2 nebo L3, ať si nastaví oboje, provozuje a pak vyhodnotí...
Dokážu najít několik adminů, co budou obhajovat a chrochtat blahem, jak se jim vše zjednodušilo uděláním jedné L2 domény i přes několik kontinentů a i road warriory připojují mobilně na L2 úrovni.
Jinak souhlas, pro přístup na druhou stanu dle jména nemusí být síť L2, funguje L3 s funkčním DNS (případně WINS pro extra vykopávky).
-
Mirek: Já si spíš mysím, že nejsem schopnej to popsat tak, aby to bylo správně pochopeno. Zkrátka chci mít jednu podsíť na dvou geograficky oddělených místech. Dosáhnout toho chci tak, že přemostim internet pomocí koncových zařízení, tedy MK. Slovo "přemostim" neber doslovně, chci tím říct, že spojení MK1 - internet - MK2 by mělo fungovat "neviditelně", prostě na jednom místě zadam adresu franta.domena.tld a jsem o 30km jinde na vnitřní IP ze stejnýho rozsahu (řekněme 192.168.1.0/24). To je myšlenka. Jde mi o technický řešení a jeho konkrétní provedení.
Jako možnost se jeví využití něčeho (pro mě) ne běžnýho, jak zmínil M. nebo použití VPN mezi oběma MK na přemostění (opět neber doslovně).
DHCP a obou stranách je celkem logický - vypadne spojení MK - MK a jsme víme kde ;-) Zase tu jde ale o provedení. Zatím to neřeším, v blízký době nejspíš nebudu, ale testovat už to můžu. Mám jeden MK s VIP a se serverem za zády a druhý MK s ne-VIP bez serveru. Takže na úrovni MK - MK můžu experimentovat s přemostěním (zase neber doslovně).
Vypadá to, že jsem se upnul na bridge, ale já to tak pouze nazývám, protože to slovo, tedy most, celkem dobře popisuje myšlenku, ale nemyslím tím konkrétní technický řešení... ;-)
M.: Budeme tedy dál pracovat s tím, že jde o to, abych měl jednu společnou podsíť (192.168.1.0/24) na obou místech a cílem je donutit dva MK (jako koncové zařízení na obou místech) spojit se spolu a zařídit fungování takový společný podsítě, jako kdyby to byla klasická LAN. Rozdíl je pouze v tom, že z každý části podsítě se jde do internetu jinudy.
-
OK, pokud je jedna strana neveřejná, tak není moc co vybírat. Klikáš dle postupu pro blbé:
http://wiki.mikrotik.com/wiki/Manual:BCP_bridging_%28PPP_tunnel_bridging%29
Je jedon, zda to bude L2TP, PPTP, SSTP. První dva jsou pasivním odposlechem zlomitelné u Mikrotik implenetace, pokud bezpečností faktor by byl důležitý.
-
Slovo "přemostim" neber doslovně, chci tím říct, že spojení MK1 - internet - MK2 by mělo fungovat "neviditelně", prostě na jednom místě zadam adresu franta.domena.tld a jsem o 30km jinde na vnitřní IP ze stejnýho rozsahu (řekněme 192.168.1.0/24). To je myšlenka. Jde mi o technický řešení a jeho konkrétní provedení.
No a kdybys zadal adresu franta.domena.tld a byl o 30km jinde na vnitřní IP z jinýho rozsahu (řekněme 192.168.2.0/24), tak by to vadilo čemu?
Stejný rozsahy typicky nepotřebuješ. Už i ta přiblblá samba se dá provozovat napříč subnety. Popravdě řečeno mě nenapadá ani jedna "normální" věc, která by se přes dva subnety provozovat nedala.
-
Add to šílené filtrování pronikání dhcp do druhé půlky. Myslím že v případě ROSu (Mikrotik), že plně stači toto:
/interface bridge filter add action=drop chain=forward dst-port=67-68 ip-protocol=udp mac-protocol=ip out-interface=eoip1
Dát na obě strany, eoip1 nahradit jménem iface tvořícícho tunel...
Jo, to by asi stačilo, ale je to problém navíc, se kterým myslím Pavouk nepočítal, takže kdybych ho na to neupozornil, nejspíš by si to uvědomil až za provozu, až by to haprovalo. A to se mu při bridgování stane ještě x-krát. Bridgování je prostě pro lidi, kteří dobře ví, co a proč dělají. Pro všechny ostatní je lepší routování.
-
Mirek: Já si spíš mysím, že nejsem schopnej to popsat tak, aby to bylo správně pochopeno. Zkrátka chci mít jednu podsíť na dvou geograficky oddělených místech. Dosáhnout toho chci tak, že přemostim internet pomocí koncových zařízení, tedy MK. Slovo "přemostim" neber doslovně, chci tím říct, že spojení MK1 - internet - MK2 by mělo fungovat "neviditelně", prostě na jednom místě zadam adresu franta.domena.tld a jsem o 30km jinde na vnitřní IP ze stejnýho rozsahu (řekněme 192.168.1.0/24). To je myšlenka. Jde mi o technický řešení a jeho konkrétní provedení.
Ale my chapeme o co se snazis, jen ty zjevne nechapes, na jaky minovy pole vstupujes. Z toho co si tu jmenoval nepotrebuje ani jedna vec bridge. Bridge ma smysl pokud mas tu neskutecnou potrebu aby se dve zarizeni videla na L2. V opacnym pripade (tvym pripade) je to holej nesmysl. Krome veci ktery tu uz zaznely muzes a nejspis i narazis na spoustu dalsich veci. Pro predstavu trebas na MTU. Na L2 se moc nepocita s tim, ze by neslo poslat paket s MTU kterou mas definovanou, to v tomhle pripade plati, protoze ti neproleze pres ten tunel, pripadne ho tunel musi rozsekat nebo ty musis MTU zmensit => dalsi potize ... (a mimo jine horsi vykon site).
Pokud to beres jako experimentovani, OK, ale ver tomu, ze za par dnu tu budes resit, jak to predelat na routing. L2 se pouziva tam, kde je to nutny tehcnologicky pripadne tam, kde je vyzadovan vykon, ktery L3 neni schopno dosahnout.
Zkratka, kdo chce kam ...
-
Zrovna problém MTU bych do toho netahal. L2 tunelování to samozřejmě řeší pomocí rozsekání/složení, takže pro koncové zařízení je to transparentní.
Naopak, těch problémů, co jsem musel řešit s nejruznějšíma udělátky na L3 vrstvě, kdy to šlo routovaně třeba skrz GRE tunel a MTU bylo najednou 1480 místo 1500 a neustálo to, těch je nepočítaně. Někde stačilo šáhnout u TCP na MSS a srazit ho, často i tak hnusná věc, že se musel shodit DF bit, což také někdy nepomůže (IP sack neuměl složit fragmentované pakety), zkrátky kriplovských zařízení, co nezvládne MTU pod 1500, je víc než dost a pak i při routingu ho musím řešit tak, že se používá tunel, který to musí fragmentovat/skládat dohromady taky.
-
To by me fakt zajimalo jakej problem si mel na routovany lince s MTU 1480 ... kdyz kazda wifina ma jeste daleko min. A cestou do netu si ti na routovanych linkach MTU meni zcela bezne. Kupodivu, IP s tim zcela standardne pocita.
BTW: Co je to za propagaci krna zas ... uz ho tu mam snad po paty zasebou.
-
Trochu odlehčím (možná k nelibosti) - máte pravdu v tom, že vůbec netuším, do čeho jdu. Ok, opustíme myšlenku s jedním subnetem a přejdeme k myšlence, že pod každym MK bude "jeho" subnet a mě tedy půjde jen o to, aby se subnety viděly. Domény do toho nepleteme, to si pořeším až se subnety uvidí ;-)
Protože je jedenáct a protože 75% zmíněných věcí absolutně nerozumím - zkusíte to někdo? :-)
-
Add MTU: Skoro každá wifina umí MTU podstatně větší, jak 1500. Koukám na noťas, umí nastavit i 2200 (Atheros chipset). Wifiny dneska často skládají několik Ethernet rámců dohromady a přenášejí naráz pro lepší efektivitu. Jde samozřejmě nastavit, že to mají i sekat na podstatně míň a pak to zase složí...
Pokud jsi neměl dosud problém, tak jsi štastný člověk, že specifikace IPv4 má přesně řešeno, že se má pracovat od MTU 576, tak to neznamená, že reálné imoplementace to umí (zákony také říkají, že se nemá krást a jak to vypadá). V řadě krabiček je IPv4 stack tak oholen, že zkrátka neumí se přizpůsobit, neumí složit fragmentované pakety atd. Nejhezčí je, že často v té krabičce je linux nebo Windows CE, které to umí, ale skladačí to dorznili firewallem, takže krabička posílá MTU1500, má nastaveno DF a pak nepřijimá ICMP, že má zkrátit pakety ... a jsi nahranej. Počínaje VoIP telefony, web kamerama, ... na sto způsobů. Pak se to musí ojebávat nějak po cestě. A sekají se i slavní. Naposledy třeba VoIP telefony Siemens Gigaset C47x, tam volání funguje, ale web management nepřežije, když je to routnuté do tunelu, který neudrží MTU1500 (tady stačilo po cestě násilím šáhnout do TCP záhlaví a snížit MSS). A i takové Microsoft Windows, stačí se snažit použít jeho vestavěný VPN klient (PPTP, L2TP, L2TP/IPsec) a dát mu do cesty něco, co udělá MTU cca pod 1450 a je konec - tunel se sestaví, ale data už netečou (musí še šahnout do registrů).
Pavouk: Při routované síti se subnuty na 100% pro vše neuvidí, co používá broadcast nebo multicast, to bude mít problém. V domácím prostředí to přináší tak tři nejčastější požadavky:
a) Pokud trváš na tom, že když otevřes síťové okolí ve Woknech a má ti to ukázat všechny počítače v síti (i na té druhé straně), tak tohle fungovat nebude (pokud si je tam předem nedáš natvrdo). Uvidíš jen co je na lokálním segmentu (budlei na obou stranách server Samba/Windows, jde částečně řešit synchronizací browse listů).
b) Stejně tak ti případně nepojede DLNA a podobné, kde se používá multicasting v situaci, že budeš mít zdroj v jedné síti a TV třeba v druhé (tohle jde ale s Mikrotiky pořešit pomocí routingu multicastu pro některé případy).
c) Zmíněné případné problémy u některých tupých zařízení s MTU1500-, popsáno výše. Řešitelné několika způsoby, dle aktuální situace (nejuniverzálnější řešení s použitím tunelu zachovávající MTU1500 je výkonostně nejhorší).
Pro tvůj příklad s MKčky, kdy je v cestě jeden NAT, tak můžeš použít cokoliv, co ROS umí, vyhni se jen IPsecu, ten je skrz NAT uchodit problém. Takže klidně třeba L2TP, příklad zde:
http://wiki.mikrotik.com/wiki/Manual:Interface/L2TP#Site-to-Site_L2TP
V případě budoucího požadavku na zachování MTU1500 v tunelu, je to jen o změně jednoho parametru (nastavit MRRU na 1500 na obou stranách). Pokud nakonec budeš chtít přejit na bridgovanou síť je to také jen o nastavení jména bridge kam se přidat a zvednutí MRRU na cca 1600.
-
(budlei na obou stranách server Samba/Windows, jde částečně řešit synchronizací browse listů).
IMHO by mělo stačit všechny počítače nasměrovat na jeden WINS server.
-
U Samby musí mít jen jeden společný WINS server, Samba neumí replikaci dat mezi WINS. Nicméně WINS je k něčemu jinému, to je jen dynamický seznam netbios jméno(počítače|služby|uživatele):Aktuální IP adresa. Takže dotazující už musí vědět, jaké jméno ho zajímá. Od W2K potlačované řešené ve prospěch DDNS.
Pro sehnání seznamu počítačů v celé síti slouží browsery, které sbírají seznam na lokálním segmentu. V síti musí být jeden domain browser master (sídlí na PDC), browsery jendotlivých segmentů posílájí co našly na ten doménový, tne to utřídí a pak předává úplné seznamy zpět na segmentové browsery. Tohle v Sambě fungovalo tak nějak napůl. Lokální browsery sbíraly, předávaly na doménový a ten už to nějak nechtěl moc posílat zpět (takže jen komply připojené k segmentu s PDC viděly vše, v ostatních sítích jen lokální segment), ale už to amožná opravili, šlo to ojebávat ručním vynuceným nastavneím co a kam se má přeposílat. Ale je to od W2K8 také služba považovaná za mrtvou ve prospěch seznamu staticky vedeném v AD.
-
(budlei na obou stranách server Samba/Windows, jde částečně řešit synchronizací browse listů).
IMHO by mělo stačit všechny počítače nasměrovat na jeden WINS server.
A co když ten WINS server bude v síti která je momentálně neodstupná? Proto je třeba klienty směrovat na WINS server v lokální síti a WINS servery v různých sítích navzájem synchronizovat.
-
Měl jsem zato, že lokální browsery si informace s WINS serverem vyměňují. Tak to jsem se asi mýlil :)
A co když ten WINS server bude v síti která je momentálně neodstupná?
Tak to nebude fungovat no ;)
-
Samba ani Windows v síti nebudou - tedy minimálně ne na těch počítačích, které mě zajímají. DLNA už ale v síti bude a je pravděpodobné, že bude přesně jak je popisováno - server na jednom místě, klient na jiném.
Občas tu radím lidem stylem "for dummies". Poprosím M. a Mirka Prýmka, zda by mohli své navrhované řešení popsat v bodech, jedna řádka, jeden bod. Nechci vodit za ruku, ale chtěl bych to vidět přehledně napsané.
Příklad:
Na MK1 (VIP) nastavit OVPN server
Na MK2 nastavit OVPN klient
Na MK1 nastavit DHCP pool .1 - .127
Na MK2 ...
Jde mi o to, aby se mi přestaly plést dohromady věci, které spolu nemají vůbec souviset, před diskuzí jsem měl představu (která byla mylná nebo nepřesná), teď mám guláš :-)
Vycházíme z toho, že MKL1 má VIP, MK2 jí nemá. Za MK1 je plnohodnotný 24/7 PC s Linuxem, za MK2 bude taky (ale teď na případné testy NENÍ) - lze tyto servery využít při řešení (například nechat na nich běžet nějaké služby, které by byly potřeba k řešení).
-
Poprosím M. a Mirka Prýmka, zda by mohli své navrhované řešení popsat v bodech, jedna řádka, jeden bod. Nechci vodit za ruku, ale chtěl bych to vidět přehledně napsané.
Pokud tam chceš provozovat to DLNA, tak v tom případě poradit neumím, neznám ho a nevím, jestli se dá provozovat přes subnety.
Jinak by routovaná varianta byla takhle:
MK1 (VIP):
- LAN s rozsahem 192.168.1.x
- DHCP server s libovolným poolem v 192.168.1.x
- OVPN server, adresa 192.168.2.1
MK2 (PIP):
- LAN s rozsahem 192.168.3.x
- DHCP server s libovolným poolem v 192.168.3.x
- OVPN klient, adresa 192.168.2.2
Nevím teďka z hlavy, jestli OVPN na Mk umí automaticky vyřešit routy. Pokud ne, je potřeba MK1 říct, že pakety do 192.168.3.x má routovat přes OVPN a MK2 totéž pro cíle z 192.168.1.x
-
Mirek: Díky moc, přesně takhle jsem to potřeboval vidět ;-)
Tohle můžu vyzkoušet v blízký době na těch MK, který mam k dispozici teď.
Ještě jeden dotaz - na serveru za MK1 (VIP) běží DNS (jeho IP je mimochodem 192.168.1.1), rád bych ho použil jako primární DNS všech tří subnetů. To si v obou MK nastavím, aby přidělily jeho adresu, ale co když se rozpadne OVPN spojení? Pak by bylo lepší použít DNS od ISP. Pokud vezu v úvahu, že bych tohle řešil skriptem pro MK ve stylu "Jede OVPN? Přiděluj DNS 192.168.1.1. Nejede OVPN? Přiděluj DNS xx.yy.zz.aa." Je tahle úvaha správná nebo Tě napadá jiný řešení?
-
Afaik jsou dvě možný standardní řešení:
1. přiděluješ jako primární DNS ten Mk1 na druhé straně a jako sekundární ten od ISP
2. na Mk2 si rozjedeš cachovací DNS a do každé sítě pak přiděluješ jako primární DNS ten Mk v jeho síti
Rozhodně bych šel druhou cestou, ta první má jenom samé nevýhody.
-
Add WINS-Browsery: Ne ty servery spolu nepsolupracují. Umí spolupracovat WINS s DNS. NA Sambě jendostranně, WINS si umí vzít data z DNS, na Windows oboustranně, WINS s eumí zeptat lokálního DNS a i lokální DNS umí se ptát WINSu. Ptají se, když nenajdou data u sebe. Dál nemá smysl řešit, když to nebude potřeba.
DLNA: Na 95% to přes routovanou síť nebude jednoduše fungovat. Specifikace sice je postavena nad rozumnými protokoly, ale výrobci to ojebávají, takže donutit to jet jen skrz jeden router (což je jendodušší případ), je už celkem dost výzva. Přes dva (což je případ zde, pokud bude tunel), tak to bez dlouhého bádání, dumpování paketů je slušnou dizertační práci u některých produktů (a u některých nepojede nai tak). Tohle je pak na zvážneí, zda nejít do bridge varianty, pokud potřebuješ mít to takot rozhozeno.
Add DNS: Kolik máš v tom svém DNS záznamů a jak často se mění? Pokud pár, dají se dát do Mkček na obou stranách. Čili v DHCP klientům pošleš IP adresu lokálního MK, na něm bude zapnutý DNS forwarder (který bude přeposílat požadavky na IP u ISP, Google, OpenDNS, ...), do statické cache v MKčkách si zadáš těch svých 5 záznamů. Není to závislé na výpadku spojení lokalit, pro pár záznamů nejjednodušší, jen je musíš psát do těch dvou krabiček.
Jiná varianta: Na lokalitě jenda můžeš posílat lidem v DNS odkaz na ten tvůj lokální DNS server, když pak časem přidáš server a na něj DNS na druhou stranu, tka na druhé straně pošleš v DHCP odkaz na ten DNS server 2. DNS1 bude máaster a data budeš replikovat na DNS2 (slave). Edituješ pak na jendom místě. DNS1 a 2 budou fungovat i jako resolvery/cache.
-
Mirek: DNS běží na samostanym PC, ne na MK1. První cesty se bojím, protože pokud si dobře pamatuju, nikdy to nesekalo dobrotu. Nejspíš to ale bylo špatným nastavením (něco jsem podělal).
M.: DLNA jsem jen zmínil, ale už bych ho ošéfoval nějakym (nehezkym) způsobem, nemusíme to vysloveně řešit... DNS má samozřejmě asi 5 záznamů, ale znáš to, rád bych to řešil na vyšší úrovni ;-) Jde mi o to, aby to fungovalo, ale i o to, abych se za to nemusel stydět a něco se přitom naučil ;-)
Dva DNS mě taky napadly, ale vzniká trabl - lokalit může být více, ale DNS server na každé z nich být nemusí...
Teď je tu rozhodnutí, zda se do toho více potopit nebo ne... Pokud ano, tak:
Verze A:
Lokalita 1 - MK1, VIP, OVPN server, PC DNS server (master)
Lokalita 2 - MK2, neVIP, OVPN klient, PC DNS server (slave)
Lokalita 3 - MK3, poloVIP*, OVPN klient
Problém: Chcípne Lokalita 1, nedostanu se nikam mezi dalšíma dvěma (DNS chcíplý, spojení s OVPN serverem chcíplý = neví o sobě). Lokalita 1 může bejt mrtvá desítky hodiny (do 50). Podle mých dosavadních zkušeností a znalostí je tohle neřešitelnej problém (příliš složitý řešení a hacky vynecháváme).
Verze B:
Lokalita 1 - MK1, VIP, OVPN server, PC DNS server (master)
Lokalita 2 - MK2, VIP, OVPN server?/klient?, PC DNS server (slave)
Lokalita 3 - MK3, poloVIP*, OVPN klient
Konstatování: Může chcípnout Lokalita 1 nebo 2, ale zbývající dvě (tedy Lokalita 3 a ta nechcíplá) si dál povídají.
Otázka: Jak to provést? Udělat dva OVPN servery, spojit je oboustraně mezi sebou (tedy na každym udělat i klienta) a Lokalitu 3 připojit k oběma? To se asi docela zapotim, až to budu routovat, co? ;D
* poloVIP = VIP, ale proměnná. Dostane jí přímo MK na svou ether1. Pomocí skriptů v MK jsem dokázal docílit změny DNS záznamu na DNS serveru v Lokalitě 1, takže poloVIP mi byla známa = dala se použít jako VIP. Měl jsem ale děsnej problém s implementací změny DNS záznamu pomocí MK funkce, na Linux PC to jelo v pohodě, na MK to haprovalo. Nedokázal jsem to dostat do použitelnýho stavu :( Uvádím kvůli úplnosti. Případně to můžeme výhledově odštěpit do jiného tématu a pokusit se to rozchodit...
Pokud mě budete mít plný zuby a nebudete chtít řešit haldu teorie, která v praxi sice bude využitá, ale dost nadsazená, vzhledem k tomu, že jde celkem o méně než 10 PC a pravděpodobně <5% využití celkovýho konceptu, napište mi to. Rád bych pokračoval, jde ale o Váš čas.
-
To se nám to komplikuje. :-)
No, varianta A a šaškování kolem toho skriptama je blbost. čili udělat variantu B, to je běžné řešení, ostatní (jako lokalita 3 až N) se připojuje dvěma tunely, jeden do A, druhý do B. Aby to fugnovalo bez ohledu na to, zda lehne A nebo B, tak se uvnitř těch tunelu pustí např OSPF, který zajistí potřebný routing. Celkem běžná úloha. :-)
Mezi body 1 a 2 hodit tunel třeba GRE/IPsec. Na mobilní klienty, co jsou za NATem něco jiného, nejlépe kombinace víc druhů, občas někde něco nefunguje. Třeba jeden tunel SSTP a druhý L2TP. NEbo klidně oba SSTP, pokud j podstatná bezpečnostní stránka věci.
Pokud do lokality 2 nejde dostat veřejnou IP nebo IPv6 a koruna-dvě není problém, tak si pomůžu VPS serverem, který mi dovolí hostovat třeba RouterOS jako VPN server (samozřejmě bezpěčnostní stránka trochu trpí, ale je to funkční), čímž tu lokalitu podpořím a vše s epak tuneluje na místo 1 a VPS (místo 2 také si hodí tunel na 1 a VPS). Pár firem to nabízí. Např:
http://monovm.com/vpn-servers/
-
Proč já si to vždycky takhle komplikuju... ;D
M.: Pokud budou kačky, bude pravděpodobně i v Lokalitě 2 veřejná IP, prachy hýbou světem... Neměl by být potřeba server venku.
Mirku, co Ty na to? ;)
-
Mirku, co Ty na to? ;)
Já už to nějak nestíhám číst, natož chápat ;)