Add MTU: Skoro každá wifina umí MTU podstatně větší, jak 1500. Koukám na noťas, umí nastavit i 2200 (Atheros chipset). Wifiny dneska často skládají několik Ethernet rámců dohromady a přenášejí naráz pro lepší efektivitu. Jde samozřejmě nastavit, že to mají i sekat na podstatně míň a pak to zase složí...
Pokud jsi neměl dosud problém, tak jsi štastný člověk, že specifikace IPv4 má přesně řešeno, že se má pracovat od MTU 576, tak to neznamená, že reálné imoplementace to umí (zákony také říkají, že se nemá krást a jak to vypadá). V řadě krabiček je IPv4 stack tak oholen, že zkrátka neumí se přizpůsobit, neumí složit fragmentované pakety atd. Nejhezčí je, že často v té krabičce je linux nebo Windows CE, které to umí, ale skladačí to dorznili firewallem, takže krabička posílá MTU1500, má nastaveno DF a pak nepřijimá ICMP, že má zkrátit pakety ... a jsi nahranej. Počínaje VoIP telefony, web kamerama, ... na sto způsobů. Pak se to musí ojebávat nějak po cestě. A sekají se i slavní. Naposledy třeba VoIP telefony Siemens Gigaset C47x, tam volání funguje, ale web management nepřežije, když je to routnuté do tunelu, který neudrží MTU1500 (tady stačilo po cestě násilím šáhnout do TCP záhlaví a snížit MSS). A i takové Microsoft Windows, stačí se snažit použít jeho vestavěný VPN klient (PPTP, L2TP, L2TP/IPsec) a dát mu do cesty něco, co udělá MTU cca pod 1450 a je konec - tunel se sestaví, ale data už netečou (musí še šahnout do registrů).
Pavouk: Při routované síti se subnuty na 100% pro vše neuvidí, co používá broadcast nebo multicast, to bude mít problém. V domácím prostředí to přináší tak tři nejčastější požadavky:
a) Pokud trváš na tom, že když otevřes síťové okolí ve Woknech a má ti to ukázat všechny počítače v síti (i na té druhé straně), tak tohle fungovat nebude (pokud si je tam předem nedáš natvrdo). Uvidíš jen co je na lokálním segmentu (budlei na obou stranách server Samba/Windows, jde částečně řešit synchronizací browse listů).
b) Stejně tak ti případně nepojede DLNA a podobné, kde se používá multicasting v situaci, že budeš mít zdroj v jedné síti a TV třeba v druhé (tohle jde ale s Mikrotiky pořešit pomocí routingu multicastu pro některé případy).
c) Zmíněné případné problémy u některých tupých zařízení s MTU1500-, popsáno výše. Řešitelné několika způsoby, dle aktuální situace (nejuniverzálnější řešení s použitím tunelu zachovávající MTU1500 je výkonostně nejhorší).
Pro tvůj příklad s MKčky, kdy je v cestě jeden NAT, tak můžeš použít cokoliv, co ROS umí, vyhni se jen IPsecu, ten je skrz NAT uchodit problém. Takže klidně třeba L2TP, příklad zde:
http://wiki.mikrotik.com/wiki/Manual:Interface/L2TP#Site-to-Site_L2TPV případě budoucího požadavku na zachování MTU1500 v tunelu, je to jen o změně jednoho parametru (nastavit MRRU na 1500 na obou stranách). Pokud nakonec budeš chtít přejit na bridgovanou síť je to také jen o nastavení jména bridge kam se přidat a zvednutí MRRU na cca 1600.