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