Назад | Перейти на главную страницу

Блок GW не разрешает доступ в Интернет с внутренних компьютеров

У меня есть относительно новый GW-бокс (CentOS 6.5), который может пинговать www.apple.com. Когда я меняю компьютеры в своей сети, чтобы использовать этот GW в качестве GW по умолчанию, они не могут получить доступ к Интернету. Итак, я снова меняю его на старый GW, и они снова могут получить доступ к Интернету. Внутренние компьютеры - это различные машины под управлением Windows (Vista, Windows 7 и т. Д.) И различные машины под управлением Linux (еще одна коробка CentOS, старая машина RedHat Linux 9 и т. Д.). Итак, мои вопросы:

Как новый GW может пинговать www.apple.com, но внутренние компьютеры, настроенные для использования этого GW, не могут пинговать www.apple.com? Другими словами, почему этот GW не разрешает доступ в Интернет через него?
Какие настройки iptable я могу проверить на новом компьютере GW, чтобы узнать, блокирует ли он его? Я начал с того же iptables со старой машины GW (которая позволяет доступ в Интернет), при необходимости меняя IP-адреса (например, со старого GW IP на новый GW IP).

Спасибо. Просто ищите отправную точку.

РЕДАКТИРОВАТЬ:

[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 ~]#

Обратите внимание, что в iptables есть некоторые настройки, вы просто не можете их увидеть. Например, запуск "iptables -L -t nat -v" позволяет получить различные сопоставления портов.

РЕДАКТИРОВАТЬ 2:

Кроме того, вот таблица маршрутизации (с обфусцированным внешним IP-адресом):

+ 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

Где «AAA», «BBB» и «CC» одинаковы для этих двух внешних IP-адресов.

Кроме того, вот ifconfig (снова с обфусцированным внешним IP-адресом точно так же, как указано выше):

+ 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)

Это интересно, но у eth2 есть внешний IP-адрес, не указанный в маршруте -n. Может ли это быть проблема?

Хорошо, я нашел проблему. Ключ был в том, чтобы запустить следующие команды и посмотреть на результат:

iptables-save и посмотрите вывод. Особое значение имеют любые линии, ссылающиеся на ваши сетевые интерфейсы.
Запустите ifconfig, чтобы настроить интерфейс
Выполните route -n, чтобы получить маршрутизацию. Не обязательно, но это помогло мне увидеть проблему.

Итак, в моем случае у меня был следующий сценарий (до моего исправления):

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
...

Очевидно, я немного запутал внешний IP-адрес и заменил часть вывода ifconfig на «...», чтобы упростить отслеживание. Обратите внимание, что в iptables я ссылался на eth1, но интерфейса eth1 больше не было. Первоначально eth1 ссылался на внешний IP-адрес, но некоторые изменения в нашей системе удалили этот интерфейс и добавили eth2 (это оказался адаптер USB-Ethernet, поэтому я лично думаю, что изменение USB-портов удалило eth1 и добавило eth2). В любом случае, в моем случае простая замена iptables для ссылки на eth2 вместо eth1 устранила мою проблему. Ключевым моментом здесь было указание iptables, как маршрутизировать исходящие пакеты (если только у кого-то нет лучшей интерпретации).

Итак, я изменил iptables с

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

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

Я надеюсь, что это поможет кому-то другому избежать подобной ошибки.