KUTNY: uz jsem nasel zminku a priklady
How to configure a home router - MikroTik Wiki
https://wiki.mikrotik.com/wiki/How_to_configure_a_home_router#Bridging_vs_routing

nechapu jak jsem mohl tolik let fungovat bez toho abych tohle aspon zkusil.

LEXXA: To bohuzel nemuzu - nemam. Problemy s bridgem jsem resil v jinem pripade - u AP v bride mode.
Ale pokud neni problem, ze klient nebude na stejne L2 siti jako server, poslu, jak bych to nastavil.

KUTNY: muzes mi poslat odkaz na reseni toho co mam doma bez bridge?

LEXXA: To buzel nevim. Nemel jsem na to nervy a bridge jsem zrusil a bylo po problemu.

KUTNY: ano. mam jen dva mikrotiky takze btest jako takovy muzu generovat jen mezi nema.
taky me napadl bridge ale nejak nevim na co se koukat

LEXXA: Ten btest generujes na stejnem MT, ktery sifruje provoz klient - server?
Jestli ano, pak me napada, ze je rozdil mezi provozem generovanym obema MT a bridgovanym provozem pres ne.

LEXXA: a logy nic rozmuneho nevyhazuji?

LEXXA: hmm to mas pravdu kdyz je to takhle.

DELVIT: pokud by to bylo ISP tak mezi obema mikrotikama bych nedosahoval wire speed.
tohle se mi deje jen jdou data do mikrotiku - pres mikrotik - tunelem - do druheho mikrotiku - a do druhe site

LEXXA: aha jasne, ja si prave matne vybavoval 1460, ale mas tam jeste ten tunel. Zajimave ze to nic nezlepsilo. Neni mozne ze ISP nejak qoskem znevyhodnuje IPsec tunely? Vic me tedy nenapadá .)

DELVIT: chova se to uplne stejne

Manual:IP/IPsec - MikroTik Wiki
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#HEXv3_.28mmips.29_Config_Optimizations

Packet fragmentation can be avoided by sending packet over the tunnel that will fit in 1500 bytes after Ipsec and other encapsulation protocol headers are added. Ipsec header size depends on tunnel/transport mode and used encryption algorithm. With pure Ipsec in tunnel mode it is possible to safely send 1400byte packets. To avoid fragmentation for TCP traffic, change-mss rule should be added to change TCP MSS to 1400-40=1360bytes. See example in the mangle manual

LEXXA: A to nic nezlepsilo? Proc zrovna na 1360 to psali v tom navodu a nejak to vysvetlili?

DELVIT: muze, pisou to tam. proto dle navodu na strankach jsem zmenil mss

chain=forward action=change-mss new-mss=1360 passthrough=yes tcp-flags=syn protocol=tcp out-interface=vpnOut tcp-mss=1301-65535 log=no log-prefix=""

LEXXA: hmm, pokud se to bude vzdy sifrovat IPSecem tak se to blbe testuje. Nemuze byt problem, varim z vody, MTU napr?

DELVIT: coz o to. muzu ho uplne vypnout a jet ciste eoip. jde o to ze btest taky podleha ipsec politice tudiz se ten provoz taky musi sifrovat.

LEXXA: hehe, to se nedivim. Ale pokud je problem v IPSECu z nejakeho duvodu, coz je jedine co me zatim napada, tak. y se to tak dalo potvrdit ci vyloucit.

DELVIT: uprimne jse liny nastavovat ovpn

LEXXA: kdyz bys je zkusil projit jinak treba OpenVPN tak to dela to same?

simvas. drobet maturuji ze siti
mam dva mikrotiky coby gw do internetu. mezi nima je EoIP/IPSEC
kdyz pouzivam bw test se to chova absolutne nadherne. saham si na maximu linky. procesory zvladaji sifrovat. naprosta lahoda.

v obou dvou pripadech je setup plus minus stejny.
br0 - 1 iface jako wan. dhcp client je na br0
br1 - zbytek interfacu jako lan. dhcp server zase na br1
je tam par elementarnych fw pravidel, master nat masquerade, 5 simple queue na prioritizaci.
ve zratce mit tam mikrotika je overkill.

co se deje. za jednim z mikrotiku je server. za druhym mikrotikem je klient.
kdyz testuji iperfem (nebo nejak kopiuji data) tak se dostavam na cca 20% propustnosti dratu.
zaroven kdyz testuji kazdy z akteru v tom testovani zvlast tak dostavam docela prijatelne vysledky.

uz me nejak nenapada kde hledat a co mi skrti propustnost.

LEXXA: Když mě se to nikdy nechce.
A pak toho lituju :D

Nepoučitelnej.