iTomB píše:ludvik píše:Mazání nejstarších spojení postrádá logiku. Je lepší odmítnout nové (a zapsat do logu), než nějakým algoritmem ořezávat stará, klidně dlouhodobě běžící spojení.
Jak kdy, pokud mas nastaven delsi cas ip_conntrack_tcp_timeout_established a vyhnivaj ti treba spojeni TCP=5228.
ludvik píše:To je trochu jiný případ. Vyprší timeout, to je standardní chování. Také je to pitomost od aplikace, že si občas nepošle nějaký noop paket.
Já napadl to, že nová konexe nahradí nějakou starou, pokud už pro ní není místo. To se nestane.
Jenya píše:Kdyz uz jsme u toho, ma smysl, aby TCP established timeout byl vetsi nez treba 10 minut?
iTomB píše:Jenya píše:Kdyz uz jsme u toho, ma smysl, aby TCP established timeout byl vetsi nez treba 10 minut?
Rozhodne. Idelane par hodin ja mam i o dost vic ...
Za 10 minut bych te odstrelil.
Tom
Jenya píše:V moji nepritomnosti, me muzes i rozkrajet
Ocenil bych kdyby se k tomu mohl vyjadrit nekdo, kdo tomu rozumi a umi to zduvodnit.
Jsou v praxi aplikace, ktere pocitaji s navazanym TCP, avsak treba hodiny nekomunikuji?
A pokud je sdílená, je sdílení řešeno programově při generování NAT tabulky. Ona je totiž sdílená vlastně vždy, většinou ale jen v rámci jednoho usera.ludvik píše:Každý má svoji IP
ludvik píše:Vzhledem k tomu, že parametr persistent mikrotik nepodporuje, tak ti nezbývá než to řešit naprosto stejně. Možností je několik ... API, nebo třeba generování scriptu a jeho upload pomocí FTP. Nebo prostě ruční práce, pokud toho nemáš tolik.
Na čistém linuxu pomáhají atomické operace iptables-save/restore. Na mikrotiku je to krok za krokem ...
pgb píše:Lab ... aneb každý určitě děláte domácí úkoly, vzděláváte se a pak to prezentuejte do okolí:
- testovací sestava obsahuje 6x CLI ---- GW === DST1 / DST2
- na GW probíhá natování za účelem zjištění, jak se chová SRCNAT při zadání rozsahu jako překládané části
- DST1 i DST2 mají nastavenou routu na WAN GW aby to celé dobře fungovalo
- CLI mají rozsah 192.168.18.0/24 natuje se na rozsah 10.11.12.0/30
- poznámka k algoritmu "same" ... je tam jistý algoritmu ve zvolení překládaných ip a není to roud robin, ale je odvozený od src/dst ip (dle same-not-by-dst=YES/NO) a až pak dochází k pat overload
----- 192.168.18.2 je pomocí "same" přeloží za 10.11.12.2
----- 192.168.18.3 je pomocí "same" přeloží za 10.11.12.3
----- 192.168.18.4 je pomocí "same" přeloží za 10.11.12.0
add action=src-nat chain=srcnat out-interface=ether5 src-address=192.168.18.0/24 to-addresses=10.11.12.0/30
- asi nejhorší možná varianta, ip adresa za kterou se natuje je vybrána z mého pohledu chaoticky
- paradoxně se zdá, vícero spojení z jedné zdrojové LAN ip na více serverů stále překládá za stejnou IP ale nemohu zaručit
add action=same chain=srcnat out-interface=ether5 same-not-by-dst=no src-address=192.168.18.0/24 to-addresses=10.11.12.0/30
- trochu lepší varianta, ip adresajako jaká ip se budete tvářit je odvozena algoritmem který používá jako vstupní podmínku "same" + kolikáte je to spojení na cílové servery a po vyčerpání překládacích ip (10.11.12.0/30) provádí pat overload
- problémem je vícenásobné spojení např. na video servery - z pohledu serveru se tam snaží připojit hromada ip adres a přitom se na GW pak sjednotí => ve výsledku to nechce třeba přehrávat videa
add action=same chain=srcnat out-interface=ether5 same-not-by-dst=yes src-address=192.168.18.0/24 to-addresses=10.11.12.0/30
- nejlepší varianta, používá se podmínka "same" dokud není spojení moc a pak nastane pat overload
- podmínka same-not-by-dst=yes zajistí, že pokud se CLI1 připojuje k DST1 i DST2 tak má stále stejnou "vnější" ip i když přistupuje k více zdrojům
