IPSEC site-2-site VPN gyakori leállás (opnsense)
Van 1-1 db opnsense rúterem 2 site-on. A site-okon internet elérés dinamikus publikus IP-vel van (átkos PPPoE, minden reconnect után új IP-t kap). Azaz pont a legtávolabbi ellentéte az optmális static IP setup-nak, amit az ilyen service-k elvárnának. Dynamic DNS-t használok ezért, ha a rúterre WAN oldalról kell hivatkozni. Ki akartam húzni közöttük egy site-2-site VPN-t.
Valamiért úgy döntöttem, legyen IPSEC alapú a tunnel. Mert hát ugye szabványos az IPSEC, 20 éve van már windowsban beépített kliens, android is tudja out of the box, mi baj lehetne? Openvpn valahogy nem szimpatikus, SSL VPN-t amúgy sem tudja hw-ből gyorsítani szinte semmi, ezek meg gyenge CPU-n futnak.
Megnéztem pár videót YT-on ipsec-ről, mert az opnsense dokumentáció mint olyan nem létezik még ha elsőre azt is hiszed h. igen. Írnak valamit, de az egy nagy 0-t sem ér.
Ez pl. egész jó volt, elhittem neki h. TÉNLYEG érti miről beszél nem csak észnélkül felolvassa a másik által megírt slide-okat:
https://www.youtube.com/watch?v=ikSybz2e2RU
Amúgy dunát lehet rekeszteni az ipsec-ről hablatyoló kontárokból youtube-on, egyik borzasztóbb mint a másik, sok meló kiszűrni a tényleg profi előadókat
Viszont továbbra se biztos hogy minden tiszta ezekről:
ISAKMP, IKEv1, IKEv2, AH, ESP, tunnel mode, transport mode, main mode, aggressive mode, quick mode, Phase1, Phase2, cipher-eknél már opálosodik a szemem h. mi a különbség szimpla-AES-128bit / szimpla-AES-256bit /AES-GCM-128 / AES-CBC-128 között, és amit az egyik OS így hív, azt a másik meg amúgyan hívja, de a közösen beszélt low-level valódi cipher-listabeli megfelelőjét basznak ténylegesen odaírni a sor végére legalább apróbetűvel.
Szóval a tunnelt magát ez alapján csináltam meg:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
Szimpla policy-based ipsec VPN, mert a route-based ipsec VPN-t nem fogtam fel mire is jó nekem, és egyelőre ez a szimpla is elégnek tűnt. Cert helyett PSK-val állítottam be. Eleve trükkös a setup ha hiszel a guide-nak, mert a fenti szamárvezető azt írja, hogy mindkét tunnel endpoint oldalán a távoli network address-t kell megadni. Erre a példákban feszt is a RouterA és RouterB LAN IP-jét írták le: 192.168.1.1/24, 192.168.2.1/24 és nem pedig helyesen a network address-t ami 192.168.1.0/24 ill. 192.168.2.0/24. Nem világos mi a célja a My identifier / Peer identifier soroknak, azt is jól agyonmagyarázza a guide (hát nem!). Mert ha azt is fix-re kellene állítani, akkor adtam a szarnak egy pofont a dinamikus IP setup-ban!
Beállítás után elvileg felépül a tunnel. Aztán 1-2 nap után ledöglik. Többszöri IPSEC service és unbound DNS service restart megoldja. Unbound-ot a DDNS miatt kell restartolni ilyenkor, mert be-cacheli a remote public IP-t 24 órára (TTL override). Ha pedig épp IP-váltás volt a túloldalon, akkor nem fogja lekérdezni az aktuális public IP-t DDNS-en keresztül, mert az unbound local DNS cache-ben még ott van a régi, egy egészségesen nagy TTL-el.
Miután levettem az unobund DNS cache TTL-t 3600sec-re (mindkét oldalon kell, mert az anomália mindkét oldalon jelentkezik a jól ismert okokból), ideig óráig élt a tunnel. Aztán megint volt public IP váltás (vegyesen hol egyik hol másik oldalon), és utána már az unbound restart / cache űrítés sem segített. Akkor meg az IPSEC service restart kellett, látszólag mintha az SA-k beragadtak volna, hiába mutatott közben jó IP-re a DNS. Most itt állok, hogy ha sikerül a távoli opnsense-hez is hozzáférni (azaz fizikailag odamegyek, ugye ha ledöglik a tunnel, meg vagyok lőve a másik site-ról), és tudok ott is restartolni service-t akkor életre kell, ha épp annak az oldalnak volt baja a tunnel felállításakor.
Nem találtam a guide-ban 1 büdös szót sem arról, hogy ilyen dinamikus IP / DDNS felálláson is működőképes ez a Site-2-Site IPSEC tunnel setup? Persze mindenki a static rútolható IP-t szereti az oktatóanyagban, mert azzal van a legkevesebb melója gyorsan túl lehet rajta esni. Avagy minden egyes WAN IP váltáskor ledöglik és úgy is marad amíg a rúteren vki kézzel nem restartol service-eket? Mert ha magától nem tud helyreállni ilyen IP váltások után rövid idővel, akkor ez a megoldás kalap szart sem ér :(
- Tovább (IPSEC site-2-site VPN gyakori leállás (opnsense))
- 626 megtekintés