Dotaz: Jak propojit dvě serverovny do LAN?

[Fastmancz]

Dobrý den,

Chtěl bych se zeptat, jak propojit dvě různě sídlící serverovny (servery A, B) na jednu IP v LAN. Máme server (A) a server (B), potřebujeme propojit jejich síť do LAN přes tunel, aby mohl server (B) běžet na stejné IP serveru (A).

Můžete mi prosím někdo popsat návod popřípadě doporučit co a jak použít? Zkoušeli jsme EoIP tunel, jenže nefungoval.

Děkuji všem za rady, odpovědi.

---

---

Odpovědi

[bigBRAMBOR]

cožeto?

[NN]

Máme server (A) a server (B), potřebujeme propojit jejich síť do LAN přes tunel..

Jedina veta, ktera dava smysl.. Bud Vam poskytovatel protuneluje VLAN, nebo to budete muset do neceho zabalit napriklad GRE, nebo L2TP. Mimochodem "nefunguje" neni odpoved..

[Max]

Napiš zamýšlený stav s příkladem IP adres, to bude možná lepší. Současný dotaz nedává moc smysl.
Zdar Max

[Michal Kubeček]

Dotaz tak, jak je napsaný, nedává moc smysl. Napadají mne přinejmenším dvě interpretace:

1. Máte dvě lokální sítě a chcete je propojit tak, aby vám mezi nimi fungovalo všechno "jako kdybyste to propojil přímo drátem". Na to existují různé nástroje, v současné době bych asi doporučil vxlan, což je protokol, který byl navržen přesně pro tyhle účely. Samozřejmě je potřeba ten tunel nějak zabezpečit (např. IPsec - ale stačí cokoli, co umí tunelovat UDP provoz mezi jednou dvojicí portů).

Máte dvě lokální sítě používající adresy z rezervovaných rozsahů, stačilo by vám je proroutovat (nepotřebujete transparentnost až na úroveň ethernetu), ale bohužel používají kolidující rozsahy adres. To lze řešit tak, že budete oběma směry překládat adresy tak, že se pro každou síť bude ta druhá mapovat na nějaký jiný rozsah. Ne všem protokolům se to ale bude líbit (obecně bude mít problémy cokoli, co používá adresy i někde v aplikačním protokolu, jako u každého NATu). Ačkoli se to možná na začátku nezdá, v praxi je z dlouhodobého hlediska většinou nejlepší prostě jednu z těch dvou sítí přečíslovat.

Samozřejmě je ale možné, že jste myslel něco úplně jiného. Takže zkuste napsat pořádně, co vlastně potřebujete.

[hates]

Jde to a není to složité. Co vlastně ale chceš L2 protáhnout na dva servery které jsou například u jiných poskytovatelů? Je na to určeno třeba výše zmíněné vxlan kdy po L3 vrstvě protáhnes L2 na oba servery potom můžeš udělat třeba virtuální porty a přiřadit jim IP stejného segmentu. Nejjednodušší je použit k tomu L3 switche. Ja mam takto vyřešené 3 datacentra, služba má potom v DNS nastavenou záznam s velmi malým ttl a balancuji to na tři různé místa. Tak služba je potom nezávislá na tom ve kterém dc běží. Pokud mi vypadne jedno dc tak se pomocí spanning tree na switchi upravi cesty a jede se vesele dal. Tak nensem zavisli na zadnem dc a sluzba ma velmi vysokou dostupnost. Je to na delší povídání ale všechno jde když se chce a použijí se na to ty správné technologie.

[Fastmancz]

Děkujeme všem za odpovědi. Všechny odpovědi jsme zvažovali.

Nakonec jsme nasadili OpenVPN a propojení mezi serverama funguje (používáme L2 vrstvu), jenže nepřiřadí gateway, dále máme nastavený, aby nám trafik šel na klienta přímo přes VPNku, ale on tu VPN obchází.

Kde může být problém?

[X]

To myslite vazne nebo jenom kombinujete par IT slov ktere znate? Nenapadlo vas najmout si nekoho kdo alespon trochu tusi co dela?

[Michal Kubeček]

Všechny odpovědi jsme zvažovali.

Zvažoval jste i tuhle? "Takže zkuste napsat pořádně, co vlastně potřebujete." Jestli ano, škoda, že jste ji zavrhl.

[lertimir]

No mě připadá, že ani nemají znalosti, aby napsali otázku, která má smysl. Protože obojí je takový blábol, že to spíše vypadá, že jenom tuší jak síťování funguje a používají nástroje o kterých neví, co ve skutečnosti dělají.

[hates]

Příloha:

