Перенаправление трафика с роутером Rasperry Pi

Я использую Rasperry Pi (работает Rasbian) в качестве маршрутизатора Wi-Fi. Он перенаправляет трафик с проводного Ethernet (eth0 - wire + ppp0 - L2TP-соединение, для него используется lx2tp) на wlan0 (USB-ключ wi-fi, hostapd, используемый для функциональности точки доступа).

И проблема в том, что некоторые сайты загружаются очень медленно или вообще не загружаются. Возьмем, к примеру, soundcloud .com - команда curl -L soundcloud.comвыполняется сразу на самом маршрутизаторе, но навсегда зависает на ноутбуке, подключенном к нему через Wi-Fi. Это должно быть проблема перенаправления трафика.

Вот мой / etc / network / interfaces:

pi@pi ~ $ cat /etc/network/interfaces
auto lo

iface lo inet loopback
iface eth0 inet dhcp

iface wlan0 inet static
    address 192.168.1.1
    netmask 255.255.255.0

up iptables-restore < /etc/iptables.ipv4.nat

И вот правила перенаправления:

pi@pi ~ $ cat 1.sh
sudo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
sudo iptables -A FORWARD -i ppp0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o ppp0 -j ACCEPT
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

Что-то не так с этой настройкой?

UPD:

Таблица маршрутов на Пи:

pi@pi ~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 ppp0
10.89.64.0      *               255.255.248.0   U     0      0        0 eth0
85.21.0.0       10.89.64.1      255.255.255.0   UG    0      0        0 eth0
hdns2.corbina.n 10.89.64.1      255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
hdns1.corbina.n 10.89.64.1      255.255.255.255 UGH   0      0        0 eth0

UPD2:

Оказывается, это не проблема SSL (это из бродячего Ubuntu-бокса на хосте OSX):

vagrant@precise64:~$ curl -v -L soundcloud.com/pure_virtual
* Hostname was NOT found in DNS cache
*   Trying 93.184.220.127...
* Connected to soundcloud.com (93.184.220.127) port 80 (#0)
> GET /pure_virtual HTTP/1.1
> User-Agent: curl/7.38.0
> Host: soundcloud.com
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Sat, 04 Apr 2015 17:38:06 GMT
< Location: https://soundcloud.com/pure_virtual
* Server am/2 is not blacklisted
< Server: am/2
< X-Frame-Options: SAMEORIGIN
< Content-Length: 0
< 
* Connection #0 to host soundcloud.com left intact
* Issue another request to this URL: 'https://soundcloud.com/pure_virtual'
* Found bundle for host soundcloud.com: 0x7f73d4f2d0b0
* Hostname was NOT found in DNS cache
*   Trying 93.184.220.127...
* Connected to soundcloud.com (93.184.220.127) port 443 (#1)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):

* Operation timed out after 0 milliseconds with 0 out of 0 bytes received
* Closing connection 1
curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

Ваша настройка кажется совершенно стандартной. Это означает, что проблема может быть в любом количестве вещей.

Самый прямой способ найти проблему - это посмотреть, как проходит трафик, используя Wireshark - программу, которая позволит вам увидеть, как пакеты передаются с помощью графического интерфейса.

Сначала соберите некоторые данные о Raspberry Pi с помощью следующей команды:

sudo tcpdump -n -w part1.pcap not port 22

(Объяснение: -nФлаг останавливает разрешение DNS, так как нас это не волнует. -w part1.pcapЧасть запишет данные в файл pcap, чтобы мы могли передать их в WireShark позже. Он not port 22отфильтрует трафик SSH, который мы не делаем. не волнует.)

Теперь, запустив эту команду, откройте второе SSH-соединение с Raspberry Pi и выполните команду curl -L soundcloud.com(и другие связанные команды). Как только вы закончите, вернитесь в первое окно SSH и выполните Ctrl + C, чтобы остановить tcpdump. Это создаст part1.pcapфайл.

Для второго раунда сделайте то же самое, но с другим именем файла, например так:

sudo tcpdump -n -w part2.pcap not port 22

Теперь зайдите вручную на soundcloud.com на вашем ПК. После завершения загрузки снова завершите tcpdump, нажав Ctrl + C.

Наконец, загрузите и установите Wireshark на свой компьютер, передайте 2 файла pcap, а затем используйте Wireshark для их просмотра. Сравнивая эти два файла, вы должны найти мощный ключ к пониманию того, что происходит.

Похоже, это проблема фрагментации MTU / пакета, решенная с помощью этого заклинания iptables:

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