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

• #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

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