LINUX.ORG.RU
решено Форум — Admin  

Не работает tcp/ip forwarding

 ,


1

1

Собственно сервер на Arch linux клиенты pppd в правилах iptables 

iptables -t nat -A POSTROUTING -s 10.5.0.0/24 -j SNAT --to-source 192.168.0.50
/proc/sys/net/ipv4/ip_forward установлен в 1. раньше все работало, у всех был интернет, сегодня почему-то на клиентских машинах пинги/трасерт/nslookup все работает, а сайты не открываются... уже даже идей никаких нет.... мистика какая-то... подскажите че смотреть?



Последнее исправление: c0d3r (всего исправлений: 1)
← Проблема настройки маршрутизации со вторым каналом интернет + IPSec + внутренние сайты
Несколько странных вопросов о OpenVPN →

у самого сервера интернеты работают? другие правила в iptables есть? что меняли прежде чем перестало работать?

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

у самого сервера работает, других правил нет, ничего не менял, история была такая вчера у провайдера были какие-то проблемы, пропал инет, сегодня инет появился но дальше сервера не идет.... машины воткнутые в свич напрямую тоже инет получают, а вот клиенты шлюза моего нет.... не проходят пакеты tcp/ip............................

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

MASQUERADE пробовал, та же история с клиентских машин пинги/трасерт/nslookup все работает, а сайты не открываются...

c0d3r
() автор топика

а, тьфу, пинги и трейсы работают? я чегото прочитал «не работают». тогда попахивает упавшим прокси сервером

redixin ★★★★
()

пинги/трасерт/nslookup все работает, а сайты не открываются.

Уточни - «пинги/трасерт/nslookup» работают в т.ч. и в интернет? Если да, весьма похоже на некорректно выставленный MTU.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

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

ip l 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether e6:e1:c5:5c:df:cd brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether b2:99:26:23:23:a1 brd ff:ff:ff:ff:ff:ff
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1396 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 3
    link/ppp
ip r 
default via 192.168.0.1 dev eth0  metric 202 
10.5.0.10 dev ppp0 proto kernel scope link src 10.5.0.1
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.50  metric 202
ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether e6:e1:c5:5c:df:cd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.50/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::e4e1:c5ff:fe5c:e3d4/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether b2:99:26:23:23:a1 brd ff:ff:ff:ff:ff:ff
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1396 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 10.5.0.1 peer 10.5.0.10/32 scope global ppp0
ip r g 8.8.8.8 
8.8.8.8 via 192.168.0.1 dev eth0  src 192.168.0.50
    cache  ipid 0x5f5f

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

Не в mangle таблицу надо добавлять, а просто в FORWARD. 

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

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

так тоже не работает... теряюсь в догадках....

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

пробовал: делал так на виндовой машине: 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0]
"ProtocolType"=dword:00000800
"PPPProtocolType"=dword:00000021
"TunnelMTU"=dword:00000514

c0d3r
() автор топика

Определяете ip-адрес какого-нибудь сайта, запускаете на сервере tcpdump на перехват пакетов для этого сайта:

tcpdump -i eth33 -n -nn host 1.2.3.4

(понятно, что вместо eth33 нужен интерфейс с адресом 192.168.0.50, вместо 1.2.3.4 ip-адрес сайта в интернете).

Потом пытаетесь открыть сайт с клиентской машины и смотрите какие пакеты были перехвачены. Были ли вобще хоть какие то ответные пакеты от сайта или полная тишина.

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

tcpdump -i eth0 -n -nn host 195.128.127.177 

10:19:16.907123 IP 192.168.0.50.1115 > 195.128.127.177.80: Flags [S], seq 215025434, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:16.907534 IP 192.168.0.50.1116 > 195.128.127.177.80: Flags [S], seq 416804914, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:16.950052 IP 195.128.127.177.80 > 192.168.0.50.1116: Flags [S.], seq 1368414654, ack 416804915, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:16.950070 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:16.955001 IP 195.128.127.177.80 > 192.168.0.50.1115: Flags [S.], seq 523154966, ack 215025435, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:16.955013 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:17.060753 IP 192.168.0.50.1117 > 195.128.127.177.80: Flags [S], seq 3024580209, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:17.106902 IP 195.128.127.177.80 > 192.168.0.50.1117: Flags [S.], seq 3227374672, ack 3024580210, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:17.106913 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:19.856315 IP 192.168.0.50.1115 > 195.128.127.177.80: Flags [S], seq 215025434, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:19.856502 IP 192.168.0.50.1116 > 195.128.127.177.80: Flags [S], seq 416804914, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:19.937855 IP 195.128.127.177.80 > 192.168.0.50.1116: Flags [S.], seq 1368414654, ack 416804915, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:19.937877 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:19.943307 IP 195.128.127.177.80 > 192.168.0.50.1115: Flags [S.], seq 523154966, ack 215025435, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:19.943323 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:20.057645 IP 192.168.0.50.1117 > 195.128.127.177.80: Flags [S], seq 3024580209, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:20.096907 IP 195.128.127.177.80 > 192.168.0.50.1117: Flags [S.], seq 3227374672, ack 3024580210, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:20.096924 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:25.861251 IP 192.168.0.50.1115 > 195.128.127.177.80: Flags [S], seq 215025434, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:25.861462 IP 192.168.0.50.1116 > 195.128.127.177.80: Flags [S], seq 416804914, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:25.935617 IP 195.128.127.177.80 > 192.168.0.50.1116: Flags [S.], seq 1368414654, ack 416804915, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:25.935637 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:25.940567 IP 195.128.127.177.80 > 192.168.0.50.1115: Flags [S.], seq 523154966, ack 215025435, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:25.940583 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56
10:19:26.062963 IP 192.168.0.50.1117 > 195.128.127.177.80: Flags [S], seq 3024580209, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
10:19:26.094495 IP 195.128.127.177.80 > 192.168.0.50.1117: Flags [S.], seq 3227374672, ack 3024580210, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:19:26.094513 IP 192.168.0.50 > 195.128.127.177: ICMP time exceeded in-transit, length 56

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

