Vpnc, site-to-site
Salamon Attila
Sziasztok!
Site to site vpn-t próbálok összehozni egy Cisco ASA-val, pre shared
key segítségével. Jelenleg vpnc-vel próbálkozok, de csak a kapcsolat
egy részéig jutok.
Ami zavar a vpnc-ben, hogy pl. a no-xauth paramétert nem tudom hogyan
lehet beállítani neki, ezert az Xuath username és Xauth password
opciókat uresen hagyom.
Ez a jelenlegi konfig:
IPSec gateway xxx.xxx.xxx.xxx
IPSec ID xxx.xxx.xxx.xxy
IKE Authmode psk
IKE DH Group dh2
IPSec secret jelszo
Xauth username
Xauth password
NAT Traversal Mode cisco-udp
Perfect Forward Secrecy dh2
Debug 2
Cisco UDP Encapsulation Port 10000
IPSEC target network 10.x.x.0/24
DNSUpdate no
A vpnc-connect kimenete:
vpnc version 0.5.3
S1 init_sockaddr
[2009-11-24 18:43:37]
S2 make_socket
[2009-11-24 18:43:37]
S3 setup_tunnel
[2009-11-24 18:43:37]
using interface tun0
S4 do_phase1_am
[2009-11-24 18:43:37]
S4.1 create_nonce
[2009-11-24 18:43:37]
S4.2 dh setup
[2009-11-24 18:43:37]
S4.3 AM packet_1
[2009-11-24 18:43:37]
S4.4 AM_packet2
[2009-11-24 18:43:37]
(Cisco Unity)
(Xauth)
(DPD)
(unknown)
(unknown)
got ike lifetime attributes: 2147483 seconds
IKE SA selected psk-3des-sha1
peer is DPD capable (RFC3706)
S4.5 AM_packet3
[2009-11-24 18:43:37]
NAT status: no NAT-T VID seen
S4.6 cleanup
[2009-11-24 18:43:37]
S5 do_phase2_xauth
[2009-11-24 18:43:37]
S6 do_phase2_config
[2009-11-24 18:43:37]
S6.1 phase2_config send modecfg
[2009-11-24 18:43:37]
S6.2 phase2_config receive modecfg
[2009-11-24 18:43:37]
got ike lifetime attributes: 86400 seconds
vpnc-connect: no response from target
Merre induljak, mit állítsak vagy mit próbáljak a vpnc helyett?
Eddigi guglizásaim alapján arra jutottam, hogy a Cisco spéci módon
implementált dolgokat, ezért mással nem fog menni csak Cisco
klienssel vagy a vpnc-vel. A vpnc meg sokkal többet tud, ezért ezzel
próbálom.
--
Sala
_________________________________________________
linux lista - li...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Gabor HALASZ
Salamon Attila wrote:
> Sziasztok!
>
> Site to site vpn-t próbálok összehozni egy Cisco ASA-val, pre shared
> key segítségével. Jelenleg vpnc-vel próbálkozok, de csak a kapcsolat
> egy részéig jutok.
>
> Ami zavar a vpnc-ben, hogy pl. a no-xauth paramétert nem tudom hogyan
> lehet beállítani neki, ezert az Xuath username és Xauth password
> opciókat uresen hagyom.
Nem tudom, miert pont ez zavar benne :), de xauth-ot a szerveroldalon
kellene allitani, ha a szerver nem keri/ajanlja fel, akkor a kliensnek
sem kellene.
>
> Merre induljak, mit állítsak vagy mit próbáljak a vpnc helyett?
>
openswan, rosszabb esetben a kernelben levo ipsec.
> Eddigi guglizásaim alapján arra jutottam, hogy a Cisco spéci módon
> implementált dolgokat, ezért mással nem fog menni csak Cisco
> klienssel vagy a vpnc-vel. A vpnc meg sokkal többet tud, ezért ezzel
> próbálom.
Akkor kuglizd meg szepen a listaarchivumot, mar leirtam a varazslatot :)
A speci implementacio mindossze abbol all, hogy a linuxos vpn-ek mas
crypto beallitasokat hasznal defaultkent, mint a cisco:
ps
ike =
aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
esp = aes128-sha1,aes128-md5,3des-sha1,3des-md5
--
Gabor HALASZ <hala...@freemail.hu>
Salamon Attila
2009. november 25. dátummal Gabor HALASZ ezt írta:
> > Merre induljak, mit állítsak vagy mit próbáljak a vpnc helyett?
>
> openswan, rosszabb esetben a kernelben levo ipsec.
Próbálkozom az openswan-el.
> Akkor kuglizd meg szepen a listaarchivumot, mar leirtam a
> varazslatot :) A speci implementacio mindossze abbol all, hogy a
> linuxos vpn-ek mas crypto beallitasokat hasznal defaultkent, mint a
> cisco:
>
> ps
>
> ike =
> aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-
>md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3
>des-md5-modp1024 esp = aes128-sha1,aes128-md5,3des-sha1,3des-md5
Próbálkoztam ezzel az ike és esp beállítással is, amit küldtél, de
siker nélkül. Nem is értem, hogy ezt most példának szántad, vagy ezt
kellene használnom. Inkább az előzőre tippelek...
Tulajdonképpen ezt a Cisco configot kellene implementálnom:
crypto isakmp policy 20
encr 3des
authentication pre-share
group 2
crypto isakmp key mykey address 1.2.3.4 no-xauth
...
crypto map XX_MAP 20 ipsec-isakmp
set peer 1.2.3.4
set transform-set ESP_3DES_HMAC
set pfs group2
Ezzel az ESP_3DES_HMAC-al van a problémám, nem tudom mi felel meg
neki. Ezeket próbáltam: 3des-md5-96,3des-sha1-96,3des-sha1-modp1024,
de nem jöttek be.
Az
ike=3des-sha1
hatására valami történik:
pluto[11574]: "p1" #32: initiating Main Mode
pluto[11574]: "p1" #32: ignoring Vendor ID payload [FRAGMENTATION
c0000000]
pluto[11574]: "p1" #32: Can't authenticate: no preshared key found for
`4.3.2.1' and `1.2.3.4'. Attribute OAKLEY_AUTHENTICATION_METHOD
pluto[11574]: "p1" #32: no acceptable Oakley Transform
pluto[11574]: "p1" #32: sending notification NO_PROPOSAL_CHOSEN to
1.2.3.4:500
Ezt meg azért nem értem, mert a /etc/ipsec.secrets tartalmazza ezt a
sort:
4.3.2.1 1.2.3.4: PSK "jelszo"
Ez a jelenlegi config:
config setup
nat_traversal=yes
nhelpers=0
interfaces=%defaultroute
klipsdebug=all
plutodebug=all
conn p1
type= tunnel
auth= esp
authby= secret
leftid= 4.3.2.1
left= 4.3.2.1
leftnexthop= 4.3.2.2
leftsubnet= 10.yy.xx.0/16
rightid= 1.2.3.4
right= 1.2.3.4
rightsubnet= 10.zz.vv.0/24
ike= 3des-sha1-modp1024
esp= 3des-md5-96,3des-sha1-96,3des-sha1,3des-md5
keyexchange= ike
pfs= yes
pfsgroup= modp1024
auto= route
forceencaps= yes
Kérdéseim:
- A ciscos ESP_3DES_HMAC-nak mi az openswanes megfelelője?
- Mit bénázok el, hogy nem találja a psk-t? Lehet, hogy nem is a
psk-val van a baja?
--
Sala
Gabor HALASZ
Salamon Attila wrote:
>>
>> ike =
>> aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-
>> md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3
>> des-md5-modp1024 esp = aes128-sha1,aes128-md5,3des-sha1,3des-md5
>
> Próbálkoztam ezzel az ike és esp beállítással is, amit küldtél, de
> siker nélkül. Nem is értem, hogy ezt most példának szántad, vagy ezt
> kellene használnom. Inkább az előzőre tippelek...
Tevedtel. Ez mukodo konfigbol, a masik vegen cisco concentrator van, nem
keves tanakodas volt osszehozni, de eddig minden koncentratornal bevalt.
>
>
> Tulajdonképpen ezt a Cisco configot kellene implementálnom:
> crypto isakmp policy 20
> encr 3des
> authentication pre-share
> group 2
> crypto isakmp key mykey address 1.2.3.4 no-xauth
> ...
> crypto map XX_MAP 20 ipsec-isakmp
> set peer 1.2.3.4
> set transform-set ESP_3DES_HMAC
> set pfs group2
>
>
> Ezzel az ESP_3DES_HMAC-al van a problémám, nem tudom mi felel meg
> neki. Ezeket próbáltam: 3des-md5-96,3des-sha1-96,3des-sha1-modp1024,
> de nem jöttek be.
> Az
> ike=3des-sha1
> hatására valami történik:
Ha egysze esp, akkor miert az ike-t nezed? Es ha 3des-hmac, akkor miert
3des-sha1-el probalkozol?
>
> pluto[11574]: "p1" #32: initiating Main Mode
> pluto[11574]: "p1" #32: ignoring Vendor ID payload [FRAGMENTATION
> c0000000]
Nem nat-olsz te veletlenul?
> - A ciscos ESP_3DES_HMAC-nak mi az openswanes megfelelője?
esp=3des-hmac
> - Mit bénázok el, hogy nem találja a psk-t? Lehet, hogy nem is a
> psk-val van a baja?
Elkepzelheto, ranezesre jo, klipsdebug=yes es plutodebug=yes
mindenkeppen kellene a config setup-ba.
--
Gabor HALASZ <hala...@freemail.hu>
Salamon Attila
2009. november 26. dátummal Gabor HALASZ ezt írta:
> Tevedtel. Ez mukodo konfigbol, a masik vegen cisco concentrator
> van, nem keves tanakodas volt osszehozni, de eddig minden
> koncentratornal bevalt.
Most visszamásoltam az általad írt két sor (ike, esp). Itt az eredmény
(ua. mint a tegnapi):
pluto[11574]: "p1" #36: initiating Main Mode
pluto[11574]: "p1" #36: ignoring Vendor ID payload [FRAGMENTATION
c0000000]
pluto[11574]: "p1" #36: Can't authenticate: no preshared key found for
`4.3.2.1' and `1.2.3.4'. Attribute OAKLEY_AUTHENTICATION_METHOD
pluto[11574]: "p1" #36: no acceptable Oakley Transform
pluto[11574]: "p1" #36: sending notification NO_PROPOSAL_CHOSEN to
1.2.3.4:500
> > Ezzel az ESP_3DES_HMAC-al van a problémám, nem tudom mi felel meg
> > neki. Ezeket próbáltam:
> > 3des-md5-96,3des-sha1-96,3des-sha1-modp1024, de nem jöttek be.
> > Az
> > ike=3des-sha1
> > hatására valami történik:
>
> Ha egysze esp, akkor miert az ike-t nezed? Es ha 3des-hmac, akkor
> miert 3des-sha1-el probalkozol?
Próbálkoztam, nem jött össze. A vpnc meg ilyet írt:
IKE SA selected psk-3des-sha1
Ezért kezdtem el ezzel próbálkozni.
> > pluto[11574]: "p1" #32: initiating Main Mode
> > pluto[11574]: "p1" #32: ignoring Vendor ID payload [FRAGMENTATION
> > c0000000]
>
> Nem nat-olsz te veletlenul?
Nem.
> > - A ciscos ESP_3DES_HMAC-nak mi az openswanes megfelelője?
>
> esp=3des-hmac
Ezt én is próbáltam. Erre a válasz:
034 esp string error: hash_alg not found, enc_alg="3des",
auth_alg="hmac", modp=""
A man ipsec_spi szerint az AH-nál lehetnek ilyenek:
hmac-md5-96, hmac-sha1-96
Ezeknél eléggé elbizonytalanított az md5 és az sha1.
Ugyanebben a man-ban ez is olvasható:
3des-md5-96
encryption transform following the Triple-DES standard
in Cipher-Block-Chaining mode with au-
thentication provided by HMAC and MD5 (96-bit
authenticator), using a 64-bit iv (internally gen-
erated), a 192-bit 3DES ekey and a 128-bit HMAC-MD5 akey
(RFC2451, RFC2403)
és ugyanez a 3des-sha1-96-re.
Ezeket is próbáltam az esp-nél, siker nélkül.
> > - Mit bénázok el, hogy nem találja a psk-t? Lehet, hogy nem is a
> > psk-val van a baja?
>
> Elkepzelheto, ranezesre jo, klipsdebug=yes es plutodebug=yes
> mindenkeppen kellene a config setup-ba.
klipsdebug=all és plutodebug=all volt eddig is. Átírtam yes-re, de
semmi nem változott.
Amúgy én is keveseltem a logot, de az auth.log-on kívül máshol nem
találtam, abban meg ennyi van. Logol máshová is, csak nem látom?
Ha aggrmode=yes van a konfigban, akkor bőbeszédűbb
(ike=3des-sha1-modp1024 és esp=3des-sha1 kezdetekkel, mögöttük az
általad javasolt értékekkel):
pluto[11574]: "p1" #38: multiple transforms were set in aggressive
mode. Only first one used.
pluto[11574]: "p1" #38: transform (7,2,5,128) ignored.
pluto[11574]: "p1" #38: transform (7,2,2,128) ignored.
pluto[11574]: "p1" #38: transform (7,1,5,128) ignored.
pluto[11574]: "p1" #38: transform (7,1,2,128) ignored.
pluto[11574]: "p1" #38: transform (5,2,5,0) ignored.
pluto[11574]: "p1" #38: transform (5,1,5,0) ignored.
pluto[11574]: "p1" #38: transform (5,1,2,0) ignored.
pluto[11574]: "p1" #38: received Vendor ID payload [Cisco-Unity]
pluto[11574]: "p1" #38: received Vendor ID payload [XAUTH]
pluto[11574]: "p1" #38: received Vendor ID payload [Dead Peer
Detection]
pluto[11574]: "p1" #38: ignoring Vendor ID payload [FRAGMENTATION
c0000000]
pluto[11574]: "p1" #38: ignoring Vendor ID payload [Cisco VPN 3000
Series]pluto[11574]: "p1" #38: Aggressive mode peer ID is
ID_IPV4_ADDR: '1.2.3.4'
pluto[11574]: "p1" #38: Can't authenticate: no preshared key found for
`4.3.2.1' and `12.3.4'. Attribute OAKLEY_AUTHENTICATION_METHOD
pluto[11574]: "p1" #38: no acceptable Oakley Transform
pluto[11574]: "p1" #38: sending notification NO_PROPOSAL_CHOSEN to
1.2.3.4:500
Ha kiveszem az ike és az esp elejéről a 3des-sha1-eket, akkor a Vendor
ID sorok eltűnnek a logból.
Úgyhogy már kezdem nagyon nem érteni a dolgot...
--
Sala
Gabor HALASZ
Akkor 3des-hmac-md5 es 3des-hmac-sha1?
> A man ipsec_spi szerint az AH-nál lehetnek ilyenek:
> hmac-md5-96, hmac-sha1-96
> Ezeknél eléggé elbizonytalanított az md5 és az sha1.
>
Lehet mindketto egyszerre
>
>>> - Mit bénázok el, hogy nem találja a psk-t? Lehet, hogy nem is a
>>> psk-val van a baja?
>> Elkepzelheto, ranezesre jo, klipsdebug=yes es plutodebug=yes
>> mindenkeppen kellene a config setup-ba.
>
> klipsdebug=all és plutodebug=all volt eddig is. Átírtam yes-re, de
> semmi nem változott.
Bocs, az all a jo.
> Amúgy én is keveseltem a logot, de az auth.log-on kívül máshol nem
> találtam, abban meg ennyi van. Logol máshová is, csak nem látom?
Nem. Esetleg megprobalhatod kicserelni az ipsec stacket az openswan
felere a kernelben es ujraforditani, ehhez sajnos szokott kelleni egy
kis buveszkedes, de multkor irtam itt az aktualis varazslatot, de sajnos
az sem statikus megoldas.
>
>
> Ha aggrmode=yes van a konfigban, akkor bőbeszédűbb
> (ike=3des-sha1-modp1024 és esp=3des-sha1 kezdetekkel, mögöttük az
> általad javasolt értékekkel):
>
> pluto[11574]: "p1" #38: multiple transforms were set in aggressive
> mode. Only first one used.
> pluto[11574]: "p1" #38: transform (7,2,5,128) ignored.
> pluto[11574]: "p1" #38: transform (7,2,2,128) ignored.
> pluto[11574]: "p1" #38: transform (7,1,5,128) ignored.
> pluto[11574]: "p1" #38: transform (7,1,2,128) ignored.
> pluto[11574]: "p1" #38: transform (5,2,5,0) ignored.
> pluto[11574]: "p1" #38: transform (5,1,5,0) ignored.
> pluto[11574]: "p1" #38: transform (5,1,2,0) ignored.
Na itt kezdodik a szopas, mire ezeket a szamokat leforditja az ember
azokra, amiket az esp parameternel adtal meg.
> pluto[11574]: "p1" #38: received Vendor ID payload [Cisco-Unity]
> pluto[11574]: "p1" #38: received Vendor ID payload [XAUTH]
> pluto[11574]: "p1" #38: received Vendor ID payload [Dead Peer
> Detection]
> pluto[11574]: "p1" #38: ignoring Vendor ID payload [FRAGMENTATION
> c0000000]
> pluto[11574]: "p1" #38: ignoring Vendor ID payload [Cisco VPN 3000
> Series]pluto[11574]: "p1" #38: Aggressive mode peer ID is
> ID_IPV4_ADDR: '1.2.3.4'
> pluto[11574]: "p1" #38: Can't authenticate: no preshared key found for
> `4.3.2.1' and `12.3.4'. Attribute OAKLEY_AUTHENTICATION_METHOD
Jol latja ezt a szemem? 12.3.4? Kicsit keves ott pont, mintha valahol
elgepeltel volna egy address-t.
> pluto[11574]: "p1" #38: no acceptable Oakley Transform
> pluto[11574]: "p1" #38: sending notification NO_PROPOSAL_CHOSEN to
> 1.2.3.4:500'
pfs=yes, aggressive mode kikapcsolva (foleg a tuloldalon)?
>
>
> Ha kiveszem az ike és az esp elejéről a 3des-sha1-eket, akkor a Vendor
> ID sorok eltűnnek a logból.
> Úgyhogy már kezdem nagyon nem érteni a dolgot...
>
>
Amikor vendor id payload van, akkor magyarazza a tuloldal, hogy o mire
kepes, illetve mit szeretne, az esp valoszinuleg jo mar.
ike=3des-md5-modp1024,3des-sha1-modp1024 van most?
Az a fragmentation-os uzenet elegge nem szep, esetleg probald meg
bebillenteni a df flaget. mtu hogyan van, belefer az ipsec-kel novelt
header?
--
Gabor HALASZ <hala...@freemail.hu>
Salamon Attila
2009. november 26. dátummal Gabor HALASZ ezt írta:
> >>> - A ciscos ESP_3DES_HMAC-nak mi az openswanes megfelelője?
> >>
> >> esp=3des-hmac
> >
> > Ezt én is próbáltam. Erre a válasz:
> > 034 esp string error: hash_alg not found, enc_alg="3des",
> > auth_alg="hmac", modp=""
>
> Akkor 3des-hmac-md5 es 3des-hmac-sha1?
esp=3des-hmac-md5 és esp=3des-hmac-sha1 esetén is:
034 esp string error: Non initial digit found for auth keylen, just
after "3des-hmac-" (old_state=ST_AA_END)
A hiba alapján a végén számot vár, ezért próbálkoztam:
esp=3des-hmac-96, de erre ez jön:
034 esp string error: hash_alg not found, enc_alg="3des",
auth_alg="hmac", modp=""
Megpróbáltam ezt is:
esp=3des-hmac-modp1024, erre megint ez jött:
034 esp string error: Non initial digit found for auth keylen, just
after "3des-hmac-" (old_state=ST_AA_END)
> Nem. Esetleg megprobalhatod kicserelni az ipsec stacket az openswan
> felere a kernelben es ujraforditani, ehhez sajnos szokott kelleni
> egy kis buveszkedes, de multkor irtam itt az aktualis varazslatot,
> de sajnos az sem statikus megoldas.
Ez mit jelent? Ma jó, holnap nem biztos? Mert akkor nem erőlködök
vele.
> > Ha aggrmode=yes van a konfigban, akkor bőbeszédűbb
> > (ike=3des-sha1-modp1024 és esp=3des-sha1 kezdetekkel, mögöttük az
> > általad javasolt értékekkel):
> >
> > pluto[11574]: "p1" #38: multiple transforms were set in
> > aggressive mode. Only first one used.
> > pluto[11574]: "p1" #38: transform (7,2,5,128) ignored.
> > pluto[11574]: "p1" #38: transform (7,2,2,128) ignored.
> > pluto[11574]: "p1" #38: transform (7,1,5,128) ignored.
> > pluto[11574]: "p1" #38: transform (7,1,2,128) ignored.
> > pluto[11574]: "p1" #38: transform (5,2,5,0) ignored.
> > pluto[11574]: "p1" #38: transform (5,1,5,0) ignored.
> > pluto[11574]: "p1" #38: transform (5,1,2,0) ignored.
>
> Na itt kezdodik a szopas, mire ezeket a szamokat leforditja az
> ember azokra, amiket az esp parameternel adtal meg.
Itt nem egyszerűen az történik, hogy aggressive mode-ban csak az elsőt
veszi figyelembe, a többit sorban eldobja és figyelmeztet?
> > pluto[11574]: "p1" #38: Can't authenticate: no preshared key
> > found for `4.3.2.1' and `12.3.4'. Attribute
> > OAKLEY_AUTHENTICATION_METHOD
>
> Jol latja ezt a szemem? 12.3.4? Kicsit keves ott pont, mintha
> valahol elgepeltel volna egy address-t.
Igen elgépeltem a listára küldött, "cenzúrázott" ip-t. Ellenőriztem
még egyszer, a konfigban jól van.
> pfs=yes, aggressive mode kikapcsolva (foleg a tuloldalon)?
pfs=yes
pfsgroup=modp1024
volt eddig is. Itt kivettem az aggressive mode-ot, a túloldalt is
megkérem mindjárt.
> > Ha kiveszem az ike és az esp elejéről a 3des-sha1-eket, akkor a
> > Vendor ID sorok eltűnnek a logból.
> > Úgyhogy már kezdem nagyon nem érteni a dolgot...
>
> Amikor vendor id payload van, akkor magyarazza a tuloldal, hogy o
> mire kepes, illetve mit szeretne, az esp valoszinuleg jo mar.
>
> ike=3des-md5-modp1024,3des-sha1-modp1024 van most?
Jelenleg ilyen:
ike=3des-md5-modp1024,3des-sha1-modp1024,aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
esp=3des-md5,3des-sha1,aes128-sha1,aes128-md5
> Az a fragmentation-os uzenet elegge nem szep, esetleg probald meg
> bebillenteni a df flaget.
Hogyan tegyem? Úgy gondoltam kernel beállítás, de nem találom:
# sysctl -a 2>&1| grep -e frag -e df | grep ipv4
net.ipv4.ipfrag_high_thresh = 262144
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ipfrag_time = 30
net.ipv4.ipfrag_secret_interval = 600
net.ipv4.ipfrag_max_dist = 64
Openswan-ben sem találom hogyan kellene.
> mtu hogyan van, belefer az ipsec-kel
> novelt header?
mtu: 1500
--
Sala
Gabor HALASZ
Salamon Attila wrote:
> 2009. november 26. dátummal Gabor HALASZ ezt írta:
>>>>> - A ciscos ESP_3DES_HMAC-nak mi az openswanes megfelelője?
>>>> esp=3des-hmac
>>> Ezt én is próbáltam. Erre a válasz:
>>> 034 esp string error: hash_alg not found, enc_alg="3des",
>>> auth_alg="hmac", modp=""
>> Akkor 3des-hmac-md5 es 3des-hmac-sha1?
>
> esp=3des-hmac-md5 és esp=3des-hmac-sha1 esetén is:
> 034 esp string error: Non initial digit found for auth keylen, just
> after "3des-hmac-" (old_state=ST_AA_END)
>
> A hiba alapján a végén számot vár, ezért próbálkoztam:
> esp=3des-hmac-96, de erre ez jön:
> 034 esp string error: hash_alg not found, enc_alg="3des",
> auth_alg="hmac", modp=""
>
> Megpróbáltam ezt is:
> esp=3des-hmac-modp1024, erre megint ez jött:
> 034 esp string error: Non initial digit found for auth keylen, just
> after "3des-hmac-" (old_state=ST_AA_END)
>
Valami ciscos dokumentacio melyen megtalaltam egyszer a szamsorok
magyarazatat, de sajnos elvesztettem a linket.
>
>> Nem. Esetleg megprobalhatod kicserelni az ipsec stacket az openswan
>> felere a kernelben es ujraforditani, ehhez sajnos szokott kelleni
>> egy kis buveszkedes, de multkor irtam itt az aktualis varazslatot,
>> de sajnos az sem statikus megoldas.
>
> Ez mit jelent?
A kernek api/abi lenyegeben random valtozik, igy a 3rdparty kernel
fejlesztesek altalaban nem kovetik ezeket.
> Ma jó, holnap nem biztos?
Igen, ha ma le tudod forditani, akkor nem biztos, hogy holnap is.
> Mert akkor nem erőlködök
> vele.
Szerintem az egesz erolkodes folosleges, leven egy kis asa ~50k (ha
ciscos ember nem beszelt zoldeket), ami sokkal kulturaltabb eszkoz, mint
tso ganyolmanya a kernelben. Ha osszeszamolod a gep es az eltoltott ido
arat, mar most veszteseges a projekt.
>
>
>>> Ha aggrmode=yes van a konfigban, akkor bőbeszédűbb
>>> (ike=3des-sha1-modp1024 és esp=3des-sha1 kezdetekkel, mögöttük az
>>> általad javasolt értékekkel):
>>>
>>> pluto[11574]: "p1" #38: multiple transforms were set in
>>> aggressive mode. Only first one used.
>>> pluto[11574]: "p1" #38: transform (7,2,5,128) ignored.
>>> pluto[11574]: "p1" #38: transform (7,2,2,128) ignored.
>>> pluto[11574]: "p1" #38: transform (7,1,5,128) ignored.
>>> pluto[11574]: "p1" #38: transform (7,1,2,128) ignored.
>>> pluto[11574]: "p1" #38: transform (5,2,5,0) ignored.
>>> pluto[11574]: "p1" #38: transform (5,1,5,0) ignored.
>>> pluto[11574]: "p1" #38: transform (5,1,2,0) ignored.
>> Na itt kezdodik a szopas, mire ezeket a szamokat leforditja az
>> ember azokra, amiket az esp parameternel adtal meg.
>
> Itt nem egyszerűen az történik, hogy aggressive mode-ban csak az elsőt
> veszi figyelembe, a többit sorban eldobja és figyelmeztet?
>
Vagy-vagy, ezert nem jo az aggressive mode, de nem tudom fejbol az
osszes uzenetet.
>
>>> pluto[11574]: "p1" #38: Can't authenticate: no preshared key
>>> found for `4.3.2.1' and `12.3.4'. Attribute
>>> OAKLEY_AUTHENTICATION_METHOD
>> Jol latja ezt a szemem? 12.3.4? Kicsit keves ott pont, mintha
>> valahol elgepeltel volna egy address-t.
>
> Igen elgépeltem a listára küldött, "cenzúrázott" ip-t. Ellenőriztem
> még egyszer, a konfigban jól van.
>
Ok.
>
>
>> pfs=yes, aggressive mode kikapcsolva (foleg a tuloldalon)?
>
> pfs=yes
> pfsgroup=modp1024
>
> volt eddig is. Itt kivettem az aggressive mode-ot, a túloldalt is
> megkérem mindjárt.
>
Ha a tuloldal aggressiv, akkor szerintem te hiaba kapcsolod ki.
>
>>> Ha kiveszem az ike és az esp elejéről a 3des-sha1-eket, akkor a
>>> Vendor ID sorok eltűnnek a logból.
>>> Úgyhogy már kezdem nagyon nem érteni a dolgot...
>> Amikor vendor id payload van, akkor magyarazza a tuloldal, hogy o
>> mire kepes, illetve mit szeretne, az esp valoszinuleg jo mar.
>>
>> ike=3des-md5-modp1024,3des-sha1-modp1024 van most?
>
> Jelenleg ilyen:
> ike=3des-md5-modp1024,3des-sha1-modp1024,aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
> esp=3des-md5,3des-sha1,aes128-sha1,aes128-md5
>
>
>> Az a fragmentation-os uzenet elegge nem szep, esetleg probald meg
>> bebillenteni a df flaget.
>
> Hogyan tegyem? Úgy gondoltam kernel beállítás, de nem találom:
>
> # sysctl -a 2>&1| grep -e frag -e df | grep ipv4
> net.ipv4.ipfrag_high_thresh = 262144
> net.ipv4.ipfrag_low_thresh = 196608
> net.ipv4.ipfrag_time = 30
> net.ipv4.ipfrag_secret_interval = 600
> net.ipv4.ipfrag_max_dist = 64
Regen volt ilyen, de ha jol latom, ez is megszunt.
>
> Openswan-ben sem találom hogyan kellene.
>
Ott biztosan nincs.
>
>> mtu hogyan van, belefer az ipsec-kel
>> novelt header?
>
> mtu: 1500
>
>
Ezt kellene allitani, ha a ket gep kozotti vonalnak kisebb az mtu-ja.
Allitsd be a ip_no_pmtu_disc-et, akkor biztosan at fognak ferni a
csomagok, csak ne hagyd ugy, mert akkor 552 lesz az mtu.
--
Gabor HALASZ <hala...@freemail.hu>
Salamon Attila
Beállítottam, meg ifconfiggal az mtu-t is 552-re, mert az nem lett
kisebb.
Ugyanúgy maradt az "ignoring Vendor ID payload [FRAGMENTATION
c0000000]".
A tcpdump alapján úgy tűnik nálam be is van billentve a df flag, a
túloldalon viszont nincs:
14:49:35.675208 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 484) 4.3.2.1.500 > 1.2.3.4.500: isakmp 1.0 msgid :
phase 1 I ident: [|sa]
14:49:35.676908 IP (tos 0x0, ttl 247, id 15688, offset 0, flags
[none], proto UDP (17), length 132) 1.2.3.4.500 > 4.3.2.1.500: isakmp
1.0 msgid : phase 1 R ident: [|sa]
14:49:35.677136 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 68) 4.3.2.1.500 > 1.2.3.4.500: isakmp 1.0 msgid :
phase 1 I inf:
(n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN)
Más ike és esp beállításokkal érdemes túlórázni (mindkét oldalon)?
--
Sala
Gabor HALASZ
Salamon Attila wrote:
> 2009. november 26. dátummal Gabor HALASZ ezt írta:
>> Ezt kellene allitani, ha a ket gep kozotti vonalnak kisebb az
>> mtu-ja. Allitsd be a ip_no_pmtu_disc-et, akkor biztosan at fognak
>> ferni a csomagok, csak ne hagyd ugy, mert akkor 552 lesz az mtu.
>
> Beállítottam, meg ifconfiggal az mtu-t is 552-re, mert az nem lett
> kisebb.
Amennyiben az ip_no_pmtu_disc-et bekapcsolod, es nem csokken a packet
meret, az ordenare nagy bug (nem mellekesen rfc irja elo)
>
> Ugyanúgy maradt az "ignoring Vendor ID payload [FRAGMENTATION
> c0000000]".
>
> A tcpdump alapján úgy tűnik nálam be is van billentve a df flag, a
> túloldalon viszont nincs:
>
A kikapcsolt df az uzemszeru allapot, altalaban addig kapcsoljak be,
amig pmtu discovery tortenik.
> 14:49:35.675208 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 484) 4.3.2.1.500 > 1.2.3.4.500: isakmp 1.0 msgid :
> phase 1 I ident: [|sa]
> 14:49:35.676908 IP (tos 0x0, ttl 247, id 15688, offset 0, flags
> [none], proto UDP (17), length 132) 1.2.3.4.500 > 4.3.2.1.500: isakmp
> 1.0 msgid : phase 1 R ident: [|sa]
> 14:49:35.677136 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 68) 4.3.2.1.500 > 1.2.3.4.500: isakmp 1.0 msgid :
> phase 1 I inf:
> (n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN)
>
>
> Más ike és esp beállításokkal érdemes túlórázni (mindkét oldalon)?
>
>
Altalaban az a problema, hogy uzemelo koncentratorhoz kell kapcsolodni,
amit nem nagyon lehet konfiguralni.
Ami fura, visszaterve a kiindulasi ponthoz, hogy mar a masodik ipsec nem
megy...Tudod mindket oldal forglamat monitorozni?
--
Gabor HALASZ <hala...@freemail.hu>
Gabor HALASZ
Belepillantottam az original konfigba:
NAT Traversal Mode cisco-udp
Perfect Forward Secrecy dh2
Debug 2
Cisco UDP Encapsulation Port 10000
Egyreszt itt van natt, amire te azt mondtad, hogy nincs, masreszt ez
nem nativ ipsec, ha igaz ez a konfig.
--
Gabor HALASZ <hala...@freemail.hu>
Salamon Attila
2009. november 26. dátummal Gabor HALASZ ezt írta:
>
> NAT Traversal Mode cisco-udp
> Perfect Forward Secrecy dh2
> Debug 2
> Cisco UDP Encapsulation Port 10000
>
> Egyreszt itt van natt, amire te azt mondtad, hogy nincs, masreszt
> ez nem nativ ipsec, ha igaz ez a konfig.
Először valóban nat mögül próbálkoztam, akkor került bele a konfigba a
nat sor. Aztán túl sok volt a hibatényező, ezért most másik helyről
próbálom, ahol nincs nat.
A vpnc ugyanúgy eljut a phase1 végéig, ha
"NAT Traversal Mode none" van a konfigban.
Az UDP Encapsulation meg csak natt esetén releváns.
Ez a sor
Perfect Forward Secrecy dh2
ha jól értelmezem megfelel ennek a kettőnek:
pfs=yes
pfsgroup=modp1024
modp1024==Diffie-Hellman group 2
--
Sala
Gabor HALASZ
Salamon Attila wrote:
> Az UDP Encapsulation meg csak natt esetén releváns.
Ez a 10k-n futo encapsulation-nak szerintem nincs koze a esp-udp-hez (az
a 4500-at hasznalja), ez cisco specifikus szorakozas azon
felhasznaloknak, akik mindenfele lehetetlen halozaton kenytelenek vpn-t
csinalni, amin nem megy at a nativ ipsec.
--
Gabor HALASZ <hala...@freemail.hu>
Gabor HALASZ
>
Pedig jo lenne nezni a tuloldali forgalmat, nem valami nyakatekert
halozati hiba okozza-e a nyavajadat.
Salamon Attila
2009. november 26. dátummal Gabor HALASZ ezt írta:
> Ami fura, visszaterve a kiindulasi ponthoz, hogy mar a masodik
> ipsec nem megy...Tudod mindket oldal forglamat monitorozni?
Az ASA-t nem. Linux oldalt természetesen.
--
Sala
Salamon Attila
2009. november 26. dátummal Gabor HALASZ ezt írta:
> > Az UDP Encapsulation meg csak natt esetén releváns.
>
> Ez a 10k-n futo encapsulation-nak szerintem nincs koze a
> esp-udp-hez (az a 4500-at hasznalja), ez cisco specifikus
> szorakozas azon
> felhasznaloknak, akik mindenfele lehetetlen halozaton kenytelenek
> vpn-t csinalni, amin nem megy at a nativ ipsec.
Nem magamtól találtam ki. :-)
man vpnc:
--udp-port <0-65535>
Local UDP port number to use (0 == use random port).
This is only relevant if cisco-udp
nat-traversal is used. This is the _local_ port, the remote
udp port is discovered automati-
cally. It is especially not the cisco-tcp port.
Default: 10000
conf-variable: Cisco UDP Encapsulation Port <0-65535>
Közben történtek dolgok
egy /etc/init.d/ipsec stop után kiadott start csúnya kernel
oops-ot okozott. Jobbnak láttam újraindítani a szervert, abba
meg "belefagyott". Power off-on lett a vége. Szokása ez az
openswan-nek? 2.6.26-2-amd64 gyári debian kernellel próbálom.
Közben mégegszer elkövettem ezt a hibát. Úgy tűnt, hogy az "ipsec
auto --rereadall" hatására nem olvasta újra az egész konfigot,
az "ipsec auto --status" legalábbis még az előző debug értékeket
mutatta. Ezután ipsec stop, start következett és egy szép kernel
trace.
Felment a load 5-re, nem tudom kilőni a következő processeket:
# ps -ef | grep ipsec
root 7008 1 0 12:31 ? 00:00:00 grep -v
NULL /proc/net/ipsec_tncfg
root 7055 1 0 12:35 ? 00:00:00 grep -v
NULL /proc/net/ipsec_tncfg
root 7092 1 0 12:38 ?
00:00:00 /bin/sh /usr/lib/ipsec/_realsetup --status
Tudtok valami megoldást? Nem merem újraindítani, nehogy megint
megálljon az egész. (200 km-re van a gép)
Beidézem a kernel trace logot is:
Nov 27 12:30:26 gepnev kernel: [15259.714619] klips_info:ipsec_init:
KLIPS startup, Openswan KLIPS IPsec stack version: 2.4.12
Nov 27 12:30:26 gepnev kernel: [15259.714619] NET: Registered protocol
family 15
Nov 27 12:30:26 gepnev kernel: [15259.714619]
klips_info:ipsec_alg_init: KLIPS alg v=0.8.1-0 (EALG_MAX=255,
AALG_MAX=251)
Nov 27 12:30:26 gepnev kernel: [15259.714619]
klips_info:ipsec_alg_init: calling ipsec_alg_static_init()
Nov 27 12:30:26 gepnev kernel: [15259.714619]
ipsec_aes_init(alg_type=15 alg_id=12 name=aes): ret=0
Nov 27 12:30:26 gepnev kernel: [15259.714619]
ipsec_3des_init(alg_type=15 alg_id=3 name=3des): ret=0
Nov 27 12:30:26 gepnev kernel: [15259.724537] PGD 203067 PUD 207063
PMD 115063067 PTE 0
Nov 27 12:30:26 gepnev kernel: [15259.724537] CPU 1
Nov 27 12:30:26 gepnev kernel: [15259.724537] Modules linked in: ipv6
tunnel4 ipcomp esp4 aead ah4 xt_hashlimit iptable_raw xt_comment
xt_owner xt_iprange xt_policy xt_multiport ipt_ULOG ipt_TTL ipt_ttl
ipt_REJECT ipt_REDIRECT ipt_recent ipt_NETMAP ipt_MASQUERADE ipt_LOG
ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_amanda nf_conntrack_tftp nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netbios_ns nf_conntrack_irc
ts_kmp nf_conntrack_amanda xt_tcpmss xt_pkttype xt_physdev xt_NFQUEUE
xt_MARK xt_mark xt_mac xt_limit xt_length xt_helper xt_dccp
xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state
iptable_nat iptable_mangle nfnetlink iptable_filter ip_tables
x_tables deflate zlib_deflate zlib_inflate ctr twofish twofish_common
camellia serpent blowfish des_generic cbc aes_x86_64 aes_generic xcbc
sha256_generic sha1_generic crypto_null crypto_blkcipher dm_snapshot
dm_mirror dm_log dm_mod nf_nat_ftp nf_nat nf_conntr
Nov 27 12:30:26 gepnev kernel: ck_ipv4 nf_conntrack_ftp nf_conntrack
loop i2c_i801 parport_pc snd_hda_intel i2c_core parport snd_pcm
pcspkr snd_timer snd soundcore snd_page_alloc button intel_agp evdev
ext3 jbd mbcache raid1 md_mod sd_mod ide_cd_mod cdrom ata_piix
jmicron ata_generic r8169 ide_pci_generic ahci ehci_hcd ide_core
libata scsi_mod dock uhci_hcd thermal processor fan thermal_sys [last
unloaded: xfrm_user]
Nov 27 12:30:26 gepnev kernel: [15259.724537] Pid: 6929, comm:
_startklips Not tainted 2.6.26-2-amd64 #1
Nov 27 12:30:26 gepnev kernel: [15259.724537] RIP: 0010:
[<ffffffff802d4e87>] [<ffffffff802d4e87>] proc_get_inode+0x1c/0x127
Nov 27 12:30:26 gepnev kernel: [15259.724537] RSP:
0018:ffff81010b16fbb8 EFLAGS: 00010246
Nov 27 12:30:26 gepnev kernel: [15259.724537] RAX: 0000000000000001
RBX: 0000000000000000 RCX: 0000000000000000
Nov 27 12:30:26 gepnev kernel: [15259.724537] RDX: ffffffffa0449980
RSI: 00000000f0000197 RDI: ffff81011fa45000
Nov 27 12:30:26 gepnev kernel: [15259.724537] RBP: ffff810115cfc7c0
R08: ffff81010b16fc98 R09: ffff8101169a2150
Nov 27 12:30:26 gepnev kernel: [15259.724537] R10: 0000000000000000
R11: ffffffff802f32a1 R12: ffff8100d41d4a40
Nov 27 12:30:26 gepnev kernel: [15259.724537] R13: ffff810116804338
R14: ffff81010b16fe48 R15: ffff81010b16fc98
Nov 27 12:30:26 gepnev kernel: [15259.724537] FS: 00007f6e114296e0
(0000) GS:ffff81011fa7c8c0(0000) knlGS:0000000000000000
Nov 27 12:30:26 gepnev kernel: [15259.724537] CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
Nov 27 12:30:26 gepnev kernel: [15259.724537] CR2: ffffffffa0449980
CR3: 000000011d506000 CR4: 00000000000006e0
Nov 27 12:30:26 gepnev kernel: [15259.724537] DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
Nov 27 12:30:26 gepnev kernel: [15259.724537] DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 27 12:30:26 gepnev kernel: [15259.724537] Process _startklips
(pid: 6929, threadinfo ffff81010b16e000, task ffff81011f12b470)
Nov 27 12:30:26 gepnev kernel: [15259.728050] Stack: fffffffffffffffe
00000000f0000197 ffff810115cfc7c0 ffffffff802d9121
Nov 27 12:30:26 gepnev kernel: [15259.728050] ffff81010b16fc98
ffff8100d41d4a40 ffff8100d41d4080 ffff810116804338
Nov 27 12:30:26 gepnev kernel: [15259.728050] ffff8101168043f0
ffffffff802a1d76 ffff81011680c9e8 ffff81010b16fca8
Nov 27 12:30:26 gepnev kernel: [15259.728050] Call Trace:
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802d9121>] ?
proc_lookup_de+0x89/0xd1
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a1d76>] ?
do_lookup+0xd7/0x1c1
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a3ed9>] ?
__link_path_walk+0x87a/0xd05
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff80238bd9>] ?
current_fs_time+0x1e/0x24
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802b0aef>] ?
mnt_want_write+0x2d/0x6e
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a4118>] ?
__link_path_walk+0xab9/0xd05
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a43aa>] ?
path_walk+0x46/0x8b
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a46d6>] ?
do_path_lookup+0x158/0x1cf
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a34e1>] ?
getname+0x140/0x1a7
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff802a5045>] ?
__user_walk_fd+0x37/0x4c
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8029e15d>] ?
vfs_stat_fd+0x1b/0x4a
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff80246201>] ?
autoremove_wake_function+0x0/0x2e
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff80237587>] ?
do_wait+0x968/0x9f8
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff80221fbc>] ?
do_page_fault+0x5d8/0x9c8
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8029e1e8>] ?
sys_newstat+0x19/0x31
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8029b688>] ?
vfs_read+0x11e/0x152
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8031e0a7>] ?
__up_read+0x13/0x8a
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8023fa1c>] ?
sys_rt_sigprocmask+0xba/0xd3
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8042a6a9>] ?
error_exit+0x0/0x60
Nov 27 12:30:26 gepnev kernel: [15259.728050] [<ffffffff8020beca>] ?
system_call_after_swapgs+0x8a/0x8f
Nov 27 12:30:26 gepnev kernel: [15259.728050]
Nov 27 12:30:26 gepnev kernel: [15259.728050]
Nov 27 12:30:26 gepnev kernel: [15259.728050] RSP <ffff81010b16fbb8>
Nov 27 12:30:26 gepnev kernel: [15259.728050] ---[ end trace
6761efeb7cc7a699 ]---
--
Sala
Gabor HALASZ
Salamon Attila wrote:
> 2009. november 26. dátummal Gabor HALASZ ezt írta:
>> Salamon Attila wrote:
>>> Az UDP Encapsulation meg csak natt esetén releváns.
>> Ez a 10k-n futo encapsulation-nak szerintem nincs koze a
>> esp-udp-hez (az a 4500-at hasznalja), ez cisco specifikus
>> szorakozas azon
>> felhasznaloknak, akik mindenfele lehetetlen halozaton kenytelenek
>> vpn-t csinalni, amin nem megy at a nativ ipsec.
>
> Nem magamtól találtam ki. :-)
> man vpnc:
> --udp-port <0-65535>
> Local UDP port number to use (0 == use random port).
> This is only relevant if cisco-udp
> nat-traversal is used. This is the _local_ port, the remote
> udp port is discovered automati-
> cally. It is especially not the cisco-tcp port.
> Default: 10000
> conf-variable: Cisco UDP Encapsulation Port <0-65535>
>
Ah, ezzel a varazslattal meg nem talalkoztam, altalaban a tcp10k-ra
akasztjak a ciscosok az egeszet, ha nem megy nativan.
>
>
> Közben történtek dolgok
>
> egy /etc/init.d/ipsec stop után kiadott start csúnya kernel
> oops-ot okozott. Jobbnak láttam újraindítani a szervert, abba
> meg "belefagyott". Power off-on lett a vége. Szokása ez az
> openswan-nek?
Nem, jopar openswan-os gepem van, ami evek ota teszi a dolgat megallas
nelkul.
Valasszuk ket reszre: neked nem az openswan-nal van bajod, hanem a linux
kernellel, amiben nem az openswan fele stack van, hanem egy ganyolmany.
Az openswan csak a kulccseret vegzi a userlandben, az ipsec kodolast a
kernelben levo ipsec stack csinalja.
Nalad tobb rendbeli gondok lehetnek:
1. a debianban levo fene tudja mikori es hogyan osszepatkolt openswan
2. a debianban levo fene tudja mivel es hogyhan osszepatkolt kernel
3. maga a linux kernel.
4. sok egyebb
En ezt tennem:
1. 2.6.27.utolso kernelt forrasbol
2. openswan stacket beletenni
3. mindent kikapcsolni, amire nem lesz szukseg
4. udevet es tarsait kinyirni, vagy legalabb ne toltson be minden .ko
kiterjeszesu filet, amit a gepen talal
5. openswant forrasbol telepiteni
> 2.6.26-2-amd64 gyári debian kernellel próbálom.
Ez ilyesmit azonnal elfelejtenem. Eleg formedveny allpotban van a kernel
anelkul is, hogy mindenfele felkegyelmu osszepiszkitana. Egyaltalan,
miert pont a 26-os van benne? A codefreeze napjan az volt aktualis? ;)
>
>
> Közben mégegszer elkövettem ezt a hibát. Úgy tűnt, hogy az "ipsec
> auto --rereadall" hatására nem olvasta újra az egész konfigot,
> az "ipsec auto --status" legalábbis még az előző debug értékeket
> mutatta. Ezután ipsec stop, start következett és egy szép kernel
> trace.
>
> Felment a load 5-re, nem tudom kilőni a következő processeket:
> # ps -ef | grep ipsec
> root 7008 1 0 12:31 ? 00:00:00 grep -v
> NULL /proc/net/ipsec_tncfg
> root 7055 1 0 12:35 ? 00:00:00 grep -v
> NULL /proc/net/ipsec_tncfg
> root 7092 1 0 12:38 ?
> 00:00:00 /bin/sh /usr/lib/ipsec/_realsetup --status
>
>
> Tudtok valami megoldást? Nem merem újraindítani, nehogy megint
> megálljon az egész. (200 km-re van a gép)
HA a proc interface olvasgatasa ekkora galibat okoz, akkor mar regen
mindegy, ne a kodolasok egyeztetesen tord a fejed.
>
>
> Beidézem a kernel trace logot is:
> Nov 27 12:30:26 gepnev kernel: [15259.714619] klips_info:ipsec_init:
> KLIPS startup, Openswan KLIPS IPsec stack version: 2.4.12
> Nov 27 12:30:26 gepnev kernel: [15259.714619] NET: Registered protocol
> family 15
> Nov 27 12:30:26 gepnev kernel: [15259.714619]
> klips_info:ipsec_alg_init: KLIPS alg v=0.8.1-0 (EALG_MAX=255,
> AALG_MAX=251)
> Nov 27 12:30:26 gepnev kernel: [15259.714619]
> klips_info:ipsec_alg_init: calling ipsec_alg_static_init()
> Nov 27 12:30:26 gepnev kernel: [15259.714619]
> ipsec_aes_init(alg_type=15 alg_id=12 name=aes): ret=0
> Nov 27 12:30:26 gepnev kernel: [15259.714619]
> ipsec_3des_init(alg_type=15 alg_id=3 name=3des): ret=0
> Nov 27 12:30:26 gepnev kernel: [15259.724537] PGD 203067 PUD 207063
> PMD 115063067 PTE 0
> Nov 27 12:30:26 gepnev kernel: [15259.724537] CPU 1
> Nov 27 12:30:26 gepnev kernel: [15259.724537] Modules linked in: ipv6
Az ipv6 csak biztonsagi es uzemeltetesi kockazat, szinte minden ipv6
stack bugos (nem csak linuxon), ertelme vagy haszna nincsen; nyugodtan
kapcsold ki.
Ez a kernelben levo ipsec stack, ugye? Sima kernelbug, meghozza eleg
randa (proc_get_inode+0x1c/0x127). Vagy probald meg vanilla kernellel (a
2.6.27 ag hasznalhato valamennyire) es patkold bele az openswan stacket,
vagy hasznald a vpnc-t, ahhoz nem kell kernel support, de nem tudok
benne segiteni. Mondjuk eddig sem sokat :)
--
Gabor HALASZ <hala...@freemail.hu>