Access lists

[patakji]

Sto provando a configurare il mio router cisco 837 via telnet per alcune connessioni in entrata.
Per esempio vorrei accettare tutte le connessioni tcp/ip sulla porta 8484 e udp sulla porta 9966, mi chiedo se la sintassi che uso è corretta, sapreste darmi una mano?

cisco<config>#access-list 130 permit tcp any any eq 8484
cisco<config>#access-list 130 permit udp any any eq 9966

Con queste impostazioni dovrei accettare tutte le connessioni tcp su qualunque macchina della mia rete attraverso la porta 8484 e udp 9966 o sbaglio? Forse c'è un comando per applicare e rendere effettive queste impostazioni?

Mi sono letto praticamente tutti i post sul forum ma ancora, dopo svariati tentativi, non sono riuscito ad aprire quelle due porte in entrata...

Grazie ancora per il vostro aiuto!!!

[TheIrish]

I comandi sono corretti.
Vanno comunque applicati ad una o più interfacce del router. Normalmente, visto che i pacchetti scoprono qual è il destinatario al quale devono essere consegnati una volta attraversata l'interfaccia dalla quale sono entrati (a causa del NAT), è bene applicare le proprie regole di permit all'interfaccia più vicina al destinatario, nel tuo caso ethernet0.
Questo risultato si ottiene così

Codice: Seleziona tutto

>enable
#conf t
#(config)interface e0
#(config-if)ip access-group 130 out

