La casella GW non consente l'accesso a Internet da computer interni

Ho una casella relativamente nuova di GW (CentOS 6.5) che può ping www.apple.com. Quando cambio computer all'interno della mia networking per utilizzare questo GW come † default GW, non possono accedere a Internet. Così la cambio di nuovo al vecchio GW e possono accedere nuovamente a Internet. I computer interni sono macchine varie Windows (Vista, Windows 7, ecc.) E varie macchine Linux (un'altra casella CentOS, una vecchia macchina RedHat Linux 9, ecc.). Quindi le mie domande sono:

  1. Come può il nuovo GW ping www.apple.com, ma i computer interni che sono configurati per utilizzare quel GW non possono ping www.apple.com? Mettere un altro modo, perché questo GW non permetterebbe l'accesso a Internet attraverso di essa?
  2. Quali impostazioni iptable posso controllare sulla nuova macchina GW per vedere se questo blocca? Ho iniziato con gli stessi iptables della vecchia macchina GW (che consente l'accesso a internet attraverso), cambiando gli IP in base alle necessità (dal vecchio GW IP al nuovo GW IP, ad esempio).

Grazie. Basta cercare un punto di partenza.

  • yum equivalente di "apt-get purge"
  • controllando la width di banda utilizzando tc
  • Inoltro di porte su Centos 7
  • Telling sendmail all'authentication?
  • Come trovare l'indirizzo IP del gateway in Linux
  • Usa iptables per inoltrare ipv6 a ipv4?
  • EDIT:

    [root@wmsgateway ~]# cat /proc/sys/net/ipv4/ip_forward 1 [root@wmsgateway ~]# iptables -L -n -v Chain INPUT (policy ACCEPT 7175 packets, 739K bytes) pkts bytes target prot opt in out source destination 1 60 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9091 LOG flags 0 level 4 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9093 LOG flags 0 level 4 Chain FORWARD (policy ACCEPT 161 packets, 14106 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6424 packets, 629K bytes) pkts bytes target prot opt in out source destination [root@wmsgateway ~]# 

    Si noti che iptables ha alcune impostazioni, semplicemente non riesci a vederli in questo modo. L'esecuzione di "iptables -L -t nat -v" ottiene i diversi mapping di porte, ad esempio.

    EDIT 2:

    Inoltre, ecco la tabella di routing (con IP esterno obfuscato):

     + route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 68.AAA.BBB.CC2 0.0.0.0 255.255.255.248 U 0 0 0 eth2 192.168.254.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth2 0.0.0.0 68.AAA.BBB.CC3 0.0.0.0 UG 0 0 0 eth2 

    Dove "AAA", "BBB" e "CC" sono le stesse tra questi due IP esterni.

    Inoltre, ecco ifconfig (ancora una volta con l'IP esterno obfuscato nello stesso modo come sopra):

     + ifconfig eth0 Link encap:Ethernet HWaddr 80:3F:5D:08:8F:94 inet addr:192.168.254.80 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::823f:5dff:fe08:8f94/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:410127 errors:0 dropped:0 overruns:0 frame:0 TX packets:385512 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:42227089 (40.2 MiB) TX bytes:37546249 (35.8 MiB) eth2 Link encap:Ethernet HWaddr 00:24:8C:90:99:FB inet addr:68.AAA.BBB.CC5 Bcast:255.255.255.255 Mask:255.255.255.248 inet6 addr: fe80::224:8cff:fe90:99fb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1308912 errors:0 dropped:0 overruns:0 frame:0 TX packets:1192461 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:499876320 (476.7 MiB) TX bytes:179686421 (171.3 MiB) Interrupt:25 Base address:0xe000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:106248 errors:0 dropped:0 overruns:0 frame:0 TX packets:106248 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:105325072 (100.4 MiB) TX bytes:105325072 (100.4 MiB) wlan0 Link encap:Ethernet HWaddr 00:21:00:E3:7E:79 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) 

    È interessante, ma eth2 ha un IP esterno non elencato nella route -n. Potrebbe essere il problema?

  • Aumentare ulimit su CentOS
  • Imansible get Nginx per servire la catena del certificato corretto
  • Come mantenere riservato il codice ssl per il nostro sito web?
  • Apache / SSL: (70014) Fine del file trovato: il filter di input SSL non è riuscito
  • errore: 14094410: routine SSL: SSL3_READ_BYTES: sslv3 avviso di handshake di avviso (35)
  • Che cos'è il process Linux 'SMBD' in esecuzione sul mio server?
  • One Solution collect form web for “La casella GW non consente l'accesso a Internet da computer interni”

    Ok, ho trovato il problema. La chiave era eseguire i seguenti comandi e guardare l'output:

    1. iptables-save e guardare l'output. Di particolare importnza sono tutte le linee che fanno riferimento alle interfacce di networking.
    2. Esegui ifconfig per get l'impostazione dell'interface
    3. Eseguire il path -n per get l'instradamento. Non assolutamente essenziale, ma mi ha aiutato a vedere il problema.

    Quindi, nel mio caso, ho avuto il seguente scenario (prima della mia correzione):

     iptables-save | grep eth -A POSTROUTING -o eth1 -j SNAT --to-source 68.AAA.BBB.155 ifconfig eth0 Link encap:Ethernet HWaddr 80:3F:5D:08:8F:94 inet addr:192.168.254.80 Bcast:192.168.254.255 Mask:255.255.255.0 ... eth2 Link encap:Ethernet HWaddr 00:24:8C:90:99:FB inet addr:68.AAA.BBB.155 Bcast:255.255.255.255 Mask:255.255.255.248 ... lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 ... wlan0 Link encap:Ethernet HWaddr 00:21:00:E3:7E:79 ... 

    Ovviamente ho oscurato l'IP esterno e ho sostituito alcune delle uscite ifconfig con "…" per rendere più semplice seguire. Si noti che in iptables, ho riferito a eth1, ma non c'era più un'interface eth1. Originariamente, eth1 ha fatto riferimento all'IP esterno, ma alcune modifiche nel nostro sistema hanno rimosso quella interface e aggiunto eth2 (questo succede ad essere un adattatore USB a Ethernet, quindi penso personalmente a cambiare le porte USB rimosse eth1 e aggiunto eth2). Comunque, nel mio caso, semplicemente cambiando iptables per riferimento eth2 invece che eth1 fissato il mio problema. La chiave qui stava dicendo iptables come indirizzare i pacchetti in output (a less che qualcun altro abbia una migliore interpretazione).

    Così ho cambiato iptables da

     iptables-save | grep eth -A POSTROUTING -o eth1 -j SNAT --to-source 68.AAA.BBB.155 

    a

     iptables-save | grep eth -A POSTROUTING -o eth2 -j SNAT --to-source 68.AAA.BBB.155 

    Spero che questo aiuti qualcun altro a evitare questo tipo di errore.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.