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.

> 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 ]---
> 
> 

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

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

válasz