[Techinfo] ipsec server linuxon

2017. Aug. 28., H, 14:49:43 CEST

A hétvégén kicsit többet foglalkoztam e témával és valóban az van, hogy 
nem láttam a "fától az erdőt".
A hibaüzenet normális, nem is kell felhúzni a kapcsolatot a 
strongswannál a ipsec up <kapcsolat neve> paranccsal.
Ezt automatikusan teszi a program, ha "auto=add" beleteszted a 
konfigurációs rész conn metódus alá.
auto=start esetén is jó, így is csatlakozik a kliens/kliensek.

Amiatt kalapáltam össze ezt a vpn megoldást, mert:
- tartoztam magamnak ezzel már elég régről
- site-to site és rw kapcsolatot is ki lehet építeni vele és ez jól jön 
az asterisk telefonközpontomhoz

A slussz poén:
A telefonszerver továbbra sem működik úgy, ahogyan szeretném:

2x cisco spa3102 >>>>>>> mikrotik gw 
 >>>>>>>>>>>>>>>>>>>>>>INTERNET>>>>>>>>>>>>>>>vpsszerver-debian8-freepbx 
manual telepítés,asterisk 13.10
192.168.10.33>>> 192.168.10.254>>>>publikus ip cím/pppoe(94.21.x.x) 
 >>>>>> publikus-ip(76.x.x.x/24)
I
I
192.168.10.40>>>> stb

A két hálózat strongswan ikev2 road warrior módban van
A 192.168.10.33 tudja pingelni:
192.168.10.40/32
192.168.10.0/24
INTERNET
vps ip címét

traceroute esetén is látom, hogy a vpn-be kerülnek a csomagok. (mindkét 
irányból jó)

A két spa3102-nek a sip proxy címe a vps külső címe.
Ha ftp-t indítok ( egy belső géptől) a vps-re vagy figyelem a sip 
regisztrációt, minden esetben ESP forgalmat látok és a VPN tunnelben 
mennek az adatok >>>> EZ OK
Vissza irányban ugyanez van >>>> Ez is OK

De ha, felhívja a két telefon egymást, akkor a hívás felépülés a vpn-ben 
lesz, míg a tényleges beszédkommunikáció titkosítatlanul megy keresztül 
és natolódik a mikrotiken. (rtp: udp/10000-20000 között)
tcpdumpnál ezt van:
192.168.10.33:1000X udp >>>> vps címe
vps címe>>>>>192.168.10.33:1000X udp
192.168.10.40:1000X udp >>>> vps címe
vps címe>>>>>192.168.10.40:1000X udp

Nem értem miért nem megy a vpn-be az rtp forgalom is,hiszen jól működik 
a vpn.
Openvpn esetében is ez volt a gond.

A transport mód lehet még érdekes, de nem igazán szeretném áthozni a 
"szemetet" holmi bridgeléssel

Új próba:
Kértem egy új interfészt a vps-re ami nem kapcsolódik a netre, és 
megpróbálom a tényleges site-to site konfigot.
A bindet átállítom a belső címre és akkor, már tényleg oda kell 
csatlakoznia, amit nem tud elérni a netről. >>> bízom benne ez lesz a 
megoldása a dolognak
Sejtésem szerint a mikrotik trükközik és az irányítja tévesen a net felé 
ezeket az udp csomagokat.

Az eddigieket köszönöm!

