guest debian da caixa virtual com adaptadores nat & host-only: 'No route to host' ao tentar acessar o host do guest

Question

Acabei de configurar um convidado Debian dentro do VirtualBox, em um host Fedora. Eu uso dois adaptadores: NAT (internet para o convidado, que funciona bem) e apenas para host ( ssh do host para convidado, nfs , etc.). Eu sou capaz de ssh de host para convidado, mas não o contrário. Na verdade, exceto ping e traceroute , que fornecem resultados, todas as outras ferramentas relacionadas à rede apresentam o erro: "Nenhuma rota para o host".

Algumas informações:

O IP do host é 192.168.29.1.

axirma@dev:~$ ip addr  

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN  
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00  
inet 127.0.0.1/8 scope host lo  
inet6 ::1/128 scope host  
valid_lft forever preferred_lft forever  
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000  
link/ether 08:00:27:25:1f:71 brd ff:ff:ff:ff:ff:ff  
inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0  
inet6 fe80::a00:27ff:fe25:1f71/64 scope link  
valid_lft forever preferred_lft forever  
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000  
link/ether 08:00:27:6d:16:e6 brd ff:ff:ff:ff:ff:ff  
inet 192.168.29.2/24 brd 192.168.29.255 scope global eth1  
inet6 fe80::a00:27ff:fe6d:16e6/64 scope link  
valid_lft forever preferred_lft forever  
axirma@dev:~$ ip route  
default via 10.0.2.2 dev eth0  
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15  
192.168.29.0/24 dev eth1  proto kernel  scope link  src 192.168.29.2  

axirma@dev:~$ ip route get 192.168.29.1  
192.168.29.1 dev eth1  src 192.168.29.2  
    cache  ipid 0x1910 rtt 7ms rttvar 7ms cwnd 10  

axirma@dev:~$ arp  
Address                  HWtype  HWaddress           Flags Mask            Iface  
10.0.2.2                 ether   52:54:00:12:35:02   C                     eth0  
host                     ether   0a:00:27:00:00:00   C                     eth1  

axirma@dev:~$ ping -c 4 192.168.29.1  
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.  
64 bytes from 192.168.29.1: icmp_req=1 ttl=64 time=0.247 ms  
64 bytes from 192.168.29.1: icmp_req=2 ttl=64 time=0.403 ms  
64 bytes from 192.168.29.1: icmp_req=3 ttl=64 time=0.446 ms  
64 bytes from 192.168.29.1: icmp_req=4 ttl=64 time=0.636 ms  

--- 192.168.29.1 ping statistics ---  
4 packets transmitted, 4 received, 0% packet loss, time 3003ms  
rtt min/avg/max/mdev = 0.247/0.433/0.636/0.138 ms  

axirma@dev:~$ traceroute 192.169.29.1  
traceroute to 192.168.29.1 (192.168.29.1), 30 hops max, 60 byte packets  
 1  host (192.168.29.1)  0.152 ms !X  0.141 ms !X  0.143 ms !X  

axirma@dev:~$ nc -vz 192.168.29.1 22  
host [192.168.29.1] 22 (ssh) : No route to host  

axirma@dev:~$ ssh [email protected]  
ssh: connect to host 192.168.29.1 port 22: No route to host  

Por favor, deixe-me saber se posso fornecer informações adicionais.

    

Answer 1

O problema é que existe um firewall padrão configurado no host Fedora e seu conjunto de regras acaba rejeitando pacotes de entrada da interface de rede somente host do VirtualBox. Se olharmos para as regras abaixo, vemos que icmp pacotes são permitidos. Esta é a razão pela qual ping funciona.

[alexandru@the-host ~]$ sudo iptables -vL -t filter
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 435K  493M ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
   15  1559 ACCEPT     icmp --  any    any     anywhere             anywhere            
   20  1054 ACCEPT     all  --  lo     any     anywhere             anywhere            
   51 11040 ACCEPT     udp  --  any    any     anywhere             224.0.0.251          state NEW udp dpt:mdns
25148 1821K REJECT     all  --  any    any     anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  any    any     anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 332K packets, 39M bytes)
 pkts bytes target     prot opt in     out     source               destination

A possibilidade de um firewall passou pela minha cabeça quando vi !X aparecendo na saída tracerout , sobre a qual a página man diz: 'comunicação administrativamente proibida'. Se observarmos as regras de firewall acima, poderemos ver que os pacotes traceroute udp estavam atingindo a última regra de REJECT abrangentes da corrente INPUT .

Mais tarde, quando depurei com nmap :

axirma@the-guest:~$ nmap -Pn -T4 192.168.57.1

Starting Nmap 6.00 ( http://nmap.org ) at 2013-11-12 16:28 EET
Nmap scan report for 192.168.57.1
Host is up (0.95s latency).
All 1000 scanned ports on 192.168.57.1 are filtered

Nmap done: 1 IP address (1 host up) scanned in 35.69 seconds

Ele disse que todas as portas rastreadas são filtradas, sobre as quais a página principal diz: "... significa que um firewall, filtro ou outro obstáculo da rede está bloqueando a porta".

Depois de entender a saída iptables , ficou claro que eu precisava adicionar uma regra de firewall adicional para que a comunicação desejada ocorresse. Minha solução pessoal é a seguinte adição a /etc/sysconfig/iptables :

-A INPUT -i vboxnet0 -j ACCEPT , pouco antes do todo o REJECT da cadeia INPUT . vboxnet0 é a interface de rede somente de host criada no VirtualBox.