Hirdetés

Keresés

Új hozzászólás Aktív témák

  • A_ScHuLcZ

    addikt

    válasz crok #8826 üzenetére

    Végül még péntek délután reseteltem az egészet és kezdtem elölről, de ezúttal már SCCP-vel. Így a telefonok simán beregisztráltak és letöltötték a megfelelő fw-t. A 7940-ek között szépen megy a hívás, viszont a 7911 és 7906-on nem működnek a funkciógombok, nem tudok hívást indítani, sem elfogadni, sem elutasítani, valamint vonal sincs. De ha hívom az azokhoz rendelt melléket, akkor megjelenik a bejövő hívás a kijelzőjükön. Valami hiányozhat?

    A konfig érdemleges részei:
    ip dhcp pool voice
    network 172.22.100.0 255.255.255.0
    option 150 ip 172.22.100.1
    default-router 172.22.100.1

    tftp-server flash:P00307010200.bin
    tftp-server flash:P00307010200.loads
    tftp-server flash:P00307010200.sb2
    tftp-server flash:P00307010200.sbn
    tftp-server flash:apps11.9-2-1TH1-13.sbn
    tftp-server flash:cnu11.9-2-1TH1-13.sbn
    tftp-server flash:cvm11sccp.9-2-1TH1-13.sbn
    tftp-server flash:dsp11.9-2-1TH1-13.sbn
    tftp-server flash:jar11sccp.9-2-1TH1-13.sbn
    tftp-server flash:SCCP11.9-2-1S.loads
    tftp-server flash:term06.default.loads
    tftp-server flash:term11.default.loads

    telephony-service
    no auto-reg-ephone
    max-ephones 144
    max-dn 500
    ip source-address 172.22.100.1 port 2000
    load 7911 term11.default
    load 7960-7940 P00307010200
    dialplan-pattern 1 5123781291 extension-length 4
    max-conferences 12 gain -6
    transfer-system full-consult
    secondary-dialtone 9
    create cnf-files version-stamp Jan 01 2002 00:00:00

    ephone-dn 1 dual-line
    number 1001
    name Teszt1
    !
    ephone-dn 2 dual-line
    number 1002
    name Teszt2
    !
    ephone-dn 3 dual-line
    number 1003
    name Teszt3
    !
    ephone-dn 4 dual-line
    number 1004
    name Teszt4
    !
    ephone-dn 5 dual-line
    number 1005
    name Teszt5
    !
    ephone-dn 6 dual-line
    number 1006
    name Teszt6
    !
    ephone-dn 7 dual-line
    number 1007
    name Teszt7
    !
    ephone-dn 8 dual-line
    number 1008
    name Teszt8
    !
    ephone 1
    device-security-mode none
    mac-address 0022.905A.9BBC
    type 7940
    button 1:1
    !
    ephone 2
    device-security-mode none
    mac-address 0022.905A.9D9C
    type 7940
    button 1:2
    !
    ephone 3
    device-security-mode none
    mac-address 0022.9003.955C
    type 7940
    button 1:3
    !
    ephone 4
    device-security-mode none
    mac-address 0024.C444.6BD1
    type 7962
    button 1:4
    !
    ephone 5
    device-security-mode none
    mac-address 0021.A084.A71B
    type 7911
    button 1:5
    !
    ephone 6
    device-security-mode none
    mac-address 0021.A02E.5BBB
    type 7911
    button 1:6
    !
    ephone 7
    device-security-mode none
    mac-address E804.62EA.6732
    type 7911
    button 1:7
    !
    ephone 8
    device-security-mode none
    mac-address 0023.5EB8.78B8
    type 7906
    button 1:8

  • zsolti.22

    senior tag

    válasz crok #8826 üzenetére

    Szia!

    Sikerült megoldanom, de már ki is ment a fejemből, hogy mi volt a konkrét megoldás. Jó sok ACL-em volt, amit nem is használt végül a router. Onnan jöttem rá, mi a gond, hogy a show crypto engine connections active mutatta, hogy decryptálni tudta a csomagot, de encryptálni már nem akart. Ekkor nézegettem az ACL-eket és azokból az látszott, hogy a NAT-os deny-os ACL sorra is van találat, a crypto ACL-re visszafelé szintén, ennek ellenére mégsem történt meg a csomagok titkosítása. Aztán nézegettem a class-mapokat és ott egy inspectet átírtam pass-ra és egyből ment az egész. Nem is hittem volna, hogy nem lesz lassú a kapcsolat és a router se fog pörögni tőle, így pozitívat csalódtam.
    Aztért lehetett ennyire kusza megtalálni a megoldást, mert szerintem nem jól értettem meg a ZBF alapjait és emiatt fölösleges zóna-párjaim lehetnek, amik csak bezavarnak.
    Itt ragadnám meg az alkalmat és fejtágítást szeretnék kérni a ZBF-et illetően és nézzük is a konkrét, használatban lévő routerem konfigját. Jelenleg a routeremben 3 zóna van: VOIP, INSIDE, OUTSIDE. Szerintem beszédes zónák, nem kell túlmagyarázni.
    A VOIP az VLAN700 SVI-re van felkonfigurálva a routeren és csak egyetlen port tagja ennek a VLAN-nak, mert csak egy telefon van. Ő egy /30-as címet kapott (192.168.20.0/30).
    Az INSIDE zóna már nehezebb, ide a VLAN600 és VLAN500 tartozik. A VLAN600 a vezetékes belső hálózat, ami 192.168.15.0/29-es tartományban csücsül, a VLAN500 pedig a belső vezeték nélküli hálózat, az ő címtartománya a 192.168.10.0/29 lett.
    Olvastam olyanról, hogy ahol lehet, kerülni kell a SELF zóna használatát, mert igencsak meg tudja nehezíteni az ember életét. Lehet, hogy pont te írtad itt valahol.
    Amilyen szabályokat én zónákat csináltam, azok a következők:

    INSIDE-to-OUTSIDE

    Egyértelmű, a wifis és belső vezetékes gépek érjék el az internetet
    itt ezeket használom a class-mapomban:
    match protocol pop3s
    match protocol dns
    match protocol icmp
    match protocol ntp
    match protocol tcp
    match protocol udp

    A policy-mapban őket inspektálom, a class class-defaultot droppolom. Szóval elvileg ha bentről szinte bármit csinálok, akkor arra mindig érkezik vissza válasz, ezzel elvileg nem kell foglalkoznom.

    INSIDE-to-VOIP

    Egyértelmű, a VOIP telefonomnak van webes felülete, azt szeretném elérni néha, ha konfigurálni kell. Itt én most azt látom, hogy van egy ACL-em, ami engedélyezi a belső gépek számára a VOIP telefon IP címét és TCP 80-as port elérését (permit tcp 192.168.10.0 0.0.0.31 host 192.168.20.2 eq www), de nem inspektál a policy-mapom, hanem passol. Na most ahogy gondolkodom közben, ez jó nagy hülyeség: ha inspect lenne, akkor automatikusan beengedné a router a telefontól érkező HTML tartalmat. Olyan eset önmagától, hogy a telefon 80-as porton egyszer csak forgalmat kezdeményezzen a belső hálózat bármely gépére, olyan soha nem lesz, így ez az INSIDE-to-VOIP és VOIP-to-INSIDE policy-map, ami passol, az szerintem felesleges, és inkább INSIDE-to-VOIP inspect kellene helyette.

    Ezek voltak az egyértelmű dolgok, most jön a neheze.

    VOIP-to-OUTSIDE
    Itt ezeket inspektálom:
    match protocol ntp
    match protocol dns
    match protocol tcp
    match protocol udp
    (SIP-et ha ideveszem, akkor katasztrófa történik, nem működik)

    A telefon ugye 5060 forrás- és 5060 cél UDP porton kommunikál kettő szolgáltatóval. Ha inspektálom ezt ACL alapján, akkor elvileg a szolgáltatótól visszaérkező választ a router beengedi. Na de amikor engem megpróbálnak elérni telefonon, akkor a szolgáltató kezdeményez 5060-as porton (vagy STUN 3478-es UDP porton), hogy egyeztessen a telóval és elkezdjen kicsörgetni, emiatt szükség van OUTSIDE-to-VOIP zónára is (jól látom, ugye?). A telefon és a teljes belső hálózat NAT-olva van, tehát ELVILEG a SELF zóna eddig nem jön szóba, mert a router amikor NAT-ol, szépen NAT táblában feljegyzi, milyen forrás socketet milyen cél socketre fordított, ennek alapján dönti el, hogy mely zónákat érinti a forgalom, így elgondolásom szerint nincs szükség OUTSIDE-to-SELF és SELF-to-VOIP zónára. A telefon NTP-n keresztül szereti lekérdezni az időt, ez szintén benne van az inspectben, tehát elvileg az időt is leszinkronizálja magának. Kérdés, hogy az OUTSIDE-to-VOIP az ispect legyen, vagy pass és akkor kell visszafelé is pass? Ha inspect, akkor egy esetleges hívásnál mennyire szopatja a routert a sok dynamikus visszaengedés (egy pár másodperces hívás is több száz vagy már 1000 fölötti darabszámú UDP oda-vissza csomag)?

    OUTSIDE-to-SELF

    Vannak olyan forgalmak, ami egy az egyben csak a routernek szól és nem mögöttes eszköznek, ilyen forgalom: az SSH, router órájának szinkonizációja, DDNS, uplink DHCP egyeztetés, DNS lekérdezés (konfigurációban meglévő domain-név feloldása). Ha jól látom, akkor ezeket a self zóna nélkül nem tudnám implementálni. Ezeket hiába inspektálom, mert azt hiszem, hogy azt nem is lehet és marad a drop és pass, pass esetén akkor nyilván kell a fordítottja is, azaz SELF-to-OUTSIDE irány is. Ha csinálok SELF-ot-OUTSIDE-ot is, akkor a router kezdi minden forgalomról azt hinni, hogy az a SELF zónából származik (NAT-olás miatt a publikus IP lesz minden internet felé szánt forgalom forrás IP-je, de akkor hülyeség, amit erről korábban fenti írtam?) és elkezdi nem kiengedni a dolgokat. Ez szépen látszik ebben az irányban a class class-default drop logjában (NTP-t biztosan eldobta kifelére menet, SIP-et is, mint a huzat).

    És akkor a fentiek tudatában szeretne az ember VPN-t konfigurálni: kérdés, hogy mely zónákat érinti ez? OUTSIDE-to-VOIP egyből, hiszen publikus forrás- és cél IP-jű a csomag, amit a router kap, majd miután kihámozza az ESP részt, akkor egyből megy is a VOIP zónába (tehát a router megvárja, míg kiderül, hogy csak neki szól vagy továbbítani kell valahova és annak megfelelően érinti a zónákat)? Vagy OUTSIDE-to-SELF, mert a router publikus IP-je a csomag célja és egyelőre ennyi látszik, míg a titkosítás nincs decryptálva, majd onnan SELF-to-VOIP és visszafelé VOIP-to-SELF és SELF-to-OUTSIDE vagy egyből VOIP-to-OUTSIDE?
    Melyik irány és miért az?
    Ja igen, a cél itt az, hogy egy másik telephelyen lévő Cisco router mögüli RFC1918-es IP-jű gép böngészőjébe beírva a 192.168.20.2-t, megjelenjen a VOIP telefon webes felülete.
    Nah, túl hosszú lett, remélem, hogy valaki azért elolvassa és tésztavizet önt a poharamba :)

Új hozzászólás Aktív témák