nessuna connessione in output tramite ipv4

Sto riscontrando un comportmento strano su un VPS che possiedo (Debian 8.6) e, onestamente, sono giunti ad un punto in cui non ho idea di come approfondire o risolverlo.

Per quanto posso vedere il sistema operativo è in grado di gestire solo una richiesta in output in un indirizzo IPv6 e non in un indirizzo IPv4:

ricall la richiesta di google su 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 a google su 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 * * * 

ricall la richiesta di google su 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 a google su 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 

La cosa strana è che il VPS è raggiungibile su IPv4 (server web e altri servizi rispondono all'indirizzo IPv4).

Per quanto mi riguarda non ho regole di firewall sulle connessioni in output che potrebbero causare questo:

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

La mia configuration di networking:

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

Ho un altro VPS con lo stesso provider di hosting e non ho problemi su quello.

One Solution collect form web for “nessuna connessione in output tramite ipv4”

Il tuo problema non è che i pacchetti in output siano bloccati, ma che le risposte in entrata generate da questi pacchetti in output sono bloccate. Provare ad aggiungere una regola come ad esempio

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

e vedere se ciò fa funzionare le cose. A proposito, è sempre una buona idea terminare le regole di gioco con una regola di logging, in modo da poter vedere cosa sta cadendo alla fine della catena e bloccato dalla policy; qualcosa di simile a

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

In questo modo, se trovate che non puoi fare qualcosa che pensi di poter essere in grado, puoi vedere se si sta cadendo un traffico che potrebbe causare il problema.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.