• Overlays-Blog-650x494.jpeg (67194 bytů)

Nenapsal jste zamer o co vam jde. Momentalne mi pripada ze chcete dosahnout nejakeho cile ale nevite jak ten cil ma vypadat.

Jiz Vas prvni dotaz byl zmateny, Ja jsem Vam odpovedel jak to lze udelat. Ale resit to pomoci VPN mi zrovna neprijde rozumne.

Nakreslete obrazek jak a kde mate servery a jakeho stavu chcete dosahnout.

Jestli mate na kazdem serveru verejnou IP a chcete aby si mezi sebou povidali po privatce a videli treba kvuli broadcastu tak vam VPN staci i ta nejjednodussi.

Pokud ale chcete na serverech virtualizovat a mit moznost umistit VM treba na serveru v DC2, ale pristupovat k nemu pres server v DC1 tak vam je jiz VPN k nicemu protoze je na to totalne nevhodne. Chcete dosahnout necohe podobneho jako na obrazku ktery je v priloze ?

[NN]

Jestli to neni trolling, tak bridge skrz OpenVPN je take reseni. Mam podezreni, ze resite L3 problem na L2 tunelu aka "redirect-gateway"..

[Pavel 'TIGER' Růžička]

A už jsme zase u té topologie sítě ... není nad to, když je to namalované, to pochopí každý, než popisovat současný stav, který se má změnit v jiný stav, o kterém navíc ani není jasná představa funkčnosti.

[Fastmancz]

Příloha:

• 3G8U.png (108064 bytů)

Můj kolega tedy udělal návrh a cituji co mi psal: "Potrebujeme virtualny server z serverovne 1 dostat na lokalni sit do serverovne 2 aby sa dana IP mola natovat v datacentru 2. Potrebujeme urobit ten prepoj siti".

[ehmmm]

Takze se pokusim tipnout, co chcete: "Potrebujeme, aby clenove site LAN2, tj. 192.168.6.0/24, videli i na virtualni server 192.168.6.20, jakoby byl u nich v LAN2." Uhodl jsem?

Kdyby ne, tak mam doplnujici otazky:

Ten virtualni server skutecne musi mit ip adresu z rozsahu 192.168.6.0/24?

Kdo v siti 192.168.6.0/24 dela branu? Je to ten server s ip adresou 1.2.3.5?

Co znamena napis "gateway" u serveru s adresou 1.2.3.4? Kam gateway?

Co znamena napis "forward portov na 1.2.3.5" u 192.168.6.20?

Z vyjadreni Vaseho kolegy: proc "se musi dana IP natovat v datacentru 2"?

Z tech krasnych popisu toho, co chcete, jsem pochopil, ze sam bych si poradil levou zadni, i kdyz se tim primo nezivim. Ale ze vy dva, pri brainstormingu s kolegou, nejste schopni ani popsat, o co vam jde, ac se tim pravdepodobne zivite.

[Pavel 'TIGER' Růžička]

To co je na tom obrázku jde zařídit od pouhého n2n přes openvpn až po různé, uzavřené krabičky. Nevidím v tom žádný problém. Pokud jste něco nastavili a ono to nefungovalo, tak jak jste to nastavili? Napsat: "Zkoušeli jsme EoIP tunel, jenže nefungoval." je akorát na ignoraci dotazu. Jak jste ho zkoušeli? Co to (ne)dělalo? To se tu má probírat. Takhle to vypadá, že chcete své trable hodit na nás a my je máme řešit.

[Fastmancz]

Takže nakonec se nám to podařilo propojit přes OpenVPN, jenže jsme nečekali, že bude takové omezení sítě a ano nejspíš jsem měl tuto informaci napsat dříve. Spustili jsme herní servery (Counter-Strike: Global Offensive) - běží výhradně přes UDP, ale i TCP, protože je potřeba k získání stavu serveru, RCON a jiné. Při velkém počtu hráčů se již problematicky zobrazoval stav herního serveru na webu - ukazoval offline, ale po několika refreshích jsem získal odpověď od serveru a najednou byl online.

Při připojení na server vzniká dlouhá prodleva v řádech 10 vteřin, než se skutečně dostanu na serveru. Server vše stíhá, ale jakmile na RDP spustím například nějakou webovou stránku, tak okamžitě VPN kolabuje. Linka je 100 Mbps.

Windows server běží jako client a Linux server běží jako OpenVPN server, kde je i firewall. Proto bych se chtěl zeptat na jinou alternativu, než OpenVPN, protože docela dost lidí si stěžuje na omezování rychlosti/propustnosti, takže jestli by nebylo lepší N2N?

Děkuji za názory.

[hates]

