LINUX.ORG.RU
решено Форум — Linux-hardware  

Не проходят ответы из внешней сети.


0

1

Это сообщение связано с решением этой задачи и является её естественным продолжением.

В кратце: настраиваю WiFi точку доступа. С указанием в ручную настроек proxy на машинах во внутренней сети (wlan1) всё работает. WiFi-карточку перевожу в режим точки доступа с помощью hostapd. В качестве DNS- и DHCP-сервера --- dnsmasq. Proxy (прозрачный) --- squid.

Сетевые настройки: 

dvolosnykh@xakac:~$ sudo cat /etc/network/interfaces 
auto lo
iface lo inet loopback

auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
	address 192.168.55.151
	netmask 255.255.255.0
	gateway 192.168.55.1

#iface wlan1 inet dhcp
iface wlan1 inet static
	address 10.42.43.1
	netmask 255.255.255.0


dvolosnykh@xakac:~$ ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:90:f5:8c:4a:ac  
          inet addr:192.168.55.151  Bcast:192.168.55.255  Mask:255.255.255.0
          inet6 addr: fe80::290:f5ff:fe8c:4aac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:496166 errors:0 dropped:5010 overruns:0 frame:0
          TX packets:228179 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:263312390 (263.3 MB)  TX bytes:30584761 (30.5 MB)
          Interrupt:46 

