Transparentny FW z FreeBSD

Dan Lukes dan at obluda.cz
Thu Mar 8 02:26:12 CET 2018


On 7.3.2018 19:20, Vilem Kebrt wrote:
> v rámci zpracování jedou jednotlivé checky paralelně

> každý thread kontroluje jemu příslušnou část. 

No, a to je prave to, co budes na FreeBSD s existujicimi nastroji 
dosahovat jen tezko. Tohler bysis musel napsat ...

A nevim o tom, ze by to nekdo nabizel jako open source.

> Zde si dle mého názoru můžeš urychlit rozhodovací procesy skrze binary match tables

'tables' v IPFW jsou implementovany jako b-strom (tim se 'table' 
vyznamne lisi od seznamu IP adres oddelenych carkami).

> Jako další příklad si můžeš vzít hloupyho mikrotika

No prave - na ty jsem pri tomhle hodne myslel ;-)

Jsou typickym zastupcem zarizeni, ktere 'wirespeed' casto nezvlada.

Zminena RB600 mela tri gigabitove fullduplexni porty, ale pokud vim, tak 
plny tok ze dvou portu do tretiho tedy 1Gbps (prakticky priklad dve 
stanice + uplink) to uswitchovat nedokazalo ani nahodou. Jako 
border-router asi prijatelny (a tak jsi to taky pouzival), ale jako 
gigabitovy intra-switch nic moc.

Myslim totiz na Wokna v domene pri prihlasovani nebo odhlasovani 
uzivatele (kdyz se synchronizuje uzivatelsky profil). U toho je "rozdil, 
ktery citite" jestli mas pul gigabitu, nebo jen petinu.

Proto mi nedela problem mit neco "zpomalujiciho" jako border-router, ale 
na switch mi to nezni lakave. A bojim se, ze FreeBSD bude v naznacene 
roli vykazovat prave tuhle neprijemnou "Mikrotikovost".


> On 7.3.2018 21:05, Jozef Drahovsky wrote:
> Existuje firma, ktora ma verejne C, vlastne AS,vlastny reverzny DNS 
> a viac krat optiku od roznych providrovza drahe peniaze, kde verejne 
> bezi vselico mozne.
> 
> Okrem toho ma viacero pracovisk kde je tiez sirokopasmovy pristup, ale 
> len jednu verejnu IP a aj to nie vsade fixnu, navyse bez 
> moznostinastavenia reverzneho DNS.
> Pritom rozdiel mat a nemat moznost nastavit reverzu domenu podla seba je 
> 400% mesacnej ceny.
> 
> Kazde z tychto pracovisk chce mat u seba okrem obvykleho PAT pristupu 
> pre bezne pocitace, aj niekolko verejnych serverov bez NAT z dovodu 
> specifickeho vyvoja a experimentalnej prevadzky.


Me takovehle zadani vede na samostatne LAN s privatnimi IP v 
jednotlivych lokalitach, ty vzajemne routovane (propojene nejakou formou 
VPN) a smerem ven prekladane.

Konkretni verejne adresy, ktere jsou k dispozici jen v HQ, se podle 
potreby 1:1 mapuji na adresy vnitrni, kde uz do "spravne pobocky" 
doputuji po te vnitrni routovane siti.

Tohle vsechno je relativne "normalni topologie" a zvladne ji "bezne" 
nabusene FreeBSD (samozrejme zalezi take na celkovych datovych tocich).

Divam se na to velice pragmaticky (a jeho koreny sahaji do doby, kdy 
jsem se staral o sit jedne financni instituce s radou pobocek po 
republice).

Obcas se proste neco podela - bud' "samo", nebo v souvislosti s udrzbou 
(upgrade, rekonfigurace - a ono se tenhle ukonum donekonecna vyhybat 
nelze).

Specialni konfigurace site jsou sice velice efekt(iv)ni, ale kdyz se pak 
takova sit zhrouti a nefunguje, tak se daleko hur analyzuje pricina 
jakoz i naleza reseni. Mj. se clovek nema s kym poradit, protoze malokdo 
neco podobneho provozuje; dale - jakmile zavisis na vlastnostech 
systemu, ktere malokdo pouziva, prudce vzrusta riziko, ze nemusi 
fungovat dle ocekavani (a obzvlaste, nikoliv vsak vylucne, po jakemkoliv 
upgrade).

Oproti tomu "drevacka" konfigurace obvykle neni az tak elegantni, obcas 
ma nejaka "by design" omezeni kterym se je nutne nejak prizpusobit (coz 
ale vetsinou jde) - proti tomu ale stoji vyznamne nizsi riziko 
"podivnych zavad" (mj. proto, ze pouzivas prevazne ty funkce systemu, 
ktere pouziva kde kdo). A kdyz uz se nejaky problem objevi, daleko snaz 
se analyzuje i odstranuji (pripadne hleda se nejaky workaround).

Zdrojem potizi muze byt i konkretni stanice, kde se rozsype sitovy stack 
nebo s HW zavadou karty - o kreativite uzivatelu pri instalaci ruzneho 
software nemluve. A ty mluvis dokonce o vyvojovych a experimetalnich 
serverech. Takovy problem daleko spis zlikviduje "jen" zasazenou LAN, a 
jen mene pravdepodobne celou korporatni sit.

Urcite bych se snazil vyhnout rozsahle (geograficky i poctem stanic) LAN.

Celkove, to co popisujes bych (ja) zacal zvazovat teprve pote co bych 
vyloucil vsechna "normalnejsi" reseni.

Pripoustim, ze muj odpor nejspis dost souvisi s tim, ze skoda 
souvisejici s nefunkcni vnitrofiremni komunikaci se uz tehdy blizila 
dost stovkam tisic za pulden vypadku. Pokud jsi ve vyrazne jine hladine, 
pak te "velmi specialni topologie site" samozrejme nemusi strasit 
zdaleka tak jako me ...

Jen sdilim zkusenosti. Vyber si z toho co je ti mile ;-)


Dan




More information about the Users-l mailing list