Zdravím.
Nechci tu zde z nikoho tahat nějaké konfigurace či tak něco (alespoň zatím) ale potřebuji poradit.
Modelový příklad:
Máme rozlehlejší síť o několika budovách v kterých sídlí firmy co nemají nic společného.
Do areálu je přivedená linka, která nabízí 6 veřejných adres.
Po celém areále máme k dispozici LAN či optiku a jako hraniční router CCR1016 S12-S+ s moduly RJ45 nebo optikou
Zajímá mě, jaký je ten správný způsob přidělení veřejných IP.
1.eth - internetové připojení se 6 veřejnými IP (WAN)
2.eth - firma 1 (192.168.10.1)
3.eth - firma 2 (192.168.20.1)
....
1) Na 1.eth přidělit všechny veřejné adresy a pak pomocí src-nat a dst-nat přesměrovat veškerý provoz na vnitřní IP firmy třebana 192.168.10.2 kde bude čekat další router dané firmy a dělat si firewall a dlaší přesměšrování třebas na pošťáka atp.
nebo
2) vytvořit bridge a spojit eth 1-3 a pak na každém routeru firmy nastavit jednu z volných veřejných IP.
Základem je, abych mohl omezit rychlosti pro jednotlivé firmy (čímž mi trochu vypadává možnost 2 ale možná taky ne jen nemám znalosti).
Důležitá věc je také aby se firmy mezi sebou neviděli ale mohli si poslat email ze svých serveru co jsou u nich fyzicky umístěné (tam počítám, že se to bude otáčet nějaká na CCR1016 nebo se pletu?)
Nejedná se asi o nic extra složitého v tak malém měřítku. Věřím, že jsou tu mraky ISP, kteří toto mají těžce v ruce.
Snad se podělíte o svoje vědění:-)
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Rozlehlejší firemní síť - správné řešení
V principu ano. Na vstupu z/do internetu by měl být páteřní prvek (NAT, routing, FW, QUEUE - pro rozdělení rychlostí), v tvém případě CCR plně vyhoví. Firmy pak dostanou každá svůj fous, je jedno, zda fyzické rozhranní nebo vlanu, to záleží na topologii (pokud jde drát společně do dvou firem, tak vlan). Zvolil bych pak spíš rozsahy z pollu 10.xx.yy.zz než 192.168. Ale na funkci to vliv nemá. Každé firmě dáš vlastní veřejnou pomocí dst-nat, jak píšeš, nastavíš jim maximální kapacitu linky pomocí single queue. Pokud mají poštu uvnitř sítě na serveru, je dobré mít pro její odesílání ještě jinou IP, případně další pro odesílání NDR, ale to už jsme hodně v detailu. Jednotlivé segmetny firem bych od sebe striktně oddělil. Mailovou komunikaci mezi firmami bych normálně tlačil venkem přes jejich veřejné, určitě bych nehledal cestu, jak to routovat vnitřkem. Bylo by to složité, nebezpečné a výhoda z toho skoro žádná.
Pak je zvykem oddělovat provozy do různých IP sezmentů, např. dílna, veřejná wifi v zasedačce apod by neměli být na stejným IP segmentu a stejný vlaně jako účtárna a personální.
To zda zvolit variantu 1 nebo 2 je spíš na tom, jaký je vztah firem navzájem a jaký tvůj k nim. Pakticky i pro model 1 může být pro každou další firmu ještě jeden jejich FW na vstupu nich. Třeba nějakou autorizaci pro přístup zaměstnanců na internet a logování provozu asi jinak než přímo v dané firmě a ve vazbě na jejich AD nebo jiný IDM stejně nevyřešíš. Asi bych to na vstupu úplně nebrigoval, pak nebude nad vstupním prvkem kontrola nad konekšnama a trafikem - což u stroje na rozhranní veřejného a neveřejného internetu není úplně to pravé ořechové jak z pohledu bezpečnosti, tak z pohledu performance.
Další moje zkušenost je taková, že větší omezení než technické bývá bezpečnostně-organizačně-politické a s tím ti už ani nikdo neporadí, pokud nemá k firmám vztah a nepracuje na místě, protože se to organizace od organizace může diametrálně lišit. Takže s nima hodně mluv, než to zrealizuješ, aby pak nenastalo nějaké oboustranné rozčarování, že to není dost bezpečné nebo politicky špatně (např. pokud se firma A nemá ráda s firmou B, asi jim bude dost vadit, že jdou ven přes jednu stejnou veřejnou IP, zvlášť až skončí v blacklistu
)
Právě potenciální problém vidím v nedostatku veřejných IP.
Pak je zvykem oddělovat provozy do různých IP sezmentů, např. dílna, veřejná wifi v zasedačce apod by neměli být na stejným IP segmentu a stejný vlaně jako účtárna a personální.
To zda zvolit variantu 1 nebo 2 je spíš na tom, jaký je vztah firem navzájem a jaký tvůj k nim. Pakticky i pro model 1 může být pro každou další firmu ještě jeden jejich FW na vstupu nich. Třeba nějakou autorizaci pro přístup zaměstnanců na internet a logování provozu asi jinak než přímo v dané firmě a ve vazbě na jejich AD nebo jiný IDM stejně nevyřešíš. Asi bych to na vstupu úplně nebrigoval, pak nebude nad vstupním prvkem kontrola nad konekšnama a trafikem - což u stroje na rozhranní veřejného a neveřejného internetu není úplně to pravé ořechové jak z pohledu bezpečnosti, tak z pohledu performance.
Další moje zkušenost je taková, že větší omezení než technické bývá bezpečnostně-organizačně-politické a s tím ti už ani nikdo neporadí, pokud nemá k firmám vztah a nepracuje na místě, protože se to organizace od organizace může diametrálně lišit. Takže s nima hodně mluv, než to zrealizuješ, aby pak nenastalo nějaké oboustranné rozčarování, že to není dost bezpečné nebo politicky špatně (např. pokud se firma A nemá ráda s firmou B, asi jim bude dost vadit, že jdou ven přes jednu stejnou veřejnou IP, zvlášť až skončí v blacklistu
)Právě potenciální problém vidím v nedostatku veřejných IP.
0 x
Předně děkuju za vyčerpávající odpověď, nečekal jsem tu nic tak dlouhého.
Začnu odzadu.
Počet veřejných IP je dostačující, každá firmička v areálu si vystačí s jednou IP.
Co se vztahů týče, tak ty jsou absolutně v pořádku (zatím)
V tuto chvíli už to mám jakštakš hotové ale nejsem si jist jestli je to to správné řešení. Přijde mi, že je to dost nepřehledné na to jak je to malé řešení a nedovedu si dost dobře představit ISP, který má 500 IP nad celým městem či tak něco. To musí být neskutečný "bordel"
Do WAN mám nakonec bridge kdybych náhodou chtěl vysunout něco napřímo třebas VoIP ústřednu (údajně je lepší, když není za natem) Ostatní firmičky jsou udělány pomocí src-nat a dst-nat na svojí IP a poštu mám taky přenatovanou a funguje to.
Co se týče oddělení firem od sebe tak mám ve FW pravidlo drop forward src add vnitřní IP firma 1 dst add vnitřní IP firma 2 + in interface s portem !25. To ale funguje tak nějak z části. Poštu to pustí což je dobře ostatní to už nepovolí až na ping což nechápu... to by mělo být taky zakázané (ale budiž)
Celkem bych si zkusil střihnout nějaké to školení MK. nějaká zkušenost? nejsem žádný specialista jen si rád hraju s MK ve volném čase
Začnu odzadu.
Počet veřejných IP je dostačující, každá firmička v areálu si vystačí s jednou IP.
Co se vztahů týče, tak ty jsou absolutně v pořádku (zatím)
V tuto chvíli už to mám jakštakš hotové ale nejsem si jist jestli je to to správné řešení. Přijde mi, že je to dost nepřehledné na to jak je to malé řešení a nedovedu si dost dobře představit ISP, který má 500 IP nad celým městem či tak něco. To musí být neskutečný "bordel"
Do WAN mám nakonec bridge kdybych náhodou chtěl vysunout něco napřímo třebas VoIP ústřednu (údajně je lepší, když není za natem) Ostatní firmičky jsou udělány pomocí src-nat a dst-nat na svojí IP a poštu mám taky přenatovanou a funguje to.
Co se týče oddělení firem od sebe tak mám ve FW pravidlo drop forward src add vnitřní IP firma 1 dst add vnitřní IP firma 2 + in interface s portem !25. To ale funguje tak nějak z části. Poštu to pustí což je dobře ostatní to už nepovolí až na ping což nechápu... to by mělo být taky zakázané (ale budiž)
Celkem bych si zkusil střihnout nějaké to školení MK. nějaká zkušenost? nejsem žádný specialista jen si rád hraju s MK ve volném čase
0 x
ok, tak už jen stručně 
jedna IP jedna firma = málo, pokud je v síti poštovní server. Zkušenost ukáže
proti bordelu jsou standardy a evidence (poctivě vedená), školení pracovníci resp. sebedisciplína a vědomí, že co teď ošulim se mi později vrátí řádově hůř. Pak je jedno, jak je řešení veliké. Od určité velikosti to chce ale nějaký nástroj, xls tabulka ztrácí dech.
bridge nemám rád, ale možná je to jen můj pocit. Asi to fungovat bude.
Ping projde, protože je to ICMP nikoli TCP packet. Tedy se na něj pravidlo neuplatní. Udelej pravidlo ještě jednou a dej do něj místo TCP ICMP.
Já nikdy na MK školení nebyl. Vše je na netu. Pokud má člověk představu o síti, jak se to má chovat, nakliká to už pak v lecčems (záměrně nepíšu v čemkoli, protože např. Cisco se bez školení a rutinní praxe fakt nedá). Ale taky nejsem žádnej expert.
kdo si hraje, měl by si hrát doma a ne pracovat pro firmy, kde chyba může ohrozit jejich podnikání
Hodně ISP si také hraje a často je to otřesné.
jedna IP jedna firma = málo, pokud je v síti poštovní server. Zkušenost ukáže
proti bordelu jsou standardy a evidence (poctivě vedená), školení pracovníci resp. sebedisciplína a vědomí, že co teď ošulim se mi později vrátí řádově hůř. Pak je jedno, jak je řešení veliké. Od určité velikosti to chce ale nějaký nástroj, xls tabulka ztrácí dech.
bridge nemám rád, ale možná je to jen můj pocit. Asi to fungovat bude.
Ping projde, protože je to ICMP nikoli TCP packet. Tedy se na něj pravidlo neuplatní. Udelej pravidlo ještě jednou a dej do něj místo TCP ICMP.
Já nikdy na MK školení nebyl. Vše je na netu. Pokud má člověk představu o síti, jak se to má chovat, nakliká to už pak v lecčems (záměrně nepíšu v čemkoli, protože např. Cisco se bez školení a rutinní praxe fakt nedá). Ale taky nejsem žádnej expert.
kdo si hraje, měl by si hrát doma a ne pracovat pro firmy, kde chyba může ohrozit jejich podnikání
Hodně ISP si také hraje a často je to otřesné.
0 x
Jakákoliv větší síť většinou nemá jediný prvek jako gateway. Ani fyzicky, ani především logicky. Síť je rozsegmentovaná, mezi jednotlivými větvemi se routuje a zálohuje. Na nějakou ochranu klientů se obecně řečeno kašle. Ono je totiž těžko říci, kdy je to ještě ochrana a kdy už nemístné omezování připojení. Ochrana je tedy na koncových uživatelích, na jejich firewallech.
Větší sítě jsou prostě internet, jen se předávají pakety sem a tam. Nikoliv firemní LAN s vrátným ...
A také na to mají systémy.
Pokud řešíš areál tak jak řešíš, tak ale moc možností nemáš. Šest IP je prostě málo pro víc jak dvě firmy. Takže musíš mít centrální NAT. A přeci jenom bych to dělal routingem. Každá firma vlastní spoj (na CCR máš portů dost), nebo alespoň VLAN. A nad ní samostatný IP segment nad privátními adresami (ale vybral bych si také raději jiné, než 192.168. a nejspíš i ne 10.).
Nebo to můžeš udělat stylem sdíleného segmentu. Tedy bridge ve tvém případě. Tam budeš mít celý segment veřejných (hlavní WAN ale musí být z jiného segmentu) a routery firem budou mít tedy jednu z nich. Zabezpečení je vcelku logicky opět na nich. Buď budou akceptovat provoz od ostatních, nebo nebudou. Filtrovat na bridge samozřejmě můžeš také, pokud zajistíš, že vše půjde přes něj. Výhodou je, že nebudeš nikde NATkovat a potřebuješ jen ty IP, které skutečně potřebuješ.
Ale mám takový pocit, že s tím mým druhým návrhem máš smůlu právě kvůli podmínce extra WAN segmentu.
Větší sítě jsou prostě internet, jen se předávají pakety sem a tam. Nikoliv firemní LAN s vrátným ...
A také na to mají systémy.
Pokud řešíš areál tak jak řešíš, tak ale moc možností nemáš. Šest IP je prostě málo pro víc jak dvě firmy. Takže musíš mít centrální NAT. A přeci jenom bych to dělal routingem. Každá firma vlastní spoj (na CCR máš portů dost), nebo alespoň VLAN. A nad ní samostatný IP segment nad privátními adresami (ale vybral bych si také raději jiné, než 192.168. a nejspíš i ne 10.).
Nebo to můžeš udělat stylem sdíleného segmentu. Tedy bridge ve tvém případě. Tam budeš mít celý segment veřejných (hlavní WAN ale musí být z jiného segmentu) a routery firem budou mít tedy jednu z nich. Zabezpečení je vcelku logicky opět na nich. Buď budou akceptovat provoz od ostatních, nebo nebudou. Filtrovat na bridge samozřejmě můžeš také, pokud zajistíš, že vše půjde přes něj. Výhodou je, že nebudeš nikde NATkovat a potřebuješ jen ty IP, které skutečně potřebuješ.
Ale mám takový pocit, že s tím mým druhým návrhem máš smůlu právě kvůli podmínce extra WAN segmentu.
Vodny píše:V tuto chvíli už to mám jakštakš hotové ale nejsem si jist jestli je to to správné řešení. Přijde mi, že je to dost nepřehledné na to jak je to malé řešení a nedovedu si dost dobře představit ISP, který má 500 IP nad celým městem či tak něco. To musí být neskutečný "bordel"
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Můžu poprosit o trochu konkrétnosti? Na co narazím v průběhu času nebo na co můžu narazit?
Souhlas nikterak neriskuji a pokud uvidím, že na to nestačím, tak to nechám někomu. Jen jsem se toho ujal, protože pro jednu z firem v areálu dělám IT a v rámci rozšiřování znalostí to zkusím. Přeci jen základní znalost MK se neztratí a kde si to jinde vyzkouším:-) A na testování tu jsou slušné časové intervaly, které nikoho neomezují. Snad jen servery s poštou nejsou chvíli dostupné a protože před nimi sedí na VPS jiný pošťák, tak vlastně ani nic neztratím.
Ano to je logické zrovna tak mi projde UDP a ostatní protokoly. Špatně jsem si to pravidlo vyložil tím, že je fakt jen na ty TCP a jelikož následující pravidlo Forward do sítě accept tak už to tam projde.
Takže řešení je zakázat všechnu komunikaci mezi IP a nad ní nové pravidlo povolí pouze tu 25 na poštu
Souhlas, pokud alespoň trochu člověk čte anglicky, tak načte asi většinu co potřebuje. Nicméně ta praktická část těch školení může být zajímavá.
jedna IP jedna firma = málo, pokud je v síti poštovní server. Zkušenost ukáže
Souhlas nikterak neriskuji a pokud uvidím, že na to nestačím, tak to nechám někomu. Jen jsem se toho ujal, protože pro jednu z firem v areálu dělám IT a v rámci rozšiřování znalostí to zkusím. Přeci jen základní znalost MK se neztratí a kde si to jinde vyzkouším:-) A na testování tu jsou slušné časové intervaly, které nikoho neomezují. Snad jen servery s poštou nejsou chvíli dostupné a protože před nimi sedí na VPS jiný pošťák, tak vlastně ani nic neztratím.
kdo si hraje, měl by si hrát doma a ne pracovat pro firmy, kde chyba může ohrozit jejich podnikání
Ano to je logické zrovna tak mi projde UDP a ostatní protokoly. Špatně jsem si to pravidlo vyložil tím, že je fakt jen na ty TCP a jelikož následující pravidlo Forward do sítě accept tak už to tam projde.
Takže řešení je zakázat všechnu komunikaci mezi IP a nad ní nové pravidlo povolí pouze tu 25 na poštu
Ping projde, protože je to ICMP nikoli TCP packet. Tedy se na něj pravidlo neuplatní. Udelej pravidlo ještě jednou a dej do něj místo TCP ICMP.
Souhlas, pokud alespoň trochu člověk čte anglicky, tak načte asi většinu co potřebuje. Nicméně ta praktická část těch školení může být zajímavá.
Já nikdy na MK školení nebyl. Vše je na netu. Pokud má člověk představu o síti, jak se to má chovat, nakliká to už pak v lecčems (záměrně nepíšu v čemkoli, protože např. Cisco se bez školení a rutinní praxe fakt nedá). Ale taky nejsem žádnej expert.
0 x