Redirecionamento de tráfego com roteador Rasperry Pi

Question

Eu uso um Rasperry Pi (rodando raspbian) como um roteador wi-fi. Ele redireciona o tráfego do fio Ethernet (conexão eth0 - wire + ppp0 - L2TP, lx2tp usado para ele) para wlan0 (dongle wi-fi USB, hostapd usado para a funcionalidade AP).

E o problema é que alguns sites são carregados muito lentos ou não são carregados. Tomemos por exemplo soundcloud .com - o comando curl -L soundcloud.com executa em um piscar de olhos no próprio roteador, mas fica pendurado para sempre em um laptop conectado a ele via Wi-Fi. Deve ser um problema de redirecionamento de tráfego.

Aqui está meu / 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

E aqui estão as regras de redirecionamento:

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"

Há algo de errado com essa configuração?

UPD:

Tabela de rotas no Pi:

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:

Acontece que não é algum problema SSL (que é da caixa do Ubuntu vagrant no host 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

    

Answer 1

Parecia ser um problema de MTU / fragmentação de pacotes, resolvido com esta mágica do iptables:

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

    

Answer 2

Sua configuração parece ser perfeitamente padrão. O que significa que o problema pode ser qualquer coisa.

A maneira mais direta de encontrar o problema seria dar uma olhada em como o tráfego está fluindo usando o Wireshark - um programa que permitirá que você veja como os pacotes estão fluindo usando uma GUI.

Primeiro, capture alguns dados no Raspberry Pi com o seguinte comando:

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

(Explicação: O sinal -n pára a resolução de DNS, pois não nos importamos com isso. A parte -w part1.pcap gravará os dados em um arquivo pcap para que possamos alimentá-los posteriormente com o WireShark. O not port 22 irá filtrar o tráfego SSH, que não nos interessa.)

Agora, com esse comando em execução, abra uma segunda conexão SSH ao Raspberry Pi e execute um curl -L soundcloud.com (e outros comandos relacionados). Quando terminar, volte para a primeira janela do SSH e faça um "Ctrl + C" para parar o tcpdump. Isso criará o arquivo part1.pcap .

Para a segunda rodada, faça a mesma coisa, mas com um nome de arquivo diferente, assim:

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

Agora, navegue manualmente para o soundcloud.com no seu PC. Depois que terminar o carregamento, finalize o tcpdump com "Ctrl + C" novamente.

Por fim, baixe e instale o Wireshark no seu PC, transfira os 2 arquivos pcap e use o Wireshark para visualizá-los. Ao comparar os dois arquivos, você deve encontrar uma pista poderosa sobre o que está acontecendo.