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

• #4300 jerry311 nagyúr karesz500 #4298

  Új Válasz 2013-08-21 22:13:21 #4300

  Ú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

  

  jerry311

  nagyúr

  válasz karesz500 #4298 üzenetére

  Ez inkabb arra van hogy olyan manipulalat pakkokat nem engednek be a halozatba amelynek szorasi forrascime van.

  Azért jó lenne tudni, hogy milyen irányban van az ACL aminek része, mert könnyen változhat a leányzó fekvése.

• #4287 jerry311 nagyúr karesz500 #4286

  Új Válasz 2013-08-20 18:31:32 #4287

  Ú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

  

  jerry311

  nagyúr

  válasz karesz500 #4286 üzenetére

  A switch switchel, a router routol, a PIX pixel az ASA meg a sal.

  Javaslom a kozelebbi megismerkedest az icmp paranccsal.
  Kezdetnek valahogy igy:
  icmp permit any outside
  icmp permit any inside

  Aztan kesobb lehet vele jaccani.
  A PIX/ASA kulon allatfajta. Kulon kell kezelni az eszkoznek szant es az atmeno forgalmat.

  tusi_
  DMVPN-t majd otthonrol, most megyek mert lekesem a vonatom.

• #4280 jerry311 nagyúr karesz500 #4279

  Új Válasz 2013-08-20 16:18:47 #4280

  Ú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

  

  jerry311

  nagyúr

  válasz karesz500 #4279 üzenetére

  A tunnel egeszen addig nem epul fel, amig nincs az ACL-nek megfelelo forgalom.
  Az egyszeruseg kedveert pingelj a routerrol. Meg kell hataroznod a source IP-t, kulonben ugye annak az interface-nek az IP-je lesz a source, amelyiken kikuldi a csomagot. Tehat 'ping 10.0.1.1 source 10.0.2.1'
  Nem fog valasz erkezni, de ettol fuggetlenul a tunnel felepul, mert olyan forgalom volt, amit bele kell rakni a tunnelbe.
  Ha VPN-en keresztul akarod pingelni a PIX inside IP-jet, akkor: "mana inside' a baratod, mert a varazslashoz mana kell.
  Ha ezen az oreg PIX-en keresztul akarsz kuldeni barmit, akkor arra nem eleg az ACL (vagy a megfelelo high to low security forgalom) hanem valamilyen NAT szabalyank is ervenyesnek kell lenni ra. Mondjuk
  access-list 100 permit ip 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0
  nat (inside) 0 access-list 100
  clear xlate

  Ha valamit elirtam, az azert van mert nincs keznel 6.3-as PIX, hogy konzolrol masolhassam.

  UI: sysopt connection permit-vpn (kulonben meg az outside ACL-lel is szivnod kell)

• #4278 jerry311 nagyúr karesz500 #4277

  Új Válasz 2013-08-20 14:11:28 #4278

  Ú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

  

  jerry311

  nagyúr

  válasz karesz500 #4277 üzenetére

  Tippelem 6.3(5) vagy korabbi. Igazabol mindegy is. Szemelyes (es barati kor) tapasztalat alapjan azt mondom, hogy ahany felhasznalas annyi ACL, hiaba ugyanazt tartalmazza. Bar egyre jobban halad a software az ilyen aprobb epitoelemek ujrafelhasznalasaban, a 6.x verzio meg nagyon nem volt jo ebbol a szempontbol.

  Az sem sokat segit, hogy PIX-en default routenak a sajat IP cimet adod meg.

  A VPN konfig viszont alapvetoen jo.
  Ket hasznos debug:
  debug crypto isakmp
  debug crypto ipssec

  A transform set, ACl, keyring, profile, stb. eseteben ajanlott vagy a kapcsolatra jellemzo nevet adni vagy azt amit tartalmaz, kesobbiekben megkonnyiti az eletet.

  Valamint, a PIX 6.x alapvetoen nem enged at semmit magan, amire nincs NAT szabaly.

• #4269 Hedgehanter őstag karesz500 #4267

  Új Válasz 2013-08-19 15:52:18 #4269

  Ú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

  

  Hedgehanter

  őstag

  válasz karesz500 #4267 üzenetére

  SA az a Security Association, ebben hatarozzuk meg a Phase 1 es 2 ben a parametereket.

  A Phase 1 az IKE (ISAKMP) channel amin keresztul a peer-ek authenticaljak egymast, IKE SA policit cserelnek, crealnak egy kulcsot a DH-val, es felepitik a secure tunnel-t Phase 2 hoz. Itt csak azt beszelik meg hogy mivel epuljon fel a Phase 1 es azokbol egy titkos csatorna lesz amiben megbeszelik majd a Phase 2-t.

  A Phase 2 ben IPsec SA-t cserelnek amivel titkositva lesz az adat amit neha ujratargyalnak, neha a PFS segitsegevel ami a DH-n alapul..

  A tobbi kerdesed remelem erthetobb az elobbi magyarazt utan...

• #4268 jerry311 nagyúr karesz500 #4267

  Új Válasz 2013-08-19 15:41:25 #4268

  Ú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

  

  jerry311

  nagyúr

  válasz karesz500 #4267 üzenetére

  Nagyon roviden es nagyon pongyolan...
  Mindket esetben a beallitott hash, encryption, lifetime, DH group (~PFS @ phase 2), stb. alapjan epiti fel a kapcsolatot.
  Az SA (Security Associaton) egy felepitett kapcsolathoz tartozo adatok osszesseget rejti. Nyilvan a fenti konfiguralt elemek plusz az aktualis titkositasi kulcs es hatralevo lifetime (adat es ido egyarant).

  Azert ketto, mert az elsoben a biztonsagos csatornat epiti fel, amin aztan majd titkositva megbeszelik a peerek, hogy az adatforgalmat milyen beallitasokkal kuldik egymasnak. Tehat a masodik fazisban is egyeztetni kell mindent. Ugy is mondhatjuk, hogy a masodik fazisban ugyanaz tortenik, mint az elsoben, csak nem a peerek kozti forgalomra vonatkozoan, hanem a valos adatforgalomra.

  PFS: DH kulcs csere phase 2-ben. Ez azert jo, mert enelkul a phase 2 kulcs alapvetoen a phase 1 kulcs leszarmazottja lenne. Tehat PFS nelkul konnyebben torheto, mint PFS-sel.

  Crypto mapban rakod ossze az epitoelemeket, mint peer, ACL, transform set, PFS, lifetime, stb.
  Majd a crypto map kerul ra valamelyik interface-re es vegul ennek alapjan donti el az eszkoz, hogy kell-e titkositani vagy sem.

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