sem conexão de saída via ipv4

Question

sem conexão de saída via ipv4

#1 resposta do (9 votos)

3

Estou experimentando um comportamento estranho em um VPS que possuo (Debian 8.6) e, honestamente, cheguei a um ponto em que não tenho idéia de como investigá-lo mais ou corrigi-lo.

Até onde eu posso ver, o sistema operacional só é capaz de manipular uma solicitação de saída para um endereço IPv6 e não para um endereço IPv4:

Enrole a solicitação para o Google no IPv4:

$ curl -v -4 google.be
* Rebuilt URL to: google.be/
* Hostname was NOT found in DNS cache
*   Trying 172.217.17.67...
* connect to 172.217.17.67 port 80 failed: Connection timed out
* Failed to connect to google.be port 80: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to google.be port 80: Connection timed out

Traceroute para o Google no IPv4:

$ traceroute 172.217.17.67
traceroute to 172.217.17.67 (172.217.17.67), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Enrole a solicitação para o Google no IPv6:

$ curl -v -6 google.be
* Rebuilt URL to: google.be/
* Hostname was NOT found in DNS cache
*   Trying 2a00:1450:400e:802::2003...
* Connected to google.be (2a00:1450:400e:802::2003) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: google.be
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.be/
< Content-Type: text/html; charset=UTF-8
< Date: Sat, 01 Oct 2016 13:55:01 GMT
< Expires: Mon, 31 Oct 2016 13:55:01 GMT
< Cache-Control: public, max-age=2592000
* Server gws is not blacklisted
< Server: gws
< Content-Length: 218
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.be/">here</A>.
</BODY></HTML>
* Connection #0 to host google.be left intact

traceroute para o google no IPv6:

$ traceroute 2a00:1450:400e:802::2003
traceroute to 2a00:1450:400e:802::2003 (2a00:1450:400e:802::2003), 30 hops max, 80 byte packets
 1  v340.router1.dcga.ams.transip.net (2a01:7c8:aaac::2)  0.493 ms  0.409 ms  0.320 ms
 2  30gigabitethernet1-3.core1.ams1.he.net (2001:7f8:1::a500:6939:1)  11.541 ms  11.581 ms  11.569 ms
 3  amsix-router.google.com (2001:7f8:1::a501:5169:1)  1.531 ms  1.640 ms  1.509 ms
 4  2001:4860:0:f8d::1 (2001:4860:0:f8d::1)  1.500 ms 2001:4860:0:f8c::1 (2001:4860:0:f8c::1)  1.794 ms  1.871 ms
 5  2001:4860:0:1::15a9 (2001:4860:0:1::15a9)  1.774 ms  1.856 ms 2001:4860:0:1::15ad (2001:4860:0:1::15ad)  1.867 ms
 6  ams16s21-in-x03.1e100.net (2a00:1450:400e:802::2003)  1.857 ms  1.606 ms  1.459 ms

O mais estranho é que o VPS pode ser acessado pelo IPv4 (o servidor web e outros serviços respondem no endereço IPv4).

Tanto quanto eu entendo, não tenho regras de firewall nas conexões de saída que poderiam causar isso:

$ sudo iptables -L -n -v
Chain INPUT (policy DROP 76 packets, 4352 bytes)
 pkts bytes target     prot opt in     out     source               destination
 4330  481K LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_IN:"
  664 79865 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 4116  465K ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:10001
   36  2405 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   47  3192 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:86
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 20,21
    9   459 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
   46  5141 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:53
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:25

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_OUT:"
    0     0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_IN:"

Chain OUTPUT (policy ACCEPT 7234 packets, 6355K bytes)
 pkts bytes target     prot opt in     out     source               destination
 6570 6275K LOG        all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_OUT:"

Minha configuração de rede:

$ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:xx:xx:xx
          inet addr:95.170.xx.xx  Bcast:95.170.xx.xx  Mask:255.255.255.0
          inet6 addr: 2a01:7c8:aaac:bb:5054:xx:xx:xx/64 Scope:Global
          inet6 addr: fe80::5054:xx:xx:xx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:309169854 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62960742 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:75197092341 (70.0 GiB)  TX bytes:32195269170 (29.9 GiB)

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:65536  Metric:1
          RX packets:92231464 errors:0 dropped:0 overruns:0 frame:0
          TX packets:92231464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13174664705 (12.2 GiB)  TX bytes:13174664705 (12.2 GiB)

Eu tenho outro VPS com o mesmo provedor de hospedagem e não tenho problemas com isso.

debian ipv4 linux-networking

por KristofM 01.10.2016 / 16:02

1 resposta

Tags debian ipv4 linux-networking

Como dividir um local_action ansible em várias linhas Cluster Redis: 3 nós mestres no mínimo?

score 9 · Accepted Answer

Seu problema não é que seus pacotes de saída sejam bloqueados, mas que as respostas de entrada provocadas por esses pacotes de saída sejam bloqueadas. Tente adicionar uma regra como

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

e veja se isso funciona. A propósito, é sempre uma boa ideia finalizar seu conjunto de regras com uma regra de log, para que você possa ver o que está caindo no final da cadeia e sendo bloqueado pela política; algo como

iptables -A INPUT -j LOG --log-prefix="INPUT DROP: "

Dessa forma, se você descobrir que não pode fazer algo que acha que deveria conseguir, poderá ver se algum tráfego está sendo eliminado e que isso pode estar causando o problema.