Por que não há Internet (Tor + VirtualBox)

Question

Há um página que tem etapas para fazer o VirtualBox funcionar dentro do Tor. Há um script que faz as regras abaixo nesta página.

Após todas as etapas concluídas, estas são as regras como resultado do script (na máquina convidada):

user@host:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
user@host:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
RETURN     all  --  anywhere             192.168.1.0/24      
REDIRECT   udp  --  anywhere             anywhere             udp dpt:domain redir ports 53
REDIRECT   tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN redir ports 9040

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination 

Uma lista de interfaces (na máquina convidada):

user@host:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 08:00:27:0c:35:47 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 85715sec preferred_lft 85715sec
    inet6 fe80::7366:71e1:228d:1f98/64 scope link 
       valid_lft forever preferred_lft forever

user@host:~$ ifconfig 
enp0s3    Link encap:Ethernet  HWaddr 08:00:27:0c:35:47  
          inet addr:172.16.0.148  Bcast:172.16.0.255  Mask:255.255.255.0
          inet6 addr: fe80::7366:71e1:228d:1f98/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59036 errors:0 dropped:0 overruns:0 frame:0
          TX packets:81184 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:15041310 (15.0 MB)  TX bytes:5970833 (5.9 MB)

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:17614 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17614 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1965587 (1.9 MB)  TX bytes:1965587 (1.9 MB)

Como resultado, não há Internet na máquina convidada, mas o ping fornece apenas IPs (Isso pode ser devido ao dnsmasq na máquina host que funciona na porta 53).

Esta é uma saída do nmap ao descobrir a máquina host (na máquina convidada):

user@host:~$ nmap -A 172.16.0.1

Starting Nmap 7.01 ( https://nmap.org ) at 2018-09-20 10:13 EEST
Nmap scan report for 172.16.0.1
Host is up (0.0010s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE    VERSION
22/tcp   open  ssh        OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 ae:64:0e:c7:b8:5d:4a:76:6a:9b:7d:a2:9d:9b:8e:9e (RSA)
|_  256 cd:af:60:19:87:51:b2:ad:33:65:44:97:6a:8f:45:46 (ECDSA)
53/tcp   open  domain     dnsmasq 2.75
| dns-nsid: 
|_  bind.version: dnsmasq-2.75
1717/tcp open  fj-hdnet?
9040/tcp open  tcpwrapped
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 146.15 seconds

Então, como você pode ver, a porta 9040 está aberta na máquina host e vista pela máquina convidada. Tudo somado, o ping dá apenas IPs, mas o curl / ping pára:

user@host:~$ ping google.com
PING google.com (173.194.220.101) 56(84) bytes of data.
...
--- google.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1012ms

user@host:~$ ping google.com -t 1
PING google.com (173.194.220.102) 56(84) bytes of data.
...
--- google.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1024ms

Além disso, como você pode ver, o ping também é interrompido no primeiro salto.

Por que não há conexão com a Internet por meio do Tor na máquina convidada enquanto a máquina hospedeira está? O que poderia ser isso? A propósito, devemos adicionar uma nova regra para descartar todos os pacotes UDP na máquina convidada?