Fórumok
Udv,
A linuxos ipsec-tools aka. RACOON ugye mar unmaintained lett, nem fejlesztik evek ota, es mar a patchelese is abbamaradt. Kb annyit irnak mindenhol, hogy hasznaljak mast helyette.
De mit? :) Mi szamit manapsag standard ipsec implementacionak linuxon?
Vannak a SWAN forkok, libreswan, openswan, strongswan, freeswan meg mittomenmilyenswanok. Eleg zavaros mi a kulonbseg koztuk, a licenszelesen kivul. Melyiket mennyire fejlesztik, supportaljak meg?
A'rpi
ps: nem, openvpn nem jo. meg mas vpn megoldas sem erdekel, mert mas cegek enterprise tuzfalaival kell ipsec-et beszelni, ebbe nincs beleszolasom.
Hozzászólások
Mondjuk StrongSwan-t. Tamogatott, fejlesztett, stabil, tobbet nem is nagyon akarhatnek. :)
Ha jót akarsz magadnak Strongswan. Openswan-t nem fejlesztik már. A Libreswan-t fejlesztik (sőt RHEL ben ez az alapértelmezett tippre a FIPS minősítés? miatt), de a kódbázisa nem egy leányálom (20 + év sitthalom, ez ugye a *swan ok egyenesági pluto démonjának továbbvitele). Nekem többször crashelt olyan ike csomag parser hibákkal, hogy ihaj. Mondjuk mióta Libreswan néven fut pucolják a kódot azért rendesen.. (fő fejlesztő RH alkalmazott). Ikev2 támogatása nem annyira kiforrott mint a Strongswané.
A Strongswan 5.x-nek a nevén kívül semmi köze a *swan-okhoz. Teljesen 0-ról újraírt implementáció (charon démon). Atom stabil. Több 100 s2s tunneles környezetekben használom, tucatnyi különböző ipsec vendorral a másik oldalon.
koszi!
Hm, ez sok mindent megmagyaraz. RHEL5-ben racoon volt, ment is stabilan. RHEL6-ban volt libreswan de folyton stabilitasi gondjaink voltak... Itt ugy "workaroundoltuk", hogy az ipsec terminalasra befogtunk egy pfsense instanceot (lovesem sincs, hogy abban mi van, de osszekattingatva mukodik azota is stabilan).
Pfsense-ben Strongswan van.
Subscribe.
Az a "több 100 s2s tunnel" nálad tunnel módú, vagy transport módú? (Nálam transport mód kell, GRE tunnelek vannak beágyazva)
Többségében tunnel, de vannak transport+gre felállások is.
Megírnád röviden mi a különbség köztük? Nem vagyok képben vele.
Nehéz ügy. Én vagy két évtizedig Racoon felhasználó voltam (már csak azért is, mert ugye *BSD preferenciám volt), de pár éve Linuxon át kellett állnom strongSwan-ra. Működget, de nem mondom, hogy jó pajtások vagyunk. A Racoon-nál hozzászoktam, hogy "setup and forget", míg a strongSwan-nál egy sima IKEv1 transport módú site-to-site konfiggal is heteket szoptam (dead peer detection, reconnection, rekeying, auto connect, stb.) mire 100% üzembiztos lett kezdve azzal, hogy az összes példa konfig a gyakorlatban szar.
Jelenleg ezzel működik tűrhetően stabilan:
- az egyik oldalon (nevezzük szervernek, bár egyenrangú)
- a másik oldalon (nevezzük kliensnek, bár egyenrangú)
biztato :)
en is vagy 15 eve racoon-t hasznalok, mondjuk dpd-vel es auto connecttel ott is voltak erdekes tapasztalataim (igaz a tulvegen mindig valami enterprise cucc volt, checkpoint, cisco stb), de egy folyamatos ping altalaban workaroundolta :)
s2s tunneleket érdemes mindkét oldalon auto=route-ra tenni. Ekkor a Strongswan installálja a kernelbe a trap policy-t és bármely csomag ami illeszkedik a policy-ra felszól az XFRM socketen keresztül a strongswan-nek, hogy indítson SA-t ha még nincsen. A dpdaction=hold vagy dpdaction=restart is ajánlott. A dpdaction=hold ugyanúgy installálja a kernel policy-t. A dpdaction=restart meg ha DPD miatt megáll az ipsec újratriggerel egy SA kérést. De sajnos ez sem segít néha :). Ekkor még érdemes a closeaction=restart-ot is beállítani. Ez akkor is új SA-t kér ha a másik oldal "normál okok miatt (tehét nem dead peer) törli az SA-t (pl egy delete SA üzenettel, de nem jön rekey meg semmi utána). És akkor még a keyingtries=%forever beállítást is említhetném.... :)
Sajnos az Ipsec nem triviális. És nem feltétlenül a Strongswan miatt. Inkompatibilis implementáció hegyek vannak. Érdemes ikev2-t használni mindenhol ahol csak lehet. Jelentősen stabilabb. Megoldottak egy csomó "out of state" problémát amire az ikev1-nél még nem gondoltak.
Egyébként megkeresem majd,de azt hiszem már van valami draft az ikev1 deprecated-é tételére (kb mint a TLS 1.0-nál).
A Strongswan doksija nem éppen acélos,de a test suite-ban lévő scenáriókat éredemes nézegetni. Mindenre IS van ott megoldás.
Ajánlott olvasmányok:
https://wiki.strongswan.org/projects/strongswan/wiki/Interoperability
Nagyon ajánlott, főleg ha nem szeretnénk clear text packet leaket ha nem épül fel az ipsec:
https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations
test suite:
https://www.strongswan.org/testresults.html
Ó igen, ikev1 deprecation draft (jegyzi RHEL Libreswan főcsővezető):
https://tools.ietf.org/id/draft-pwouters-ikev1-ipsec-graveyard-04.html
Még egy megjegyzés és abbahagyom a szófosást... :)
Érdemes tudni, hogy néhány ikev1 implementáció , leghíresebb pl a Cisco ASA egyszerűen nem rakta bele az ikev1 démonba az újabb algoritmusokat. Pl SHA256 MODP2048 stb...
Ezért aztán ASA-n ha normális crypto-t akarsz "kénytelen" vagy ikev2-t használni. Ikev1-el egyzserűen már csak "nem ajánlott" SHA1+MOD1536-ot tudsz beállítani. Az RFC8247-ben a modp1024 és modp1536 SHOULD NOT status-ban van.
ne hagyd abba, erdekes!
o igen a jo kis ASA-k, van par olyanhoz is "szerencsem" ami vagy 10+ eves es nagyon le van maradva minden tekintetben :)
:)
Vannak olyan IPSEC implementációk ahol nem mindegy a security proposal-ok sorrendje. Hajam hullott ki, amíg rájöttem egyszer, hogy hiába küldöm be a túloldalnak a megfelelő proposalt "is" (több másikkal egyetemben), csak akkor fog működni az IPSEC ha az ike proposalban a sorrendben az első proposalra van match. Ekkor jön a játék az ike=,esp= sorokkal a Strongswan-ban. Amúgy is érdemes leszűrni mert alapból elég sok algoritmus fel van sorolva a defaultban (ha nem adsz meg ike és esp sort).
Elképesztő egyébként ez a kupleráj az ike környékén. Képzeld el ugyanezt ilyen szinten mondjuk Tlsv1.2 implementációkkal. Tele lenne kürtölve az internet vele....
Vagy "secure by default" OpenBSD-ben lévő isakmpd ikev1 démon, ami bármilyen!! traffic selector-t elfogad a túloldaltól by default , a doksi erről nem tesz említést....
2017 óta nem javították leaglább doksi szintjén..... Igaz azt mondják használd az iked ikev2 démont inkább... :)
https://marc.info/?l=openbsd-misc&m=151175827013403&w=2
strongswan-ban meg lehet valahogy ertelmesen nezni, hogy a tuloldal mit kuld, mit szeretne? sok esetben nem azt allitjak be a tuloldalon amit megbeszelunk (vagy nem azt csinalja az eszkoz amit beallitanak neki, volt hogy pl. a beallitott lifetimeokat felulbiralta valami beepitett limit, vagy a beallitott cryptot nem tamogatta es csendben valami mast csinalt helyette), ilyenkor a racoon logbol debug modban ki lehetett azert nyomozni hogy megis mi a jo setting.
nagyon ugy erzem, hogy ez a racoon-rol atallas azert tobb lesz, mint par config filet atirni mas szintaxisra :) van egy par tucat s2s tunnel nalunk is.
Persze lehet. Subsystemenként (ike,net,mgr,enc) lehet állítani a logolást több szinten restart nélkül.
Olvasmányos legtöbbször. Mondjuk néha nem és meg kell nézni az ike RFC-t hogy mit akart a költő.... a kriptikus hibaüzenetek miatt... :)
kb hasonlókat lehet látni...
https://serverfault.com/questions/895354/strongswan-received-no-proposal-chosen-error-notify-while-connecting-to-cisco
Egyébként migráltam kb mindenről IS strongswanra meg le strongswan-ról, és meglepően könnyen ment. Nyilván nem árt némi ipsec sittes rutin hozzá....
Csak engem szopat azzal a strongSwan, hogy két s2s peer között néha egynél több SA jön fel? Többféle szkenárióban sikerült már belefutni, pl. dpd, vagy akár egy sima rekeying.
szerintem az tok normalis, legalabbis racoonnal mindig van atfedes, elobb huzza fel az ujat es csak utana torli a regit kis kesessel, hogy ami csomag a regi kulccsal jon azt is tudja meg dekodolni.
meg nekem van olyan s2s linkem is ahol 3 kulonbozo subnet megy ugyanabban a kapcsolatban, tehat 1 phase1 es 3 phase2 van. eleg mokas volt racoon-al osszehozni (asszem juniper a masik vege) :)
Nem az átfedésre gondolok, az normális. Arra gondolok, ami nem normális. :)
Pl. ha nem a "dpdaction=clear" beállítást használtam, hanem a minta konfigokban is előforduló többi variánst (pl. dpdaction=restart) - akkor, szakadás esetén a dpd is nyitott egy SA-t, meg az auto=route is, legalábbis, az volt a tünet, hogy szépen elkezdtek szaporodni az SA-k, egyes esetekben már akár 7-8 SA is volt egyidejűleg. Mivel utoljára kb. egy éve foglalkoztam ezzel, már nem nagyon emlékszem a részletekre...
De ez problémát is okozott vagy csak zavaró volt?
Egyébként a megoldás erre is az ikev2. Ott normális state management van sequence numberekkel meg ackolással....
Az ikev1 by design ilyen szar.
Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing loistics and shared state management. IKEv1 could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated . Work arounds (such as Dead-Peer-Detection) were developed but not standardized. This meant that different implementations of work-arounds were not always compatible.
Problémát okozott, konkrétan megállt a forgalom.
Értem, csak ~20 évig használtam IKEv1-et Racoon-nal, és semmi bajom nem volt vele.
Azt érdemes tudni hogy a Strongswan 5.x-ben a újraírták az ikev1 démont 0-ról. Előtte a Strongswan is a pluto-t használta. Az 5.x óta a charon démon viszi az ikev1 és ikev2-t is.
Az ikev1 az 5.0-5.2 környékén okozott furcsaságokat nekem is. Én kb 5-6 éve migráltam minden régi *swan (openswan,libreswan)-ról. Nem tapasztalok ilyen furcsaságokat. Illetve ha igen, ott legtöbbször a másik oldali implementáció szivat....
sub
idkozben lecsereltem a racoont, stringswan 5.9.2-re.
a site2site tunnelekkel nincs is gond. viszont az L2TP-nel ugy tunik, miutan a kliens lecsatlakozott (vagy leszakadt), a szerver meg probalja ujra felepiteni az ipsec kapcsolatot, es soha nem adja fel.
ez pl. mar tegnap ota connecting-be van, es a logba latszik, hogy folyton probal kuldeni arra az ip-re, de nem jon valasz:
L2TP-TK[11]: CONNECTING, 193.224.177.7[%any]...80.98.39.10[%any]
L2TP-TK[11]: IKEv1 SPIs: cee0ed42eacdaf38_i* 0000000000000000_r
L2TP-TK[11]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD
L2TP-TK{17}: INSTALLED, TRANSPORT, reqid 3, ESP in UDP SPIs: c1e26526_i 9523ffe8_o
L2TP-TK{17}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying active
L2TP-TK{17}: 193.224.177.7/32[udp/l2f] === 80.98.39.10/32[udp/l2f]
ipsec.conf:
mi kene meg neki, hogy ne erolkodjon foloslegesen?
auto=add
dpdaction=clear
... opciókkal nekem nem csinál ilyet. Biztos, hogy nincs semmi más szerveroldalon, ami kapcsolatot próbálna kezdeményezni?
nem hinnem, hogy lenne... foleg 1-2 nap utan? amugy szaporodnak, mar 5 van beakadva:
Security Associations (7 up, 5 connecting):
te milyen idoket adsz meg ikelifetime/keylife eseten L2TP-hez?
szerk: lehet ez okozza...? most lattam egy peldat ahol 1-re allitottak:
keyingtries=%forever
Nálam ez a konfig releváns része:
Ezres nagyságrendű (főként Windows 10-es) kliens nyúzza, a szimultán kapcsolatok száma 100-on belül szokott lenni. Alapjaiban véve, gondozásmentes.
keyingtries beállítás nálam csak site2site esetében van.
s2s tunnel mode vs. endpoint-to-site transport mód keveredés esete áll fenn, rosszul értem?
Nálam csak transport módú IPSec van, mert az s2s tunneleket transport módú IPSec-be csomagolt GRE-ben viszem.
Ok, ehhez már kevés vagyok :)
thx. kivettem a keyingtries-t, most jonak tunik :)
ha mar ennyi win kliensed van, nalatok nem jott elo az a problema, ha ugyanaz a public ip (NAT cim) mogul csatlakozik 2 win kliens? mondjuk 1 haztartasban vagy pl. 1 hotelben van 2 user, igy kifele ugyanazon ip-n es porton latszik...
es amugy xl2tpd-t hasznalsz vagy mast az l2tp-hez?
Van megoldás a több user ugyanaz a publikus IP aka same nat problémára....,de nem 100%-os
https://wiki.strongswan.org/projects/strongswan/wiki/Connmark
Mi az oka amúgy, hogy l2tp van még használatban, nem egyszerűbb Ikev2-re átállni, Windows 7 óta támogatott.
igen a connmark-osat megtalaltam en is, de az a githubos patch... az nagyon gaz :)
ikev2: hmm, koszi a tippet, megneztem, kiprobaltam win/mac alol, szerintem ez jo lesz. anno azert lett l2tp, mert azzal lehetett AD-bol user+pass hitelesiteni radiussal, es racoon-nal ugye ikev2 nem is volt opcio, az ikev1+xauth meg nem tul szabvanyos es elterjedt. legalabbis kb 10 eve, amikor ez be lett nalunk vezetve...
Még nem találtam jobbat az xl2tpd-nél sajnos, pedig nem IPv6 képes, és arra erősen volna igényem.
Ezt végig kell frissebb fejjel olvasnom...