Perché out? Perché il verso del transito dei pacchetti va visto dall'interno del router. Out perché sta uscendo verso i PC.
Attenzione però, alla fine di una ACL c'è un implicito deny any quindi se la applichi così com'è, accetterai solo le porte che hai esplicitato e il resto verrà scartato!
Fai così, scrivi una ACL completa di tutto quello che ti serve e poi facci vedere il risultato onde evitare (come è capitato un po' a tutti noi) di chiuderti fuori!
NOTA: abilitare l'ingresso di dati con un ACL non significa che, una volta dentro, il NAT sappia a chi destinare quei dati. In particolare, udp è stateless, quindi, una volta dentro, il router non saprà a chi darli ammeno che non vi riconosca un protocollo noto . Per risolvere il problema, è necessario usare il NAT statico, ma questa è un'altra storia...

[patakji]

Penso si sia capito, sto tentando di aprire le porte per emule... In realtà ci sono già riuscito perfettamente con il CRWS alla voce "Configurazione avanzata" "Abilita PAT", ma così non imparo niente!!!
Diciamo che ora emule è fermo, non lo uso per scaricare ma come mezzo per apprendere, insomma vorrei cinfigurarmi da solo le access-lists.

cisco<config>#access-list 130 permit tcp any any eq 8484
cisco<config>#access-list 130 permit udp any any eq 9966

cisco<config>#interface e0
cisco<config-if>#ip access-group 130 out

Il fatto che ci sia un denay all implicito alla fine del comando implica che tutte le connessioni tcp e udp in entrata usano queste due porte giusto? Se setto il client emule per usare queste due porte tutto dovrebbe andare bene e dovrei ottenere un ID alto, no?

Però così non va, ottengo ancora un ID basso... L'access-list 130 l'ho creata io, dovrei forse inserire il comando permit in una access-list di default, così come avviene se setto le porte con la funzione "Abilita PAT" del CRWS? O forse dovrei approfondire un po'l'argomento "NAT statico"?

[TheIrish]

Il fatto che ci sia un denay all implicito alla fine del comando implica che tutte le connessioni tcp e udp in entrata usano queste due porte giusto?

Vuol dire che altre porte non verranno aperte. Nemmeno il web dovrebbe funzionare!
Guarda questa istruzione:

Codice: Seleziona tutto

access-list 130 permit tcp any 192.168.0.0 0.0.0.255 established

Questo sta a significare: qualsiasi dato entri dall'esterno nel router che sia stato richiesto dalla rete interna (in questo caso 192.168.0.0), può passare. Web, email ecc. rientrano in questa tipologia di dati.
Questa operazione non è applicabile a UDP.

Se setto il client emule per usare queste due porte tutto dovrebbe andare bene e dovrei ottenere un ID alto, no?

No, non ottieni un ID alto.
Come già detto precedentemente, il router riceve dei dati insollecitati dall'esterno su quelle due porte. Insollecitati, fanno parte del funzionamento dell'edonkey network.
Le porte sono aperte, e quindi il router fa entrare questi dati, ma una volta dentro il poveretto non sa cosa farsene, non sa a chi consegnarli perché non fanno parte di una connessione avviata dall'interno.
Per avere un ID alto, purtroppo è possibile abilitare solo 1 PC in una LAN all'uso di e-mule attraverso il NAT statico.
Così:

Codice: Seleziona tutto

ip nat inside source static tcp 192.168.0.10 8484 interface Dialer1 8484
ip nat inside source static udp 192.168.0.10  9966 interface Dialer1 9966

dove 192.168.0.10 è l'indirizzo interno del PC abilitato all'uso di e-mule e Dialer1 è l'interfaccia WAN del router.
Questo codice significa: qualsiasi dato tcp entri dalla 8484 va senza discussioni verso 192.168.0.10. lo stesso per udp/9966

[patakji]

Niente da fare

Codice: Seleziona tutto

cisco<config>#ip nat inside source static tcp 192.168.0.10 8484 interface Dialer1 8484
cisco<config>#ip nat inside source static udp 192.168.0.10  9966 interface Dialer1 9966 

cisco<config>#access-list 130 permit tcp any host 192.168.0.10 eq 8484
cisco<config>#access-list 130 permit udp any host 192.168.0.10 eq 9966 

cisco<config>#interface e0
cisco<config-if>#ip access-group 130 out 

ottengo ancora un ID basso.

Facendo

Codice: Seleziona tutto

cisco#show access-lists

scopro che ci sono altre access-lists impostate (Extended IP access-list 112, per esempio), forse queste influenzano l'access-list 130 che voglio creare io?

[Asimov]

perdona la schiettezza:
perché non ci alleghi uno show run così vediamo com'è la situazione?

[patakji]

OK, non volevo essere invadente... Intanto grazie!

[Sushi]

ok, provo a dare una mano anch'io.
L'insieme sembra essere ok, ma non capisco come tu faccia a navigare!
non c'è l'established di cui parlava theirish prima.
Comunque se fosse per me sposterei tutte le protezioni su ethernet0 anzichè dialer1.

[yakuz@]

Attenzione però, potrebbe essere un caso di falso ID basso. Ci sono molti casi citati nel sito di e-mule. Io proverei a spostare le ACL sulla e0... il problema potrebbe essere più sottile di quanto sembri.
Hai fatto il test delle porte messo a disposizione da e-mule?

[patakji]

Si ho fatto il test, esito positivo, adesso come adesso emule funziona perfettamente, ho un ID alto e se provo a scaricare qualcosa va abbastanza veloce.
Però non era questo il problema, nel senso che ho postato su ciscoforums perchè volevo imparare qualcosa di nuovo! E ce n'è da imparare su questo router...
Che cosa cambia se sposto le acl su e0 piuttosto che lasciarle su dialer1 a livello di protezione?

[MrCisco]

Beh, finchè le ACL sono così semplici, tecnicamente nulla.
la grossa differenza c'è quando vuoi discriminare uno più indirizzi interni alla LAN.
per esempio, se vuoi evitare che 192.168.0.1 e 192.168.0.2 possano... ricevere dati da un server di posta mentre 192.168.0.3 192.168.0.4 no, è necessario che il router abbia già tradotto il NAT e questo accade una volta che i dati sono entrati nel router; ovvio che se li blocchi sul Dialer1, la cosa non funziona.
Un consiglio che avevo già letto sopra: ci sono delle righe dell'acl che hai postato che considererei MOLTO PERICOLOSE.
Esempio: netibios e bootpc... non credo proprio ti servano aperte all'esterno anche perché all'esterno servono quasi esclusivamente a farti hackare la rete!

[patakji]

se vuoi evitare che 192.168.0.1 e 192.168.0.2 possano... ricevere dati da un server di posta mentre 192.168.0.3 192.168.0.4 no...

Già, non ci avevo pensato!

Per quanto riguarda netibios e bootpc me ne sono reso conto quando ho fatto lo show run e li ho eliminati...