Z toho obrázku ale není vidět co na kterém serveru běží. Kde je win kde linux atd. Ta vpnka na to vliv mit nebude. Spíše někde něco blbě routujete.

[Fastmancz]

Myslíte, že by to mohl dělat Firewall? Běží na Linuxu společně s OpenVPN serverem.

#udp

iptables -t nat -A PREROUTING -d veřejná_ip_openvpn_serveru -p udp --dport 27015 -j DNAT --to-dest 172.27.22.2:27015

iptables -t nat -A POSTROUTING -d 172.27.22.2 -p udp --dport 27015 -j SNAT --to-source veřejná_ip_openvpn_serveru

#tcp

iptables -t nat -A PREROUTING -d veřejná_ip_openvpn_serveru -p tcp --dport 27015 -j DNAT --to-dest 172.27.22.2:27015

iptables -t nat -A POSTROUTING -d 172.27.22.2 -p tcp --dport 27015 -j SNAT --to-source veřejná_ip_openvpn_serveru

Divím se, že vůbec něco funguje. Je to úplně neuvěřitelné.

[Pavel 'TIGER' Růžička]

No já bych se zaměřil na NAT, tam bývají většinou největší ztráty ...

[hates]

no ono resit port dnat pomoci NAT 1:1 asi neni moc super. Hlavne se divim, ze chodi ta komunikace. predstava ze to vubec funguje je zarazejici. Hlavne ten POSTROUTING.

PREROUTING je spravne.

Ten postrouting by mel vypadat asi takto

iptables -t nat -A POSTROUTING -s 172.27.22.2 -j SNAT --to-source veřejná_ip_openvpn_serveru 

a staci vam pouze jeden. zamysli se jak ti chodi packety a potom se pozastav nad tim co jsi v tom POSTROUTINGU napsal ty a co ja. Idealni by bylo pokud by sis na tom serveru pustil tcpdump a krasne by jsi to tam videl.

[fish]

On to tam mozna ma kvuli routingu a chtel tam treba dat

iptables -t nat -A POSTROUTING -d 172.27.22.2 -j SNAT --to-source interni_vpn_ip_openvpn_serveru 

aby mu odpoved z virtualu sla ven pres branu pres kterou prisel dotaz. Ale tohle reseni je dost nevhodny a da se pouzit tak maximalne na sluzbu navazovanou jen zvenku, navic pokud mi nevadi, ze nebudu znat verejnou IP odkud to prislo.

Pri zamyslenym pouziti se to muze chovat dost nepredvidatelne, coz se asi v tuhle chvili deje. V ramci testovani bych dve brany vypustil a virtualu nastavil napevno branu pres VPN. Pak bych zjistoval, jak se to chova z pohledu funkcnosti a odezvy, jestli tomu VPN nevadi a pak teprve bych se snazil zprovoznit pristup na virtual pres obe verejny IP.

[NN]

Co je N2N?

[pavlix]

Mám za to, že jeden takový neudržovaný p2p VPN projekt.

[bigBRAMBOR]

běží výhradně přes UDP, ale i TCP ten člověk se mi líbí

[pavlix]

+1

Poezie.

[Fastmancz]

Tak jsem se upsal.. Vy toho naděláte.

[Ivan]

https://en.wikipedia.org/wiki/Ethernet_over_SDH

[hates]

Připadá mi, že ten člověk vymýšlí kolo. Při laparoskopii mozku taky neoperujete přes prdel. Na to co se snažíte docílit k tomu tam směřujete. Snažte se to udělat co nejjednodušším způsobem. K čemu proboha tolik natu atd. Já bych dal za NAT pouze ten virtuální server a mezi fyzickým zelezem bych protáhl vxlan. S tou vxlan bych možná nepotřeboval NAT vůbec,ale to bych musel vědět jak to dotyčný zamýšlí celé ten obrázek je totiž dosti nevipovidanici

[Fastmancz]

Dobrá, tak mi teda řekněte, jak by jste to chtěl jinak vyřešit, když máme FW přes který chceme pustit jen určité porty a to i včetně OpenVPN. Další věc, chceme mít klientskou IP "skrytou", takže veškerá komunikace běží přes IP (OpenVPN serveru).

Jen pro objasnění: Klientské PC (Windows Server 2008 R2) -> Běží zde cs:go server na portu 27015 s LAN IP xxx.xxx.xxx.xx OpenVPN server (Linux Debian) -> Běží zde FW, který se na základě iptables spojí s klientským PC (LAN IP) a veškerá data tečou přes OpenVPN server ke klientskému PC a zpětně. Samotné napojení na herní server běží z adresy OpenVPN serveru, takže yyy.yyy.yyy.yy:27015.

