Benvenuto,
Ospite
|
ARGOMENTO:
Moderatori: jpalombi
Benvenuto,
Ospite
|
|
Salve a tutti
sapete dirmi come dovrebbe venire l'ACL evidenziata nell'immagine allegata? Scusate, ma ho provato 1000 volte!! La rete attaccata a g0/0 di Branch è 172.16.144.0/20, HQServer.pka è 172.16.0.1 Grazie mille |
Si prega Accedi a partecipare alla conversazione. |
|
Ciao Nicola,
l'esercizio di aspetta la seguente configurazione sul Branch: ip access-list extended HQServer deny ip any host 172.16.0.1 permit ip any any interface GigabitEthernet0/0 ip address 172.16.159.254 255.255.240.0 ip access-group HQServer in Vorrei solo sottolineare come, quando si ha a che fare con le ACL, le soluzioni al medesimo problema possono essere molteplici e tutte corrette (errori concettuali a parte). Quindi, sebbene l'ACL da me configurata sia una EXTENDED, e che vada giustamente applicata il più vicino possibile alla sorgente del traffico, tecnicamente parlando anche la configurazione su HQ che segue avrebbe raggiunto lo scopo: ip access-list standard HQServer deny 172.16.144.0 0.0.15.255 permit any any interface GigabitEthernet0/1 ip access-group HQServer out Ovviamente preferibile la prima soluzione, ma ho esposto la seconda per due ragioni: la prima era quella di sottolineare il fatto che effettivamente le cose si possono fare in molti modi, la seconda invece per rendere evidente come il PT in certi frangenti di valutazione, come ad esempio quelli riguardanti le ACL, sia estremamente rigido: la valutazione avviene infatti comparando le vostre configurazioni a quelle realizzate dall'ideatore dell'activity. Se era stata decisa la prima soluzione, la seconda non darà punteggio sebbene funzionante. Detto questo un invito alla riflessione rivolto a tutti: che differenza c'è con la seguente ACL applicata su Branch, stessa interfaccia stesso verso? E' identica ed assolve esattamente allo stesso scopo? Fa qualcosa in più? In meno? Non funziona? ip access-list extended HQServer deny ip 172.16.144.0 0.0.15.255 host 172.16.0.1 permit ip any any IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications |
Si prega Accedi a partecipare alla conversazione. |
|
Dunque sono in crisi....
Ma la seconda che ha scritto è una standard???? Il comando "permit any any" non è per una extended e basta?? Io avevo proprio scritto l'ultima riportata e mi sembrava rispettasse quanto richiesto dall'esercizio anche se non coincide con quella che PT si aspetta. Infatti non mi dava punteggio. Io poi l'ho applicata a g0/0 in. Per me l'ultima riportata funziona esattamente come la seconda. Sbaglio? Probabile! Vado a studiare! |
Si prega Accedi a partecipare alla conversazione. |
|
Ho trascritto un any di troppo, spero che la crisi non sia scaturita da ciò
Per quanto concerne la seconda parte del tuo messaggio, attendiamo qualche altra opinione e vediamo che succede ^^ IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications |
Si prega Accedi a partecipare alla conversazione. |
|
Nessuno si aggiunge alla discussione?
IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications |
Si prega Accedi a partecipare alla conversazione. |
|
Ciao ragazzi..
direi che le due extended per quanto diverse per le reti coinvolte, hanno lo stesso effetto sul traffico ip/tcp : bloccano quello proveniente dalla 172.16.144.0 del Branch una e tutto quello proveniente in ingresso nella g0/0 del Branch l'altra ( che sempre la 172.16.144.0 è )entrambe verso l'host 172.16.0.1 .. A causa della genericità dell' ''any'' della prima extended, casomai si implementasse una vlan sul router branch con un'altra subnet, verrebbe bloccata anche quella verso l'host HQserver, mentre dichiarando la specificamente nella seconda ACL la 172.16.144.0 il deny non si matcherebbe.. |
Si prega Accedi a partecipare alla conversazione. |
|
Mmmm, però questo richiederebbe: 1) una nuova interfaccia fisica oppure 2) una nuova sub-interface In entrambi i casi, l'ACL dovrebbe essere applicata nuovamente per avere effetto. L'osservazione in qualche modo va nella giusta direzione, ma consideriamo proprio la STESSA rete e le due ACL IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications |
Si prega Accedi a partecipare alla conversazione. |
|
si ... infatti mi chiedevo se le ACL si implementassero anche sulle subinterfaces ... e mi sono risposto '' perché non dovrebbero ? ''
vabbè ... nel caso della stessa rete e 2 acl io direi che funzionano entrambe bloccando il traffico della 172.16.144.0 verso l'host HQ ... ma il mio sesto senso di pizzaiolo mi dice che la tua domanda è capziosa e quindi mi sta sfuggendo qualcosa.. |
Si prega Accedi a partecipare alla conversazione. |
|
Salve a tutti,
ho un problema su questo scenario perchè pur avendo costruito e verificato le ACL il Packet Tracer mi dice che sono sbagliate. Forse le vuole in un altro modo. |
Si prega Accedi a partecipare alla conversazione. |
|
Ciao Daniele,
qui il problema se vogliamo è di fino. Tu hai giustamente configurato ad esempio su HQ la seguente ACL (applicata correttamente in verso InBound sulla G0/0): ip access-list extended BranchServer deny tcp 172.16.64.0 0.0.63.255 host 172.16.128.1 eq www deny tcp 172.16.64.0 0.0.63.255 host 172.16.128.1 eq 443 permit ip any any Tuttavia il PT si aspetta questa: ip access-list extended BranchServer deny tcp any host 172.16.128.1 eq www deny tcp any host 172.16.128.1 eq 443 permit ip any any A prescindere però dalle valutazioni della correttezza effettuata dall'autore dell'activity PT (alle volte eccessivamente rigida, alle volte anche discutibile), noti una differenza apprezzabile tra le due? Ragionateci tutti IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications |
Si prega Accedi a partecipare alla conversazione. |
|
Ciao Daniele. Eh si, perché alla fine giustamente non è un errore,ma una finezza. Anche se non sono a casa e sono con il Tel, penso sia lo stesso problema di questo post:
www.ipcert.it/forum/classe-ccna-bdl-2016...enge-capitolo-9.html Buona serata |
Si prega Accedi a partecipare alla conversazione. |
|
Con il metodo PT si esclude dall'HTTP e HTTPS qualsiasi origine. Anche se andrò ad immettere una nuova rete, questa verrà respinta sul web. Forse quella attuata dal PT è sicuramente più rigida ma anche più sicura
Ringraziano per il messaggio: jpalombi
|
Si prega Accedi a partecipare alla conversazione. |