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

• #8841 A_ScHuLcZ addikt crok #8826

  Új Válasz 2015-06-29 12:50:06 #8841

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 flash00307010200.bin
  tftp-server flash00307010200.loads
  tftp-server flash00307010200.sb2
  tftp-server flash00307010200.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

• #8828 zsolti.22 senior tag crok #8826

  Új Válasz 2015-06-25 21:12:21 #8828

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

• #8827 zsolti.22 senior tag crok #8826

  Új Válasz 2015-06-25 18:19:04 #8827

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  zsolti.22

  senior tag

  válasz crok #8826 üzenetére

  .

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