Nevím, možná děláme někde chybu, ale nevíme kde, protože jak jsem psal, momentálně je komunikace s VPN vcelku nestabilní.

Nepochybně děláte tu chybu, že vůbec nevíte, co chcete. Nemáte asi ani základní znalosti, takže se nedokážete zeptat tak, aby se v tom někdo vyznal.

[Ivan]

Ok a jaky prostredky mas k dispozici? Co ti nabizi provider? Pokud potrebujes neco propojit na L2 vrstve, tak je nejlepsi pouzit neco co je te L2 vrstve blizko. A k cemu to potrebujes?

[Fastmancz]

Potřebujeme zachovat původní IP adresu serveru. Výkonnější server je bohužel úplně mimo náš hlavní server (takže i ISP). Proto tedy hledáme způsob, jak správně propojit tyto dva servery s tím, že zůstane původní IP adresa serveru (hlavního serveru). Dotaz k této věci jsem pokládal i zde: http://www.abclinuxu.cz/poradna/linux/show/413227

Pokud existuje lepší způsob, jak tohoto docílit včetně stabilního spojení, tak budu rád za určitá doporučení. Bohužel nemáme technologie Cisco, které by toto spojení jistě usnadnili.

[hates]

podle tohoto popisu jsem to pochopil si takto

CounterStrike klient --------> Debian server --------> Windows server
                            Puvodni verejna IP      Nova IP, je zde verejna ?          

Na to staci pouze DNAT portu na serveru debian na ten novy server, klidne muze byt i s verejnou IP a ani nepotrebujete VPN

[Vantomas]

Když tam dá jen DNAT, tak se stane to, že server na novém IP bude pakety posílat přímo zpět na klienta a ten ty pakety zahodí, protože ty pakety budou mít jinou zdrojovou adresu než očekává.

Na tom obrázku co byl postnutý výše, co je ta gateway? Když se psalo něco o EoIP tunelu, tak tam máte nějakýho Mikrotika a za ním je pak server ve kterém běží nějaké virtuály? V tom druhém datacentru, kde je výkonnější server, tak tam je jenom server nebo je tam taky nějaký ten Mikrotik?

Jak to tak chápu, tak ty sítě mezi sebou nemusí nutně být bridgovány, stačí, když se jen správně nastaví routování (pokud tedy není potřeba pro běh nějakých služeb mít to na společné L2).

[Vantomas]

Jinak myslím si, že zrovna v případě herních serverů kam chodí hromada různých lidi je hloupost před tím serverem zakrývat reálnou IP adresu toho klienta. Nebude pak fungovat všelijaké banování nebo jiné vlastnosti běžící nad IP adresou klienta.

Samozřejmě to můžete řešit přímo na tom firewallu, ale je to takové drbání se pravou rukou za levým uchem.

[Michal Kubeček]

Především mi přijde diskutabilní už sám nápad přístup na herní server, u kterého - pokud vím - jde především a skoro výhradně o latence, tlačit přes tunel do jiné lokality a dobrovolně tak přidávat zbytečné milisekundy (to v ideálním případě) navíc. Tím spíš, že podle

Server vše stíhá, ale jakmile na RDP spustím například nějakou webovou stránku, tak okamžitě VPN kolabuje. Linka je 100 Mbps.

(ať už je "RDP" cokoli) tam někde ještě bude nějaké úzké hrdlo s dlouhým bufferem a bez nějakého aspoň základního opatření, které by zabránilo bufferbloatu.

[Vantomas]

Samozřejmě je to celé podivné. Ale jelikož jsem znal pár lidí kteří se motali kolem herních serverů, tak vím co to je za břídili a tudíž se tomu vůbec nedivím. A ono co si budeme říkat, jestli jsou ty datacentra alespoň ve stejném městě, tak růst latence nebude zas tak katastrofální a když jim to lidi zaplatí, jejich problém.

Osobně bych to teda spíš řešil DNS jménem a IP adresu neřešil, ale jak jsem říkal výše, nedivím se tomu.

[Kuna]

Tak, tak. Jenže fascinace těch břídilů kolem game serverů IP adresou (a příslušným portem!) je neskutečná. Je to něco jako okultní tajemství sdílené jen vyvolenými. Magická čísla která dokazují, že člověk je zasvěcen. O nějakém DNS nemají ani páru. Ale o Ciscu evidentně slyšeli, holt marketing

[pavlix]

Když tam dá jen DNAT, tak se stane to, že server na novém IP bude pakety posílat přímo zpět na klienta a ten ty pakety zahodí, protože ty pakety budou mít jinou zdrojovou adresu než očekává.

