Dobrý den,
diky za odpověď, vstoupim do diskuze za kolegu, jsem ten kdo to konfiguroval.
Ve chvíli, kdy to přestane fungovat se tunel stále tváří na obou stranách jako established. Ping funguje oboustranně, a odpovídá realitě, tzn. i ze strany, kde přestanou fungovat určité typy komunikace, ping přes tunel funguje jen proti "živým" zařízením druhé strany. Většinou fungují i DNS dotazy na DNS server na druhé straně. Přestanou jakoby fungovat přenosy s větší velikostí packetu, resp. na MTU máme podezření. Zkoušeli jsme laborovat s nastavením MTU na VDSL Vodafone (na PPPoE interface mikrotiku), ze standardních auto 1480 na 1492, výsledek stále tentýž. Navíc ping s nastavenou velikostí packetu a zákazem fragmentace prochází ikdyž nastane problém. Teď to, po prvním problémovém týdnu, jelo skoro měsíc v podstatě bez problémů a nyní to opět začalo blbnout, je třeba udělat několik restartů tunelu denně. Nastavoval jsem a mám ve správě v podstatě několik desítek tunelů přes VDSL v režimu bridge, na Cisco i Mikrotik routerech, které jedou bez problémů, ale to je vše na VDSL přímo od O2, od Vodafone jinde nic nemám, tak mi chybí konkrétní zkušennost s provozem. Samozřejmě může být problém i s NATem u poskytovatele druhé strany, to ale bohužel težko ovlivníme. Většinou stačí restart tunelu, jen vyjímečně je třeba i restart PPPoE spojení přes Vodafone VDSL.
Konfigurace je Main, na straně VDSL (strana, která vykazuje ten problém) je modem v režimu Bridge, na Mikrotiku je veřejná IP přes PPPoE, druhá strana je připojena lokálním WiFi providerem, který používá pro klienty lokální adresy a NATuje je na svém rozhraní, z veřejné adresy vyhrazené pro konkrétního klienta.
Jelikož se nám nedaří najít příčinu, pro automatický restart tunelu jsem udělal script využívající toho, že při problému nefunguje fetch webové stránky z protistrany, takže to cyklicky v intervalech testuje a když to neprojde restartne tunel. Ale samozřejmě bychom raději našli podstatu problému a nehasili jen následky.
9 Odpovědí
4518 Zhlédnutí