Laboratorio VPN con VirtualBox: VM de pasarela ou rede só para o anfitrión

Debe decidir canta maquinaria merece o seu laboratorio VPN. Unha VM de pasarela encamiñada entre dous segmentos de VirtualBox reproduce a tradución de enderezos, o camiño de volta e a posición da devasa detrás da cal se senta un cliente real. Un único segmento só para o anfitrión dálle unha porta controlada e nada máis. A versión con pasarela custa tres convidados e unha táboa de encamiñamento que vostede mantén; a versión só para o anfitrión custa un convidado e unha política. Tres preguntas sepáranas, e a terceira decide se a súa proba pode aprobar sequera.

Responda tres preguntas antes de clonar nada

Comece polo que o servidor VPN ten que observar. Se o servidor debe ver un enderezo de orixe que non é o do convidado de proba, algo ten que traducir entre ambos, e ese algo ten que ser un encamiñador que vostede controle. A rede só para o anfitrión dálle ao anfitrión un adaptador no segmento do convidado, non un tradutor. Cando o convidado necesita alcanzar algo exterior, conecta un adaptador NAT, e o propio motor NAT de VirtualBox reescribe a orixe sen preguntarlle.

Despois pregunte se o convidado pode alcanzar algo excepto a través do túnel. Esa resposta escolle interno ou só para o anfitrión, e é a pregunta que a maioría das descricións de laboratorio omiten. Por último, pregunte que debe ocorrer cando o túnel cae, porque iso decide a política e non a topoloxía, e un laboratorio que só demostra o camiño feliz non probou case nada.

Conecte os tres papeis con redes internas

Use tres convidados e dous segmentos con nome, coa pasarela como a única máquina que ten un adaptador en ambos:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Non hai un paso de creación aparte para unha rede interna. A cadea de --intnet1 é o segmento: dúas máquinas compárteno só se o nome coincide exactamente, e nada do anfitrión está conectado a el. Esa última propiedade é a razón pola que o laboratorio se repite limpo, xa que as rutas do anfitrión, o seu propio cliente VPN e a súa devasa non poden alcanzar os convidados por accidente. Un segmento interno tampouco ten servidor DHCP a menos que engada un, así que os enderezos estáticos son o camiño máis curto.

Dea ao cliente só o seu enderezo WAN, cunha pasarela predeterminada que apunte ao enderezo WAN da pasarela. O servidor recibe un enderezo LAN e usa o enderezo LAN da pasarela como a súa pasarela predeterminada. Un convidado que mantén dous enderezos nun segmento, ou unha ruta perdida cara ao outro segmento, ten un camiño arredor do encamiñador, e as probas de abaixo mentiranlle.

Teño un ficheiro de texto xunto aos nomes das VM coas catro direccións e os dous nomes de segmento, e pégoo en cada shell. Semanas despois, cando un cambio de perfil rompe algo, ese ficheiro é a diferenza entre depurar o perfil e depurar a miña propia memoria.

Escolla interno ou só para o anfitrión para o segmento que non debe filtrarse

O modo só para o anfitrión crea un adaptador virtual no propio anfitrión, normalmente vboxnet0, e dálle ao anfitrión un enderezo no segmento do convidado. Iso é cómodo para a administración e fatal para unha proba de illamento, porque o anfitrión agora pode alcanzar o convidado directamente e cada servizo do lado do anfitrión convértese nun camiño posible. O modo interno non ten ningún adaptador de anfitrión. Os dous modos confúndense facilmente no panel de configuración de rede, así que comprobe a diferenza documentada en lugar da etiqueta (vexa a páxina detalles de rede de VirtualBox).

Para un convidado que debe usar o túnel, o interno é o valor predeterminado máis seguro, coa pasarela como única saída. Se mantén só para o anfitrión, trate o adaptador do anfitrión como un camiño de xestión e dígao en voz alta: o anfitrión pode alcanzar o convidado, e o convidado non debe poder usar o anfitrión como saída.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