A proto se používá SNAT+DNAT. Jedná se o triviální TCP/UDP proxy setup, na který stačí pár pravidel v iptables. Používá se například když člověk potřebuje přenést traffic ze staré destinace na novou dřív než zajistí změny v DNS a dalších systémech.

[Fastmancz]

Hráč připojující se na -------> původní ip:27015 (Starý server - Linux: Debian) -----> UDP/TCP paket se dostane na nový server Windows server R2 (zde běží Counter-Strike: Global Offensive server) ----> a hráč se připojuje na původní IP adresou bez jakéhokoliv zjištění, že se připojuje reálně na nový server.

Takhle je to doufám pochopitelné. Ve zkratce, hráč se připojuje pod původní IP adresou starého serveru na nový server.

[Vantomas]

Ten nový Windows server, to je jako fyzický stroj nebo je to virtuál? Je možné tam přidat před to třeba nějaký router, kde by se vyřešila celá VPN a Windows server pak měl jen vnitřní adresu na LAN rozhraní? Bez toho aniž by na serveru pak běžel VPN klient.

Ve Windows se docela špatně nastavují routy kudy má ten traffic téct, je to na to takové nepřipravené.

[pavlix]

Viz výše. Lze to zařídit například markováním paketů, které zahajují spojení (platí i pro UDP pseudospojení) a na základě značky se upraví zdrojová i cílová adresa pomocí SNAT a DNAT. Samozřejmě to má svoje problémy (co ne?), jako třeba již v jiném komentáři zmíněné schování klientů za IP starého serveru.

[fish]

uz ho nechte. Dostal jednoduche rady, ktere nemaji tolik problemu a nemuze se beztak dobrat cile.

Ono ti co provozuji herni servry jsou z vetsi casti parmeni a mladi kluci a ne administratori serveru. Jinak nevim jestli tato verze CS serveru bezi i na linuxu, ale drive jsem na skole provozoval interni server a to nam bezelo na linuxu. Parili jsme na tom CS 1.6

Ja bych toto vlakno asi uzavrel jako vyresene, protoze odpoved dostal. Nejjednodussi je pouzit dve pravidla v podobe DNAT a SNAT. Ja mu jeste poradim v tom, ze ty pravidla se davaji do tabulky NAT a Chainu PREROUTING a POSTROUTING. Vice at si vyhleda v manualu k iptables.

[Michal Kubeček]

Bohužel nemáme technologie Cisco, které by toto spojení jistě usnadnili.

Tahle víra, že všemocné Cisco řeší všechny problémy za všech okolností nejlépe, jak to jen lze, mne nepřestává fascinovat. Vzpomínám si na jednoho Cisco Certified Cosi, který když nebyl schopen přijít na to, proč je mnou navrhované efektivnější řešení problému špatně (skutečný důvod byl že špatně nebylo), prohlásil: "Přece kdyby to bylo k něčemu dobré, tak by to to Cisco nabízelo taky." :-)

[pavlix]

Tahle nabubřelost mě taky baví.

[Ivan]

Reseni ti uz nabidnul Pavlix. To jak jsi puvodne popsal svuj problem bylo mnohem slozitejsi. Pokud opravdu potrebujes propojit dve servrovny na L2 urovni, tak aby se preposilal vsechen trafic, tak to se dela. Napriklad kvuli qos atributum v L2 hlavickach, ktere je potreba zachovat. Resi se to napr. pomoci EthernetOverSDH anebo se L2 qos prepise do L3 hlavicky a potom the IP packet "doruci" pres MLPS sit. Na druhe strane se zase qos prepise z L3 do L2. Ty nic takovyho ale NEPOTREBUJES. To co hledas by se dalo nazvat udp relay anebo udp proxy.

[hates]

Tys mu dal. Ten člověk očividně neví jak to udělat jednoduše a ty mu navrhuje s MPLS. Jasně že se to dělá ale mu nikdo MPLS okruh jen tak nenasadila a pokud ano tak ne zadarmo.

[Ivan]

Samozrejme ze MPLS neprichazi v uvahu. Problem je v tom, ze jak popsal svuj problem tak by se mohlo zdat ze MPLS je adekvani reseni. Nakonec se ale ukazalo, ze mu vlastne vubec nejde o L2 a ze jen potrebuje forwardovat UDP packety na jednom konkretnim portu.

[Stanislav Petr]

Mas v zasade dve moznosti ktery neovlivni MTU a nebudou trpet jinejma vaznejma problemama:

1. L2TPv3 protokol 2. Udelat si GRE tunel, nad nim MPLS vrstvu a VPLS propoj