Idézet: Jahno - Dátum: 2009. jan. 24., szombat - 10:54
Semmi olyat nem tudok irni maganlevelben, amit itt ne tudnek leirni. Igaz, hogy mar nem dolgozom azon a helyen, de a szaftos reszleteket ettol fuggetlenul nem irhatom le. Inkabb ide irom, mert hatha mas tanul belole.
Lenyeg a lenyeg: egy CUCM -nak volt publikus ip cime, egeszen pontosan egy statikus PAT volt egy routeren (28xx) beallitva egy belso cimre, de maga a CME futott a routeren a sajat IP cimen.
Az, amit mi bugnak hittunk, az a kovetkezo: ha nincs static PAT beallitva a routeren, akkor a CME a router sajat IP cimen valaszol. Ha tcp static pat van beallitva, akkor meg mindig. Ugyanakkor ha udp-t patolsz belulre, akkor a routeren futo osszes szolgaltatas hirtelen elerhetove valik azokon a cimeken is, amelyek a pat global cimei.
Mivel volt egy udp pat a routeren beallitva, ezen a global ip cimen is listenelt a cme. Igy ha hivast kuldtek neki, akkor kezelte. SIP szervernek hasznalva a benne levo PRI-n at tudtak kubaba telefonalni. Es mivel az acl-ek a fentiek ismerete nelkul volt beallitva, igy ez mukodott is. Asteriskemmel en is kiteszteltem, nekem is ment.
Laborban a helyzetet reprodukaltuk, rajottunk, hogy mi okozza, hogy bindel a cme a router nem sajat cimere. Irtunk a cisconak, hogy ez szerintunk egy vastag bug. A valasz az volt, hogy ez igy van jol, ennek igy kell mukodnie es hasznaljunk acl-eket.
A teszt a laborban amugy ugy zajlott, hogy ket routert egymas moge kotve kivulrol nezve a hatso router volt a time szerver. Ha az elso routeren beallitottam a patot, akkor a kulso router telneten elerhetove valt azon a cimen amin a belso router time servere volt. Ha a patot kikapcsoltam, akkor pedig timeout volt ahogy lennie kell. tcp pat nem valtoztatott a helyzeten, de pl. egy snmp mar megint igen.
A tanulsag az esetbol a kovetkezo:
- pots kapcsolatot nem kotunk publikus ip cimmel elerheto helyre
- acl beallitasoknal mindnen ismert adatot ki kell tolteni a white listben, kulonben kellemetlen meglepetesek erhetnek

Súgó
A téma zárva.












