Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: tomsoukup 28. 06. 2021, 09:34:20

Název: Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: tomsoukup 28. 06. 2021, 09:34:20
Zdravím,

prosím neřešil někdo problém, se kterým se právě potýkám a jsem bezradný?

dvě lokality 2x RB4011iGS+RM na straně 1 radiový spoj (místní provider) na straně 2 (DSL Vodafone)

Tunel je funkční vše běží, do doby než z jedné strany (DSL) přestanou fungovat služby, nelze se dostat na sdilené složky, nelze použít žádné webové rozhraní na straně 1 na žádném IP zařízení (NVR, NAS, TISKARNY atd.) v tomto stavu ping na daná zařízení odpovídá a nedochází ke ztrátám, ze strany 1 na stranu 2 vše funguje jak má, toto se děje prakticky každé ráno, pro obnovení stavu musím krátce vypnout a opětovně zapnout IPSEC tunel, pak vše běží opět do dalšího rána, avšak ani to nebývá pravidlem, někdy komunikace funguje 2 dny někdy je potřeba restartovat tunel 2x denně.

Díky za každé relevantní moudro.
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: madmucho 28. 06. 2021, 10:52:59
Dobrý den,
vypadá to že máte ipsec přpojen jen z jedné strany..

můžete poslat část konfigurace ipsec tunelu? Jestli je mod main nebo agresive, jestli je router za natem nebo přímo má na sobě veřejnou adresu.

Prosím také koukněte na stav ipsec tunelů a jejich P2 na obou stranách
Ve winboxu je to
IP > IPSEC > Policies nabídka, sloupec PH2 State by měl být na obou stranách established.

A také verzi Router OS a jestli je zapnutý Fast Path IP > Settings > Allow Fast Path ja jej raději na hlavním routeru vypinám dělá mi v logice bordel.
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: tomsoukup 28. 06. 2021, 11:43:45
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.
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: meldax 28. 06. 2021, 12:10:14
Tunel běží na 500 nebo 4500? Zkusil bych změnit. IPSec je docela citlivý na čas, je tam stejné NTP?
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: James_Scott 28. 06. 2021, 12:14:23
OT: vysrat se okamzite na celej ipsec a nasadit Wireguard. V situaci,kdy tam mate 2x vlastni Mikrotik tomu prece nic nebrani..
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: panpanika 28. 06. 2021, 12:55:41
OT: vysrat se okamzite na celej ipsec a nasadit Wireguard. V situaci,kdy tam mate 2x vlastni Mikrotik tomu prece nic nebrani..
wg je afaik jenom v bete ktera ma furt dost bolesti.

nasadil jsem linux virtualy jen na wg, co mi tam chybi je nejakej lidskej logging, ale mozna jsem jen blbe hledal, kdyztak me pls ponaucte.
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: tomsoukup 28. 06. 2021, 12:59:29
Wireguard fajn, ale jednak je jen v ROS 7 (zatím jedeme finální verze 6.x) a druhak bych rád stabilní řešení, který posadím i proti jiným standardním routerům, nejen Mikrotik - Cisco a pod., kde Wireguard nejspíš nikdy nebude.
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: tomsoukup 28. 06. 2021, 13:01:50
meldax: tunel jede na standard portech. Samozřejmě mohu zkusit i nonstandard, to jsem nezkoušel. Ale nejdřív večer
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: johanson14 28. 06. 2021, 14:30:18
Prečo 1492? Napríklad niektoré wifiny fragmentujú pri väčšom MTU ako 1472.
Název: Re:Mikrotik IPSEC tunnel site-to-site vypadává
Přispěvatel: madmucho 28. 06. 2021, 15:56:28
Zkuste tedy změnit mangle pravidlem velikost MSS, mam to tu takto stejně, já jsem ten problém (VDSL) a druhá strana je v pořádku.
U sebe mám mangle pravidlo s DST adresním rozsahem a akce je change MSS vypočteno 1338, zkuste podle sebe okoukat hodnotu pokud to bude fungovat.

add action=change-mss chain=postrouting comment="Max ramec pro xxx, vy\E8teno z \
    pingu bez fragmentace s max ramcem dokud to pingalo a ta hodnota minus 40 je\
    \_mss " dst-address=xxx.xxx.x.x/24 new-mss=1338 passthrough=yes protocol=\
    tcp tcp-flags=syn

To by mohlo pomoct.

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.