с сервера: ping -M do -c4 -s 1472 8.8.8.8 

PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
72 bytes from 8.8.8.8: icmp_req=1 ttl=49 (truncated)
72 bytes from 8.8.8.8: icmp_req=2 ttl=48 (truncated)
72 bytes from 8.8.8.8: icmp_req=3 ttl=48 (truncated)
72 bytes from 8.8.8.8: icmp_req=4 ttl=48 (truncated)

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 26.492/29.399/37.389/4.619 ms
большие размеры не проходят, с клиента максимальный: ping ya.ru -f -l 1372 
Обмен пакетами с ya.ru [93.158.134.203] по 1372 байт:

Ответ от 93.158.134.203: число байт=1372 время=6мс TTL=54
Ответ от 93.158.134.203: число байт=1372 время=7мс TTL=54
Ответ от 93.158.134.203: число байт=1372 время=6мс TTL=54
Ответ от 93.158.134.203: число байт=1372 время=6мс TTL=54

Статистика Ping для 93.158.134.203:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 6мсек, Максимальное = 7 мсек, Среднее = 6 мсек
соответственно больше этого пакета не проходят.

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

C 8.8.8.8 так и должно быть. Посмотрите с сервера большие пинги (2000 байт) на ya.ru или mail.ru. Должны проходить.

Хотя пока что проблема с размером пинга не так важна. По выводу tcpdump видно, что возникает «ICMP time exceeded in-transit». Либо ваш сервер как-то неправильно маршрутизирует пакеты к клиенту, либо у вас что-то не так с настройками iptables, либо от провайдера приходят пакеты с TTL равным 1. Добавьте "-v" к опциям tcpdump и посмотрите на пакеты «195.128.127.177.80 > 192.168.0.50». Если в выводе tcpdump значение ttl не единица, значит надо посмотреть, что показывает tcpdump на внтреннем интерфейсе, который смотрит к клиенту.

Вобще, у вас подключение (контракт с провайдером) как для физ. лица на один компьютер или это организация?

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

tcpdump -i eth0 -n -nn -v host 195.128.127.177 

14:08:19.200721 IP (tos 0x0, ttl 64, id 48186, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.100.3489 > 195.128.127.177.80: Flags [S], cksum 0xf925 (correct), seq 1074202, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
14:08:19.251452 IP (tos 0xe0, [b]ttl 1[/b], id 20469, offset 0, flags [DF], proto TCP (6), length 48)
    195.128.127.177.80 > 192.168.0.100.3489: Flags [S.], cksum 0x74ba (correct), seq 1104295464, ack 1074203, win 8192, options [mss 1460,nop,nop,sackOK], length 0
14:08:19.251498 IP (tos 0xc0, ttl 64, id 50630, offset 0, flags [none], proto ICMP (1), length 76)
    192.168.0.100 > 195.128.127.177: ICMP time exceeded in-transit, length 56
        IP (tos 0xe0, ttl 1, id 20469, offset 0, flags [DF], proto TCP (6), length 48)
    195.128.127.177.80 > 192.168.0.100.3489: Flags [S.], cksum 0x74ba (correct), seq 1104295464, ack 1074203, win 8192, options [mss 1460,nop,nop,sackOK], length 0
14:08:19.451189 IP (tos 0x0, ttl 64, id 48188, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.100.3490 > 195.128.127.177.80: Flags [S], cksum 0x4112 (correct), seq 2037293774, win 65535, options [mss 1356,nop,wscale 1,nop,nop,sackOK], length 0
14:08:19.498287 IP (tos 0xe0, [b]ttl 1[/b], id 20554, offset 0, flags [DF], proto TCP (6), length 48)
    195.128.127.177.80 > 192.168.0.100.3490: Flags [S.], cksum 0x8d21 (correct), seq 382636209, ack 2037293775, win 8192, options [mss 1460,nop,nop,sackOK], length 0
14:08:19.498315 IP (tos 0xc0, ttl 64, id 50631, offset 0, flags [none], proto ICMP (1), length 76)
    192.168.0.100 > 195.128.127.177: ICMP time exceeded in-transit, length 56
        IP (tos 0xe0, ttl 1, id 20554, offset 0, flags [DF], proto TCP (6), length 48)
    195.128.127.177.80 > 192.168.0.100.3490: Flags [S.], cksum 0x8d21 (correct), seq 382636209, ack 2037293775, win 8192, options [mss 1460,nop,nop,sackOK], length 0
подключение как физ лица

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

Думаю, что тут достаточно всё ясно. Провайдер препятствует NAT'у пакетов, ставя им ttl 1. Думаю, что поможет правило:

iptables -t mangle -I PREROUTING -i eth0 -p '!' icmp -m ttl --ttl-eq 1 -j TTL --ttl-set 16

Но, советую ещё раз пречитать договор, изучить формулировки о не предоставлении доступа третьим лицам и возможные ответные меры со стороны провайдера. Наверное, лучше хотя бы чуть-чуть замаскироваться добавив правило, устанавливающиее TTL для всех исходящих пакетов одинаковым (примеры в Гугле).

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Проблема настройки маршрутизации со вторым каналом интернет + IPSec + внутренние сайты
Admin
Несколько странных вопросов о OpenVPN →