lo        Link encap:Локальная петля (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:13602 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13602 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2390443 (2.3 MB)  TX bytes:2390443 (2.3 MB)

mon.wlan1 Link encap:UNSPEC  HWaddr 00-1D-D9-29-00-6C-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:259941 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:17363856 (17.3 MB)  TX bytes:0 (0.0 B)

wlan1     Link encap:Ethernet  HWaddr 00:1d:d9:29:00:6c  
          inet addr:10.42.43.1  Bcast:10.42.43.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:d9ff:fe29:6c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3797 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3006 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:579087 (579.0 KB)  TX bytes:1021451 (1.0 MB)

dvolosnykh@xakac:~$ iwconfig 
...

wlan1     IEEE 802.11bg  Mode:Master  Frequency:2.412 GHz  Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          
mon.wlan1  IEEE 802.11bg  Mode:Monitor  Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off

Пытаюсь настроить систему (Ubuntu 11.04) в качестве шлюза. 

dvolosnykh@xakac:~$ uname -a
Linux xakac 2.6.38-9-generic #43-Ubuntu SMP Thu Apr 28 15:23:06 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Уже второй вечер не могу настроить сетевой экран с помощью iptables. Насколько я понимаю, при том, что во всех цепочках всех таблиц, действие по-умолчанию --- ACCEPT, то элементарно NAT'ить пакеты можно всего одной строкой: 

iptables --table nat --append POSTROUTING --out-interface eth0 --jump MASQUERADE

Понятно, что до полноценной настройки firewall'а ещё далеко, но мне бы для начала увидеть, что пакеты перенаправляются.

============================================
                 raw
--------------------------------------------
Chain PREROUTING (policy ACCEPT 5 packets, 528 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1 packets, 52 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
============================================
                 mangle
--------------------------------------------
Chain PREROUTING (policy ACCEPT 5 packets, 528 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 5 packets, 528 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1 packets, 52 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1 packets, 52 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
============================================
                 nat
--------------------------------------------
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           
============================================
                 filter
--------------------------------------------
Chain INPUT (policy ACCEPT 5 packets, 528 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1 packets, 52 bytes)
num   pkts bytes target     prot opt in     out     source               destination

На данный момент при ping'е, например, ya.ru утилита tcpdump демонстрирует следующее: 

dvolosnykh@xakac:/etc/hostapd$ sudo tcpdump -i wlan1
...
00:02:54.711482 IP 10.42.43.199 > www.yandex.ru: ICMP echo request, id 1675, seq 11, length 64
00:02:55.717426 IP 10.42.43.199 > www.yandex.ru: ICMP echo request, id 1675, seq 12, length 64
Т.е. не проходят ответы ICMP echo reply.

В то же время при ping'е адреса 192.168.1.1, который находится за шлюзом провайдера (192.168.55.1), ответы проходят. По-моему, это странно. 

00:03:24.319033 IP 10.42.43.199 > inet.icn.bmstu.ru: ICMP echo request, id 1676, seq 1, length 64
00:03:24.319464 IP inet.icn.bmstu.ru > 10.42.43.199: ICMP echo reply, id 1676, seq 1, length 64
00:03:25.321000 IP 10.42.43.199 > inet.icn.bmstu.ru: ICMP echo request, id 1676, seq 2, length 64
00:03:25.321693 IP inet.icn.bmstu.ru > 10.42.43.199: ICMP echo reply, id 1676, seq 2, length 64

См.далее.

← Не работает веб камера Logitech Webcam C160
Проблема с нестандартным vga кабелем →

Не проходят ответы из внешней сети. Продолжение.

В некоторых примерах видел, что нужно добавить путь к шлюзу для внутренней сети, но это не спасает. Делал так: 

dvolosnykh@xakac:~$ sudo route add -net 10.42.43.0 netmask 255.255.255.0 gw 10.42.43.1 dev wlan1
dvolosnykh@xakac:~$ route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.42.43.0      10.42.43.1      255.255.255.0   UG    0      0        0 wlan1
10.42.43.0      0.0.0.0         255.255.255.0   U     0      0        0 wlan1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         192.168.55.1    0.0.0.0         UG    100    0        0 eth0

Хотя, вроде, последней строки должно быть достаточно. Но с маршрутами пока до конца не разобрался.

Собственно, вопрос: что нужно сделать, чтобы дать доступ внутренней подсети по всем протоколам, так же как и машине, работающей в качестве шлюза?

PS. Включить в ядре перенаправление пакетов не забыл: 

dvolosnykh@xakac:~$ sed 's/#.*//;s/^[ \t]*//;s/[ \t]*$//' /etc/sysctl.conf | grep -v '^$'
net.ipv4.ip_forward=1

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

Так в исходном посте же. Просто я писал сценарий настраивающий iptables и распечатывающий их все, в зависимости от параметра командной строки. Поэтому, возможно, вы их, из-за добавленных шапок, и не узнали. Выводил, правда, ещё с ключом -v.

Кстати, ещё вот (с компьютера, подключаемого по WiFi): 

dvolosnykh@xakac-acer:~$ tracepath ya.ru
 1:  xakac-acer                                            0.203ms pmtu 1500
 1:  10.42.43.1                                            0.663ms 
 1:  10.42.43.1                                            1.309ms 
 2:  192.168.55.1                                          1.974ms 
 3:  no reply

Судя по выводу tracepath, проблема с ближайшим ко мне шлюзом местного ISP (192.168.55.1), который я вбиваю статически в настройки eth0. Но в чём проблема, учитывая, что маскарад и перенаправление IP-пакетов с интерфейса на интерфейс включён, не пойму. Ведь они должны выглядеть все одинаково для этого шлюза. Пробовал подделывать TTL в mangle.PREROUTING (устанавливая сразу в 64, и увеличивая на 1), вывод узлов от этого менялся, но дальше ближайшего шлюза всё равно ничего не уходило.

Причём,

dvolosnykh@xakac-acer:~$ nslookup ya.ru
Server:		10.42.43.1
Address:	10.42.43.1#53

Non-authoritative answer:
Name:	ya.ru
Address: 213.180.204.3
Name:	ya.ru
Address: 93.158.134.203
Name:	ya.ru
Address: 93.158.134.3
Name:	ya.ru
Address: 87.250.251.3
Name:	ya.ru
Address: 87.250.250.203
Name:	ya.ru
Address: 87.250.250.3
Name:	ya.ru
Address: 77.88.21.3

Вот карта локальной сети местного провайдера. Я (настраиваемый мной шлюз) --- один из небольших desktop'ов в правом нижнем углу. С него доступно всё. А с компьютера, подключённого к нему ping'уются все узлы левее и ниже верхнего большого switch'а. Не ping'уется всё, что дальше за 192.168.1.1 (сразу под большим верхним switch'ем). Я так понимаю, это самый дальний шлюз местного ISP, дальше уже шлюзы других ISP. Если предположить, что в сетях 195.19.50.64.29 и 89.188.114.64.29 шлюзами являются, соответственно, 195.19.50.65 и 89.18.114.65, то с настраиваемого мной шлюза они ping'уются, а из подсети --- уже нет.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

> Уже второй вечер не могу настроить сетевой экран с помощью iptables. Насколько я понимаю, при том, что во всех цепочках всех таблиц, действие по-умолчанию --- ACCEPT, то элементарно NAT'ить пакеты можно всего одной строкой:

А если все же указать в явном виде?

iptables -A FORWARD -s 192.168.55.0/24 -d 0/0 -j ACCEPT

iptables -A FORWARD -s 10.42.43.0/24 -d 0/0 -j ACCEPT

iptables -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

MTU, судя по выводу ifconfig, одинаковый. Про важность его размера уже читал, на всякий случай пробовал выравнивать с помощью iptables --- не помогало.

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

Попробовал вот так: 

iptables --table mangle --append FORWARD --protocol tcp --tcp-flags RST,SYN SYN --jump TCPMSS --clamp-mss-to-pmtu
iptables -A FORWARD -s 192.168.55.0/24 -d 0/0 -j ACCEPT
iptables -A FORWARD -s 10.42.43.0/24 -d 0/0 -j ACCEPT
iptables -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables --table nat --append POSTROUTING --out-interface eth0 --jump MASQUERADE


============================================
                 raw
--------------------------------------------
Chain PREROUTING (policy ACCEPT 17 packets, 1620 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2 packets, 104 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
============================================
                 mangle
--------------------------------------------
Chain PREROUTING (policy ACCEPT 17 packets, 1620 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 16 packets, 1568 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU 

Chain OUTPUT (policy ACCEPT 2 packets, 104 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 2 packets, 104 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
============================================
                 nat
--------------------------------------------
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           
============================================
                 filter
--------------------------------------------
Chain INPUT (policy ACCEPT 16 packets, 1568 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  *      *       192.168.55.0/24      0.0.0.0/0           
2        0     0 ACCEPT     all  --  *      *       10.42.43.0/24        0.0.0.0/0           
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT 2 packets, 104 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Не помогло.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

Нет обратного преобразования адресов.

Вот вывод tcpdump'а на шлюзе (192.168.55.151) во время ping'ования ya.ru c компьютера в моей подсети:

dvolosnykh@xakac:~$ sudo tcpdump -i eth0 'icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:44:21.535250 IP xakac.icn.bmstu.ru > www.yandex.ru: ICMP echo request, id 2046, seq 111, length 64
20:44:21.579556 IP www.yandex.ru > xakac.icn.bmstu.ru: ICMP echo reply, id 2046, seq 111, length 64
20:44:22.544599 IP xakac.icn.bmstu.ru > www.yandex.ru: ICMP echo request, id 2046, seq 112, length 64
20:44:22.585274 IP www.yandex.ru > xakac.icn.bmstu.ru: ICMP echo reply, id 2046, seq 112, length 64
20:44:23.551327 IP xakac.icn.bmstu.ru > www.yandex.ru: ICMP echo request, id 2046, seq 113, length 64
20:44:23.620216 IP www.yandex.ru > xakac.icn.bmstu.ru: ICMP echo reply, id 2046, seq 113, length 64

Т.е. на шлюз всё приходит, как надо, но пакеты не попадают на интерфейс wlan1.

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

Может, какой строки в таблице маршрутизации не хватает?

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

В таблице route попробуй поставить вес для дефолтного gw побольше, чтобы его строчка гарантировано последней обрабатывалась.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

И убери оттуда все лишние строчки, оставь только:

10.42.43.0 10.42.43.1 255.255.255.0 UG 0 0 0 wlan1
loopback localhost 255.0.0.0 UG 0 0 0 lo
default 192.168.55.1 0.0.0.0 UG 100 0 0 eth0

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Без веса пробовал --- не помогло. Кстати, вес случаем не поменьше должен быть? Пока не очень разобрался, как их выставлять. man ip, конечно, но пока не вкурил.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

Вес должен быть побольше: чем больше, тем маршрут менее желателен обрабатывается.

Как сейчас выглядит route ?

В моей среде всего выше перечисленного было достаточно. Пакеты проходили и возвращались:

echo 1 > /proc/sys/net/iptv4/ip_forward

iptables -t nat -A POSTROUTING -s 10.42.43.0/24 -d 0/0 -j MASQUERADE

iptables -A FORWARD -s 192.168.55.0/24 -d 0/0 -j ACCEPT

iptables -A FORWARD -s 10.42.43.0/24 -d 0/0 -j ACCEPT

iptables -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

route add -net 192.168.55.0/24 gw 192.168.55.1

-- Если все вышесделанное было сделано правильно, то проблемы могут быть в:

1. ядро, может какой-то опции нет?

2. проблема в других сетевых службах (временно остановить их)?

3. проблема специфичная для wifi (можно сделать виртуальный интерфейс ifb0 (модуль ifb) и попробовать с него слать пакеты)?

4. в чем-то другом.

PS: вместо MASQUERADE можно попробовать SNAT, но скорее всего ничего не изменится.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Сейчас route выглядит так: 

dvolosnykh@xakac:~$ route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.42.43.0      0.0.0.0         255.255.255.0   U     0      0        0 wlan1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         192.168.55.1    0.0.0.0         UG    100    0        0 eth0

С вашей последовательностью действий сейчас попробую.

1, 2. Ну, на это я вряд ли смогу ответить... :)

3. На заметку возьму.

SNAT раньше пробовал --- никакого эффекта не наблюдал. Хотя для статических адресов, пишут, предпочтительнее. Ладно, это потом.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

Меня очень смущают 0.0.0.0 в Gateway, в совокупности со строчкой 0.0.0.0 в destination.

Может все-таки попробовать сделать такую таблицу?

10.42.43.0 10.42.43.1 255.255.255.0 UG 0 0 0 wlan1
loopback localhost 255.0.0.0 UG 0 0 0 lo
default 192.168.55.1 0.0.0.0 UG 100 0 0 eth0

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Сделал, как вы пишете --- результата, к сожалению, нет. Тут явно проблема не в iptables и маскараде/NAT'е. Либо route, либо какие-то причуды местной сети. Т.к. предлагаемое решение коррелирует со всеми теми, которые я наблюдал на просторах Сети. Вряд ли все ошибаются...

В общем, проблема локализована: пакеты не переходят по какой-то причине с eth0 на wlan1. Что с этим дальше делать пока вообще не знаю. Поживём --- увидим. В любом случае, спасибо.

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

Мне не даёт покоя 12-ый пункт в инструкции (Activating gateway). Предлагается указать шлюз provider'а, но у меня такая команда не проходит: 

dvolosnykh@xakac:~$ sudo route add -net 10.42.43.0 netmask 255.255.255.0 gw 192.168.55.1 dev wlan1
SIOCADDRT: Нет такого процесса

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

Сделал вот так: 

dvolosnykh@xakac:~$ route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
10.42.43.0      10.42.43.1      255.255.255.0   UG    0      0        0 wlan1
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
0.0.0.0         192.168.55.1    0.0.0.0         UG    100    0        0 eth0
Всё то же самое: застревает на моём шлюзе.

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

Хм... а это не одно и то же? 

dvolosnykh@xakac:~$ man route | grep "deletes the current default route"
              deletes the current default route, which is labeled "default" or 0.0.0.0 in the destination field of the current routing table.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

Дело в опции -n. Вот так вы, наверное, хотели: 

dvolosnykh@xakac:~$ route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
10.42.43.0      xakac.local     255.255.255.0   UG    0      0        0 wlan1
127.0.0.0       xakac           255.0.0.0       UG    0      0        0 lo
default         serv5-2.icn.bms 0.0.0.0         UG    100    0        0 eth0

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

А ничего тут не смущает?

10.42.43.0 10.42.43.1 255.255.255.0 UG 0 0 0 wlan1

wlan1 Link encap:Ethernet HWaddr 00:1d:d9:29:00:6c inet addr:10.42.43.1 Bcast:10.42.43.255 Mask:255.255.255.0

Он же перенаправляется на wlan1 а не во внутреннюю сеть. А куда ему дальше идти? В качестве gw надо указывать роутер. Интерфейс != роутер.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Проведи тест:

Возьми комп подключенный к 10.42.43.1, возьми его адрес 10.42.43.100 (например) и пропиши его в route на 10.42.43.1:

route add -net 10.42.43.0/24 gw 10.42.43.100

и попробуй пингануть что-нибудь.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

При такой таблице route (10.42.43.199 --- клиент шлюза): 

dvolosnykh@xakac:~$ route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
10.42.43.0      10.42.43.199    255.255.255.0   UG    0      0        0 wlan1
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
0.0.0.0         192.168.55.1    0.0.0.0         UG    100    0        0 eth0

Ситуация такая же. На клиенте ping'ую ya.ru. tcpdump'лю на шлюзе: 

dvolosnykh@xakac:~$ sudo tcpdump -ni eth0 'icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:40:08.519535 IP 192.168.55.151 > 93.158.134.3: ICMP echo request, id 2179, seq 1, length 64
00:40:08.535481 IP 93.158.134.3 > 192.168.55.151: ICMP echo reply, id 2179, seq 1, length 64
00:40:09.512360 IP 192.168.55.151 > 93.158.134.3: ICMP echo request, id 2179, seq 2, length 64
00:40:09.529246 IP 93.158.134.3 > 192.168.55.151: ICMP echo reply, id 2179, seq 2, length 64
00:40:10.512376 IP 192.168.55.151 > 93.158.134.3: ICMP echo request, id 2179, seq 3, length 64
00:40:10.543390 IP 93.158.134.3 > 192.168.55.151: ICMP echo reply, id 2179, seq 3, length 64
00:40:11.514009 IP 192.168.55.151 > 93.158.134.3: ICMP echo request, id 2179, seq 4, length 64
00:40:11.547592 IP 93.158.134.3 > 192.168.55.151: ICMP echo reply, id 2179, seq 4, length 64
00:40:12.528624 IP 192.168.55.151 > 93.158.134.3: ICMP echo request, id 2179, seq 5, length 64
00:40:12.541408 IP 93.158.134.3 > 192.168.55.151: ICMP echo reply, id 2179, seq 5, length 64

dvolosnykh@xakac:~$ sudo tcpdump -ni wlan1 'icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan1, link-type EN10MB (Ethernet), capture size 65535 bytes
00:40:08.519499 IP 10.42.43.199 > 93.158.134.3: ICMP echo request, id 2179, seq 1, length 64
00:40:09.512332 IP 10.42.43.199 > 93.158.134.3: ICMP echo request, id 2179, seq 2, length 64
00:40:10.512330 IP 10.42.43.199 > 93.158.134.3: ICMP echo request, id 2179, seq 3, length 64
00:40:11.513981 IP 10.42.43.199 > 93.158.134.3: ICMP echo request, id 2179, seq 4, length 64
00:40:12.528591 IP 10.42.43.199 > 93.158.134.3: ICMP echo request, id 2179, seq 5, length 64

dvolosnykh
() автор топика
Ответ на: комментарий от soomrack

[cite]А ничего тут не смущает?

10.42.43.0 10.42.43.1 255.255.255.0 UG 0 0 0 wlan1

wlan1 Link encap:Ethernet HWaddr 00:1d:d9:29:00:6c inet addr:10.42.43.1 Bcast:10.42.43.255 Mask:255.255.255.0

Он же перенаправляется на wlan1 а не во внутреннюю сеть. А куда ему дальше идти? В качестве gw надо указывать роутер. Интерфейс != роутер. [/cite]

Я с сетями так плотно связался только коснувшись этой проблемы. Поэтому с маршрутами ещё не освоился. Т.е. с таким правилом пакеты заворачиваются обратно на тот интерфейс, с которого пришли?

Если надо указать gw 192.168.55.1, то я выше писал, что такая команда не проходит: 

dvolosnykh@xakac:~$ sudo route add -net 10.42.43.0 netmask 255.255.255.0 gw 192.168.55.1 dev wlan1
SIOCADDRT: Нет такого процесса

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

Правильно, что не проходит, потому что с этого интерфейеса этот адрес не виден.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Да, шлюз (10.42.43.1) и клиент (10.42.43.199) друг друга ping'уют.

PS. Правда таблицу маршрутизации приходится редактировать путём добавления фиктивного шлюза, и лишь потом удалять реальный.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

С клиента даже мой шлюз по внешнему IP (192.168.55.151) ping'уется. А вот уже ближайший шлюз provider'а --- нет.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

> Правда таблицу маршрутизации приходится редактировать путём добавления фиктивного шлюза, и лишь потом удалять реальный.

А вот про это поподробней, пожалуйста.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Ну, сначала 

sudo route add -net 10.42.43.0/24 gw 10.42.43.199
а потом 
sudo route del -net 10.42.43.0/24 gw 10.42.43.1

Если наоборот, то добавить клиента в качестве шлюза не получается. Выдаёт ошибку.

Наткнулся на такое обсуждение (англ.). Проблема по-моему похожа, но пока не понял, как это может сработать.

dvolosnykh
() автор топика
Ответ на: комментарий от dvolosnykh

Дискуссия странная, но это как раз случай, который я реализовывал два дня назад:

qemu связывается с tup0

tup0 я связывал с ifb0 мостом (emerge bridge-utils и brgctl add ...)

ifb0 получал ip 10.2.2.2

внутри qemu ip был 10.2.2.1

Соотв. я добавлял вышеозвученные правила в iptables, и прописывал

route add -net 10.2.2.0/24 gw 10.2.2.1 (ip, который внутри qemu)

и все работало.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Я понял в чём дело :) Услужил мне милый провайдер.

Запускаю tcpdump с подробным выводом (-vv), а там все пакеты с TTL=1 приходят: 

dvolosnykh@xakac:~$ sudo tcpdump -nvvi eth0 'icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:07:58.480713 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.55.151 > 89.188.114.65: ICMP echo request, id 27259, seq 1, length 64
17:07:58.487796 IP (tos 0x0, ttl 1, id 44648, offset 0, flags [DF], proto ICMP (1), length 84)
    89.188.114.65 > 192.168.55.151: ICMP echo reply, id 27259, seq 1, length 64

Ну, я тоже молодец: 

iptables --table mangle --append PREROUTING --in-interface eth0 --jump TTL --ttl-inc 1

Из-за вот этой вот фигни --- столько времени ушло...

dvolosnykh
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Не работает веб камера Logitech Webcam C160
Linux-hardware
Проблема с нестандартным vga кабелем →