( ggallo | 2020. 11. 20., p – 20:33 )

Igazából itt (ha szabad ezt mondanom) mi vagyunk a hülyék. Az IPsec alapjában véve ismert fix IP címekre van kitalálva, meg mellé van technológiája "road warrior" kliensek fogadására, amiknek akár dinamikus címük is lehet, és így dinamikusan jön létre a megfelelő peer, stb. Mi meg nem szerver-kliens, hanem telephelyek közötti kapcsolatot gyártunk (ami alapból fix címeket igényelne) úgy, hogy egyik oldalnak sem statikus a címe (plusz a PPPoE miatt még átfutási ideje is van a kapcsolat újra épülésének session bontás után)... Szóval mi használjuk rosszul az egyébként jó eszközt véleményem szerint.

Az IKEv2 ezen (is) javított sokat (abban sokkal jobban működik a nem cím, hanem FQDN alapú kapcsolódás, mert hivatalosan támogatott lett - én is ezt használom a megoldásomban), de az sincs felkészítve a menet közbeni cím változásra. Na persze lehet olyan rövid phase1 és phase2 időket adni, hogy aránylag gyorsan helyreálljon, de az aránytalanul sokszor fogja megszakítani a kapcsolatot, ami akár érezhető lesz az átvitelben is.

Az OpenVPN-nek nem véletlenül a mai napig egyik kiemelt képessége a bármelyik oldalon változó IP cím tűrése, és a Mikrotik közösség nem véletlenül kéri emiatt évek óta, hogy az OpenVPN megvalósítás is tudja használni a sok MT eszközben meglévő HW AES gyorsítást.

Script kérdésedre válaszolva a Mikrotik-re is kell script ugyan arra, amire az OPNsense esetén. Az ugyan úgy nem kezeli ezt a helyzetet jó, ugyan azért amiért az OPNsense is. Az Edgerouter-re pedig a minta alapján Neked kell majd a megoldást szülni (ha lehetséges rá egyáltalán). Én nem szeretem az UBNT router-eket, mert mindenhez képest nagyon macerás (számomra) a konfigurációjuk és rettentő csapnivaló ezen felül a doksija (szintén: szerintem).

Nekünk Mikrotik hEX (RB750Gr3) túloldallal megy 200-220 Mbit az IPsec tunnel-en (a nap bizonyos szakaszaiban, mikor bírja a Digi) az 1000/300-as Digi PPPoE kapcsolatokon.