O illamento que pode demostrar é o illamento que configurou. Un convidado cun adaptador interno, unha ruta predeterminada na pasarela e ningún adaptador NAT non ten ningún camiño que evite a pasarela. Un convidado cun adaptador só para o anfitrión e un adaptador NAT ten dous camiños, e só un deles é o que quería probar.

Encamiñe e traduza na pasarela, e despois faga que falle pechada

VirtualBox non reenvía entre segmentos; faino o convidado. Coa VM do servidor VPN detrás da pasarela, active o reenvío e traduza o tráfico do cliente mentres sae cara ao servidor:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Con esa regra o servidor ve o enderezo LAN da pasarela en lugar do do cliente, que é como se ve un cliente real detrás dun NAT de operador desde unha cabeceira de rede. Garde o valor de sysctl en /etc/sysctl.d/ e a regra no servizo de devasa que use a distribución, ou un reinicio devolverá o laboratorio en silencio a un estado encamiñado pero non traducido.

O reenvío non é autorización. Baixo a política FORWARD predeterminada de ACCEPT, un convidado cuxa ruta predeterminada apunta á pasarela sae pola interface que elixa a táboa de encamiñamento, con túnel ou sen el. Se a pasarela tamén ten un adaptador NAT para instalar paquetes, ese adaptador é unha saída sen cifrar que funciona no momento en que cae o túnel, e a súa proba só-VPN nunca foi unha proba só-VPN.

Cando o servidor é remoto e é a pasarela a que remata o túnel, a mesma decisión apunta á interface do túnel, non á NIC que chega a internet:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Manteña o transporte exterior propio do túnel e unha ruta de xestión fóra de banda separados do tráfico reenviado. Se a única forma de reparar a pasarela é a través do túnel que está depurando, o laboratorio convértese nun exercicio de bloqueo. Unha consola serie, un adaptador de xestión só para o anfitrión ou unha instantánea dun estado bo coñecido son máis baratos que recuperar a man un encamiñador roto.

Verifique o camiño desde o convidado, non desde o anfitrión

Traballe cara a fóra. Confirme que o cliente alcanza o enderezo WAN da pasarela, despois o servidor a través da pasarela, despois que unha conexión ao porto VPN sae e volve. Unha captura nas dúas interfaces da pasarela mostra se a resposta chega e se descarta no camiño de volta, algo que unha captura só no cliente non pode distinguir:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Despois demostre a saída. Pregunte desde o convidado a un servizo de reflexión de enderezos que orixe ve e compáreo co enderezo de saída da pasarela; se a resposta coincide co enderezo do anfitrión, existe un camiño arredor do túnel. Comprobe que resolutor usa realmente o convidado, e comprobe IPv6 por separado, porque un segmento onde IPv6 está activado mentres o túnel só leva IPv4 filtra por deseño e non por accidente.

Por último, rómpeo a propósito. Deteña o túnel, ou bloquee o seu porto exterior, e abra unha conexión nova desde o convidado. Debe fallar, e o motivo debe ser un que poida nomear: ningunha ruta, unha regra de rexeitamento ou un resolutor morto. Reinicie o túnel e confirme que o convidado se recupera sen reconstruír a rede. Se unha VPN de malla como Hamachi ou ZeroTier comparte o laboratorio, lembre que un adaptador ponte segue o nome do adaptador, non a malla, así que a ponte debe reorientarse despois de que o cliente instale o seu propio adaptador virtual.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Compartir o túnel dun convidado co anfitrión reflicte o problema. Apuntar a ruta predeterminada do anfitrión ao convidado funciona, e tamén un proxy dentro do convidado; o NAT a través do anfitrión non leva o túnel do convidado para o tráfico que o anfitrión orixinou. Garde os nomes dos segmentos e as regras da devasa nun só lugar, faga unha instantánea do estado que funciona e anote o enderezo de orixe que observou o servidor. O seguinte cambio de perfil custará entón unha execución de script en lugar dun laboratorio reconstruído.