Virtuální síť (?) mezi Mikrotiky

[M.]

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.

[Reklama]

[Pavouk106]

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?

* 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.

[M.]

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/

[Pavouk106]

Proč já si to vždycky takhle komplikuju...

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?

[Mirek Prýmek]

Mirku, co Ty na to?

Já už to nějak nestíhám číst, natož chápat

[Reklama]