2017. 08. 25. 14:43 keltezéssel, ka at mayten.sch.bme.hu írta:
>
> Szerintem felre lettel vezetve.  Kifejtem.
>
> On 2017-08-25 12:58, Sándor Fehér wrote:
>
>> NO NE :), akkor egy kérdés:
>> Tegyük fel, hogy újraindítom a szervert és lecsatlakoznak a kliensek
>> és valami oknál fogva ( pl watchdog) újraindulnak a kliensek is.
>> Eredmény:  egy szerver restart hazavágja a vpn-t
>> Tök logikus amit írsz, de a való életben igen is lehet olyan eset,
>> hogy csak a szerver "él" a kliensek később csatlakoznak.
>
> A valo eletben minden helyzet pont ilyen.
>
>> Az előbbi miatt nem értem, hogy miért így működik a program: elszáll,
>> ha fel húzod up-al az rw kapcsolatot.
>>
>
> szoval az elmeletem (ami nem biztos, hogy helyes, de jelenleg akkor is 
> ezt gondolom) az, hogy egy dolog a vpn-t elinditani (felepiteni a 
> tuloldallal) es elinditani ugy, hogy keszen legyen bejovo kapcsolatok 
> fogadasara.
>
> szerintem a problemad tok egyszeru, ugyanis reprodukaltam.  nalad 
> auto=add van, ami azt jelenti, hogy kezzel kell up-ot adni neki. nalam 
> auto=start van, mert ha a szerver rebootol, en nem ohajtok kezzel 
> inditgatni dolgokat.
>
> Most csak a vicc kedveert ujrainditottam ipsec restart-tal az egesz 
> szolgaltatast, es nezd mi van a logomban:
>
>
> Aug 25 13:24:10 cube2 charon: 05[CFG] received stroke: add connection 
> 'mom3g-oob_cube'
> Aug 25 13:24:10 cube2 charon: 05[CFG] added configuration 
> 'mom3g-oob_cube'
> Aug 25 13:24:10 cube2 charon: 09[CFG] received stroke: initiate 
> 'mom3g-oob_cube'
> Aug 25 13:24:10 cube2 charon: 09[IKE] unable to resolve %any, initiate 
> aborted
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>
>
> Ez viszont nem hiba.  Az, hogy initiate nem tortenik az tok normalis - 
> nincs kihez.  De ettol fuggetlenul a kapcsolat mukodni fog, amint a 
> kliens kezdemenyezte a vpn-t es bejutott.
>
> A fenti amugy egy OOB menedzsment kapcsolat edesanyam otthoni 
> routerehez, hogy akkor is tudjam mi van a routerrel ha nincs net, mert 
> nyilvan engem hiv fel, hogy fiam, miert nem megy a net.
>
> Szoval a kliens oldalrol elinditom a kapcsolat felepiteset:
>
> c1921.bud-mom#ping vrf oob 10.7.20.13 source loopback 1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 10.7.20.13, timeout is 2 seconds:
> Packet sent with a source address of 10.7.20.14
> !!!!!
>
> es a logban kozben:
>
> Aug 25 13:25:40 cube2 charon: 10[IKE] CHILD_SA mom3g-oob_cube{1} 
> established with SPIs XXXXXXXXXX and TS 10.7.20.13/32 === 10.7.20.14/32
>
> Azaz szerintem a megoldas annyi, hogy ne dolj be a hibauzenetnek. Nem 
> hazudik, tenyleg nem tud kapcsolatot kezdemenyezni, de ez nem baj, 
> mivel csak fogadnia kell.
>
> Lehet, hogy nem tunik logikusnak a fenti, nekem se ez jutott elsore 
> eszembe, de szerintem a fentiekkel reprodukaltam a te helyzetedben 
> levo hibat es latszik, hogy ennek ellenere mukodik, ahogy kell neki.  
> Mivel en auto=start -ot szoktam hasznalni, logot meg csak akkor nezek 
> ha hiba van, igy a hibauzenet eddig nekem fel se tunt.
>
> udv
> adam
>
> _______________________________________________
> Techinfo mailing list
> Techinfo at lista.sulinet.hu
> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo
> Illemtan: http://www.szag.hu/illemtan.html
> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/

-- 
Szluka Pálné Igazgató asszony megbízásából
Fehér Sándor
Rendszergazda

Salgótarjáni Madách Imre Gimnázium
3100 Salgótarján, Arany J. út 12.
Telefon: (32) 411-353 Telefax: (32) 411-104
e-mail:fehersandor at madach-starjan.sulinet.hu
Internet: http://www.madach-starjan.sulinet.hu/