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 <[email protected]>

_________________________________________________
linux lista      -      [email protected]
http://mlf2.linux.rulez.org/mailman/listinfo/linux

válasz