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