Visualizzazione dei risultati da 1 a 10 su 10

Discussione: router

  1. #1

    router

    Ciao ragazzi, rieccomi alla ribalta dopo un periodo si assenteismo.
    Alla fine non sono riuscito a fare il gateway.
    Ora ho un bel numero di linux pratico dove spiegano bene com impostare il gateway e cosa accede durante il processo di nattind.

    Facciamo finta che il 192.168.0.27 sia il gateway.
    Il 192.168.0.66 il client su una rete con maschera /24.

    Lancio tcpdump
    Riporto l' esempio di linux pratico:

    ora.data IP 192.168.0.66 > 66.249.85.104.80 S blabla

    da qui si vede che il client fa richiesta di un indirizzo pubblico (es google).

    Il mio tcpdump restituisce questo:

    ora.data IP 192.168.0.66.1078 > 192.168.0.27.http: S
    ora.data IP 192.168.0.27.http > 192.168.0.66.1078: R

    la S significa che il client cerca di creare una connessione.
    La R non so.
    Nel mio caso il client non fa rischiesta di un indirizzo pubblico ma fa la richiesta all' indirizzo del gateway.

    Da qui deduco che sia un problema di DNS.
    Sul client windows ho impostato l' indirizzo del gateway e i DNS del mio provider.
    Ho provato anche a non impostarli ma non funziona comunque.

    La regola scritta in iptables è:

    iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

    Ho impostato il forwarding come detto + volte
    /opt/sys/net/ipv4/ip_forwarding a 1

    Ho anche provato ad aggiungere le seguenti regole anche se non necessarie:

    iptables -t nat PREROUTING -p tcp -m multiport -s 192.168.0.0/24 --dports 20,21,22,25,80,110,443 -j ACCEPT

    iptables -t nat -A PREROUTING -p tcp -m multiport -s 192.168.0.0/24 --dports 20,21,22,25,80,110,443 -j ACCEPT

    Che devo fare ?
    Credo che il problema sia un impostazione del client, non del gateway.
    Faccio parte di questo mondo, cambiare me stesso significa cambiare il mondo.

  2. #2
    Utente di HTML.it L'avatar di RokStar
    Registrato dal
    Dec 2001
    Messaggi
    937
    Se il client è win ti basta avere una configurazione del genere:
    IP: 192.168.0.quellochevuoi
    Subnet_mask: 255.255.255.0
    Gateway: 192.168.0.numerodelgateway

    DNS:
    setta sia il primario che il secondario

    A lavoro i due client win sono impostati così e funzionano correttamente, con il dns specificato.

    Se settando il dns non va aspetta domani che ti dico come ho configurato la macchina linux che fa da gateway.
    che ce l'hai tre e cinco? Tre e cinco?!?

  3. #3
    IL GATEWAY FUNZIONA MA NON RIESCO A NAVIGARE.
    Riporto tutti gli esoerimenti fatti.
    Saltate pure alla parte finale per capire perchè il gateway funziona ma non riesco a navigare.Ciao!

    ATTENZIONE, NELLA PRIMA PARTE IL GATEWAY NON E' IMPOSTATO

    pingo www.google.com dal gateway (che non è ancora gateway)

    [sirio81@desalitor sirio81]$ ping www.google.com
    PING www.l.google.com (66.102.9.99) 56(84) bytes of data.
    64 bytes from 66.102.9.99: icmp_seq=1 ttl=243 time=279 ms
    64 bytes from 66.102.9.99: icmp_seq=2 ttl=243 time=249 ms
    64 bytes from 66.102.9.99: icmp_seq=3 ttl=243 time=249 ms

    tcpdump -i ppp0

    20595 4/5/5 CNAME www.l.google.com.[|domain]
    13:22:58.413171 IP d81-211-176-208.cust.tele2.it > 66.102.9.147: icmp 64: echo request seq 1
    13:22:58.413715 IP d81-211-176-208.cust.tele2.it.32823 > 10.0.0.1.domain: 47918+ PTR? 147.9.102.66.in-addr.arpa. (43)
    13:22:58.682823 IP 66.102.9.147 > d81-211-176-208.cust.tele2.it: icmp 64: echo reply seq 1
    13:22:58.683040 IP d81-211-176-208.cust.tele2.it.32824 > 10.0.0.1.domain: 58643+ PTR? 147.9.102.66.in-addr.arpa. (43)
    13:23:03.413097 IP d81-211-176-208.cust.tele2.it.32825 > dns1.swip.net.domain: 47918+ PTR? 147.9.102.66.in-addr.arpa. (43)
    13:23:03.632015 IP dns1.swip.net.domain > d81-211-176-208.cust.tele2.it.32825: 47918 NXDomain 0/1/0 (103)
    13:23:03.683057 IP d81-211-176-208.cust.tele2.it.32825 > dns1.swip.net.domain: 58643+ PTR? 147.9.102.66.in-addr.arpa. (43)
    13:23:03.891980 IP dns1.swip.net.domain > d81-211-176-208.cust.tele2.it.32825: 58643 NXDomain 0/1/0 (103)
    13:23:03.892165 IP d81-211-176-208.cust.tele2.it > 66.102.9.147: icmp 64: echo request seq 2
    13:23:04.141937 IP 66.102.9.147 > d81-211-176-208.cust.tele2.it: icmp 64: echo reply seq 2
    13:23:04.142193 IP d81-211-176-208.cust.tele2.it.32825 > 10.0.0.1.domain: 18091+ PTR? 147.9.102.66.in-addr.arpa. (43)

    Ora pingo www.google.com col client con i dns impostati ma sempre col gateway inattivo
    tcpdump -i eth0

    13:25:42.158796 IP 192.168.0.66.1057 > dns1.swip.net.domain: 3278+ A? www.google.com. (32)
    13:25:43.157660 IP 192.168.0.66.1057 > dns2.swip.net.domain: 3278+ A? www.google.com. (32)
    13:25:44.157666 IP 192.168.0.66.1057 > dns1.swip.net.domain: 3278+ A? www.google.com. (32)
    13:25:46.157689 IP 192.168.0.66.1057 > dns1.swip.net.domain: 3278+ A? www.google.com. (32)
    13:25:46.157731 IP 192.168.0.66.1057 > dns2.swip.net.domain: 3278+ A? www.google.com. (32)
    13:25:50.157737 IP 192.168.0.66.1057 > dns1.swip.net.domain: 3278+ A? www.google.com. (32)
    13:25:50.157778 IP 192.168.0.66.1057 > dns2.swip.net.domain: 3278+ A? www.google.com. (32)
    la richiesta arriva ma non torna indierto nulla giustamente.

    Ora provo a pingare sempre www.google.com dal client senza i dns impostati.
    TCPDUMP non restituisce niente, neanche su ppp0.

    ORA PINGO l' IP di google dal client senza aver impostati i dns.
    In questo caso i dns non dovrebbero c' entrare niente.
    ping 66.102.9.99
    sul client vedo "richiesta scaduta"
    su tcpdump -i eth0
    13:35:56.398559 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 1280

    13:36:01.633645 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 1536
    13:36:07.133676 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 1792
    13:36:12.633740 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 2048
    la richeista arriva al gateway inattivo ma non torna indietro nulla.

    ORA ATTIVO IL GATEWAY
    iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADING

    pingo col client l' indirizzo IP di google.
    tcpdump -i eth0
    13:41:18.082211 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 2304
    13:41:18.335638 IP 66.102.9.99 > 192.168.0.66: icmp 40: echo reply seq 2304
    13:41:19.074855 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 2560
    13:41:19.325472 IP 66.102.9.99 > 192.168.0.66: icmp 40: echo reply seq 2560
    13:41:20.074866 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 2816
    13:41:20.325319 IP 66.102.9.99 > 192.168.0.66: icmp 40: echo reply seq 2816
    13:41:21.074878 IP 192.168.0.66 > 66.102.9.99: icmp 40: echo request seq 3072
    13:41:21.325168 IP 66.102.9.99 > 192.168.0.66: icmp 40: echo reply seq 3072
    si vede che il client fa la richiesta (echo request) e che google gli manda la risposta (replay)-
    Quello che mi stupisce è che NON si vede il mascheramento.
    Su LinuxPratico, dopo 192.168.0.66 > 66.102.9.99 ci dovrebbe essere un mascheramento
    mio_ip_pubblico > 66.102.9.99
    poi dovrei ricevere una risposta verso l' ip pubblico
    66.102.9.99 > mio_ip_pubblico
    ed infine redirigere la risposta al client della lan
    mio_ip_pubblico > 192.168.0.66

    Ora provo a pingare www.google.con dal client con i dns impostati:

    tcpdump -i eth0

    13:52:25.069896 IP 192.168.0.66.1057 > dns1.swip.net.domain: 1736+ A? www.google.com. (32)
    13:52:25.324239 IP dns1.swip.net.domain > 192.168.0.66.1057: 1736 4/5/5 CNAME www.l.google.com.,[|domain]
    13:52:25.331714 IP 192.168.0.66 > 66.102.9.104: icmp 40: echo request seq 4352
    13:52:25.594195 IP 66.102.9.104 > 192.168.0.66: icmp 40: echo reply seq 4352
    13:52:26.332772 IP 192.168.0.66 > 66.102.9.104: icmp 40: echo request seq 4608
    13:52:26.574034 IP 66.102.9.104 > 192.168.0.66: icmp 40: echo reply seq 4608
    13:52:27.332802 IP 192.168.0.66 > 66.102.9.104: icmp 40: echo request seq 4864
    13:52:27.573881 IP 66.102.9.104 > 192.168.0.66: icmp 40: echo reply seq 4864
    13:52:28.332798 IP 192.168.0.66 > 66.102.9.104: icmp 40: echo request seq 5120
    13:52:28.583729 IP 66.102.9.104 > 192.168.0.66: icmp 40: echo reply seq 5120
    STESSA STORIA.
    Google ha cambiato IP nel frattempo.
    Il client riceve risposta apparentemente in maniera diretta.
    Ora provo a connettrmi col browser a www.google.com

    13:52:25.069896 IP 192.168.0.66.1057 > dns1.swip.net.domain: 1736+ A? www.google.com. (32)
    13:57:55.571365 IP 192.168.0.66.1069 > 192.168.0.27.http: S 3598635372:3598635372(0) win 65535 <mss 1460,nop,nop,sackOK>
    13:57:55.571415 IP 192.168.0.27.http > 192.168.0.66.1069: R 0:0(0) ack 3598635373 win 0
    13:57:55.946031 IP 192.168.0.66.1069 > 192.168.0.27.http: S 3598635372:3598635372(0) win 65535 <mss 1460,nop,nop,sackOK>
    13:57:55.946077 IP 192.168.0.27.http > 192.168.0.66.1069: R 0:0(0) ack 1 win 0
    13:57:56.492910 IP 192.168.0.66.1069 > 192.168.0.27.http: S 3598635372:3598635372(0) win 65535 <mss 1460,nop,nop,sackOK>
    13:57:56.492954 IP 192.168.0.27.http > 192.168.0.66.1069: R 0:0(0) ack 1 win 0
    NON VA !!!!
    NON RISCHIEDE L' IP DI GOOGLE MA QUELLO DEL GATEWAY.
    E' come se i dns gli avessero detto che google è sul gateway !

    Ora provo a collegarmi col browser scrivendo l' IP di google e non l' indirizzo.
    e ancora
    13:56:20.062956 IP 192.168.0.66.1067 > 192.168.0.27.http: S 1503069995:1503069995(0) win 65535 <mss 1460,nop,nop,sackOK>
    13:56:20.063006 IP 192.168.0.27.http > 192.168.0.66.1067: R 0:0(0) ack 1503069996 win 0
    13:56:20.460521 IP 192.168.0.66.1067 > 192.168.0.27.http: S 1503069995:1503069995(0) win 65535 <mss 1460,nop,nop,sackOK>
    13:56:20.460567 IP 192.168.0.27.http > 192.168.0.66.1067: R 0:0(0) ack 1 win 0
    13:56:21.007405 IP 192.168.0.66.1067 > 192.168.0.27.http: S 1503069995:1503069995(0) win 65535 <mss 1460,nop,nop,sackOK>
    13:56:21.007449 IP 192.168.0.27.http > 192.168.0.66.1067: R 0:0(0) ack 1 win 0

    Secondo me è il client/browser che sbaglia ad inviare le richieste.
    Col ping funziona quindi il gateway funziona.
    Cosa devo fare per riuscire a navigar col simpaticone di windows ?
    Faccio parte di questo mondo, cambiare me stesso significa cambiare il mondo.

  4. #4
    Utente di HTML.it L'avatar di cacao74
    Registrato dal
    Jan 2005
    Messaggi
    2,570
    Prova a fare questa verifica sulla linux box.
    Se il contenuto del file seguente è 1:
    codice:
    cacao74@winnie:~$ cat /proc/sys/net/ipv4/tcp_ecn
    1
    prova ad impostarlo a zero:
    codice:
    cacao74@winnie:~$ su -c 'echo 0 > /proc/sys/net/ipv4/tcp_ecn'
    cacao74@winnie:~$ cat /proc/sys/net/ipv4/tcp_ecn
    0
    Se non risolve la situazione, puoi ripristinarne il valore precedente alla stessa maniera.

    ciao
    slack? smack!

  5. #5
    è già impostato a 0.
    A cosa serve questo file ?
    ciao!
    Faccio parte di questo mondo, cambiare me stesso significa cambiare il mondo.

  6. #6
    Utente di HTML.it L'avatar di cacao74
    Registrato dal
    Jan 2005
    Messaggi
    2,570
    Originariamente inviato da trillullero
    è già impostato a 0.
    A cosa serve questo file ?
    ciao!
    Riporto quanto indicato dalla guida di debian:
    http://www.debian.org/doc/manuals/re...nstall.it.html
    3.7.5 Strani problemi di accesso con alcuni siti web

    I kernel Linux recenti attivano l'ECN di default, cosa che può causare problemi di accesso ad alcuni siti web con dei cattivi routers. Per controllare lo stato dell'ECN:

    # cat /proc/sys/net/ipv4/tcp_ecn
    ... oppure
    # sysctl net.ipv4.tcp_ecn

    Per disattivarlo usate:

    # echo "0" > /proc/sys/net/ipv4/tcp_ecn
    ... oppure
    # sysctl -w net.ipv4.tcp_ecn=0

    Per disabilitare TCP ECN ad ogni boot, aprite /etc/sysctl.conf ed aggiungete:

    net.ipv4.tcp_ecn = 0
    [EDIT]
    Ho premuto invio invece di anteprima, sob!
    http://www.debian.org/News/weekly/2001/21/index.it.html
    "Explicit Congestion Notification". Dopo un aggiornamento dal kernel 2.2.x al 2.4, alcuni siti spariranno totalmente da Internet. La "Explicit Congestion Notification" (ECN) permette ai router di avvisare i client di congestioni della rete, garantendo un minor numero di pacchetti persi e un miglioramento delle prestazioni della rete. Notate che su Internet ci sono parecchi firewall bacati che rifiutano connessioni da macchine con ECN abilitato. Purtroppo potrebbe volerci del tempo prima che tali firewall vengano sistemati. Fino ad allora, per accedere a siti che si trovano dietro firewall di questo tipo (alcuni dei quali sono siti di primaria importanza) dovrete disabilitare tale opzione. Sono stati avviati un paio di dibattiti (ne trovate uno qui e un altro qui) su come ottenere un aggiornamento privo di problemi di un sistema Debian, utilizzando un nuovo kernel 2.4.x con ECN abilitato. Il problema con le immagini di kernel attualmente fornite con Debian pare sia che l'ECN è abilitato per default nel kernel 2.4.x e non viene disabilitato più avanti (/proc/sys/net/ipv4/tcp_ecn).
    [/EDIT]

    ciao
    slack? smack!

  7. #7
    Utente di HTML.it
    Registrato dal
    Jul 2002
    Messaggi
    47
    a me sembra che tu abbia impostato l'indirizzo del gateway come proxy per la connessione internet specificando la porta 80
    Humans are aliens to the rest of the galaxy

  8. #8
    Sono a digiuno di windows, come si fa ad impostare un proxy ?
    Il client è di mio fratello e non so cosa possa avere impostato.
    Io sono sicuro di come ho impostato la rete, il gateway e i dns ma non so il proxy.
    ciao!
    Faccio parte di questo mondo, cambiare me stesso significa cambiare il mondo.

  9. #9
    togliti il dubbio e prova ad installare firefox e vedere un po che succede.
    Anche secondo me è venuto in mente che centri qualcosa il proxy.
    Vai in Strumenti>impostazioni internet>connessioni>impostazioni lan....

  10. #10
    ESATTO !!!!!!!!!!!!!!!
    il problema era che sul client windows c' era impostato di usare il proxy quando il proxy non esiste!!!!
    Tolta l' impostazione il client windows naviga in internet !!!!
    Ciao e GRAZIE !!!!!!
    Faccio parte di questo mondo, cambiare me stesso significa cambiare il mondo.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.