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!!!
Access lists
Moderatore: Federico.Lagni
- TheIrish
- Site Admin
- Messaggi: 1840
- Iscritto il: dom 14 mar , 2004 11:26 pm
- Località: Udine
- Contatta:
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ì
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...
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
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...
-
- n00b
- Messaggi: 13
- Iscritto il: dom 19 dic , 2004 3:05 pm
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"?
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
- Site Admin
- Messaggi: 1840
- Iscritto il: dom 14 mar , 2004 11:26 pm
- Località: Udine
- Contatta:
Vuol dire che altre porte non verranno aperte. Nemmeno il web dovrebbe funzionare!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?
Guarda questa istruzione:
Codice: Seleziona tutto
access-list 130 permit tcp any 192.168.0.0 0.0.0.255 established
Questa operazione non è applicabile a UDP.
No, non ottieni un ID alto.Se setto il client emule per usare queste due porte tutto dovrebbe andare bene e dovrei ottenere un ID alto, no?
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
Questo codice significa: qualsiasi dato tcp entri dalla 8484 va senza discussioni verso 192.168.0.10. lo stesso per udp/9966
-
- n00b
- Messaggi: 13
- Iscritto il: dom 19 dic , 2004 3:05 pm
Niente da fare
ottengo ancora un ID basso.
Facendo
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?
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
Facendo
Codice: Seleziona tutto
cisco#show access-lists
-
- n00b
- Messaggi: 21
- Iscritto il: dom 21 mar , 2004 7:18 pm
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.
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.
-
- n00b
- Messaggi: 16
- Iscritto il: lun 19 lug , 2004 3:55 pm
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?
Hai fatto il test delle porte messo a disposizione da e-mule?
-
- n00b
- Messaggi: 13
- Iscritto il: dom 19 dic , 2004 3:05 pm
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?
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?
-
- Cisco pathologically enlightened user
- Messaggi: 202
- Iscritto il: mar 29 giu , 2004 12:12 pm
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!
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!

-
- n00b
- Messaggi: 13
- Iscritto il: dom 19 dic , 2004 3:05 pm
Già, non ci avevo pensato!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...
Per quanto riguarda netibios e bootpc me ne sono reso conto quando ho fatto lo show run e li ho eliminati...