Вопросы Теги

нет исходящего соединения через ipv4

Я наблюдаю странное поведение на моем собственном VPS (Debian 8.6) и, честно говоря, дошел до точки, когда я не знаю, как исследовать это дальше или исправить.

Насколько я понимаю, ОС может обрабатывать только исходящий запрос на адрес IPv6, но не на адрес IPv4:

curl request to google on 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 to google по 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  * * *

curl-запрос к google по 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 to google по 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

Однако странно то, что VPS доступен по IPv4 (веб-сервер и другие службы отвечают на IPv4-адресе).

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

$ 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:"

Моя конфигурация сети: 

$ 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)

У меня есть другой VPS с тем же хостинг-провайдером, и у меня нет проблем на этом.

3
задан 1 October 2016 в 17:50
1 ответ

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

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

и посмотрите, работает ли оно. Кстати, всегда полезно заканчивать свой набор правил правилом протоколирования, чтобы вы могли видеть, что выпадает из конца цепочки и блокируется политикой; что-то вроде

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

Таким образом, если вы обнаружите, что не можете сделать что-то, что, как вы думали, вы должны быть в состоянии, вы сможете увидеть, не обрывается ли какой-либо трафик, который мог бы вызвать проблему.

.
9
ответ дан 3 December 2019 в 04:57

Теги

Похожие вопросы