Laboratori VPN amb VirtualBox: VM de passarel·la o xarxa només per a l'amfitrió

Heu de decidir quanta maquinària mereix el vostre laboratori VPN. Una VM de passarel·la encaminada entre dos segments de VirtualBox reprodueix la traducció d'adreces, el camí de tornada i la posició del tallafoc darrere del qual se situa un client real. Un sol segment només per a l'amfitrió us dona una porta controlada i res més. La versió amb passarel·la costa tres convidats i una taula d'encaminament que manteniu; la versió només per a l'amfitrió costa un convidat i una política. Tres preguntes les separen, i la tercera decideix si la vostra prova pot arribar a passar.

Responeu tres preguntes abans de clonar res

Comenceu per allò que el servidor VPN ha d'observar. Si el servidor ha de veure una adreça d'origen que no és la del convidat de prova, alguna cosa ha de traduir entre tots dos, i aquesta cosa ha de ser un encaminador que controleu. La xarxa només per a l'amfitrió dona a l'amfitrió un adaptador al segment del convidat, no un traductor. Quan el convidat després necessita arribar a qualsevol cosa de fora, connecteu un adaptador NAT, i el propi motor NAT de VirtualBox reescriu l'origen sense preguntar-vos.

A continuació, pregunteu si el convidat pot arribar a res excepte a través del túnel. Aquesta resposta tria intern o només per a l'amfitrió, i és la pregunta que la majoria de descripcions de laboratori ometen. Finalment, pregunteu què ha de passar quan el túnel caigui, perquè això decideix la política, no la topologia, i un laboratori que només demostra el camí feliç no ha provat gairebé res.

Connecteu els tres papers amb xarxes internes

Feu servir tres convidats i dos segments amb nom, amb la passarel·la com l'única màquina que té un adaptador a tots dos:

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

No hi ha cap pas de creació separat per a una xarxa interna. La cadena de --intnet1 és el segment: dues màquines el comparteixen només si el nom coincideix exactament, i res de l'amfitrió hi està connectat. Aquesta darrera propietat és la raó per la qual el laboratori es repeteix net, ja que les rutes de l'amfitrió, el seu propi client VPN i el seu tallafoc no poden arribar als convidats per accident. Un segment intern tampoc no té servidor DHCP tret que n'afegiu un, així que les adreces estàtiques són el camí més curt.

Dona al client només la seva adreça WAN, amb una passarel·la per defecte que apunti a l'adreça WAN de la passarel·la. El servidor rep una adreça LAN i utilitza l'adreça LAN de la passarel·la com a passarel·la per defecte. Un convidat que manté dues adreces en un segment, o una ruta esgarriada cap a l'altre segment, té un camí al voltant de l'encaminador, i les proves de sota us mentiran.

Tinc un fitxer de text al costat dels noms de les VM amb les quatre adreces i els dos noms de segment, i el enganxo a cada shell. Setmanes després, quan un canvi de perfil trenca alguna cosa, aquest fitxer és la diferència entre depurar el perfil i depurar la meva pròpia memòria.

Trieu intern o només per a l'amfitrió per al segment que no ha de filtrar-se

El mode només per a l'amfitrió crea un adaptador virtual a l'amfitrió mateix, normalment vboxnet0, i dona a l'amfitrió una adreça al segment del convidat. Això és convenient per a l'administració i fatal per a una prova d'aïllament, perquè l'amfitrió ara pot arribar al convidat directament i cada servei de l'amfitrió es converteix en un camí possible. El mode intern no té cap adaptador d'amfitrió. Els dos modes es confonen fàcilment al tauler de configuració de xarxa, així que comproveu la diferència documentada en lloc de l'etiqueta (vegeu la pàgina detalls de xarxes de VirtualBox).

Per a un convidat que ha d'usar el túnel, l'intern és el valor per defecte més segur, amb la passarel·la com a única sortida. Si manteniu només per a l'amfitrió, tracteu l'adaptador de l'amfitrió com un camí de gestió i digueu-ho en veu alta: l'amfitrió pot arribar al convidat, i el convidat no ha de poder usar l'amfitrió com a sortida.

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

L'aïllament que podeu demostrar és l'aïllament que heu configurat. Un convidat amb un adaptador intern, una ruta per defecte a la passarel·la i cap adaptador NAT no té cap camí que eviti la passarel·la. Un convidat amb un adaptador només per a l'amfitrió i un adaptador NAT té dos camins, i només un d'ells és el que volíeu provar.

Encamineu i traduïu a la passarel·la, i després feu que falli tancada

VirtualBox no reenvia entre segments; ho fa el convidat. Amb la VM del servidor VPN darrere de la passarel·la, activeu el reenviament i traduïu el trànsit del client mentre surt cap al servidor:

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

Amb aquesta regla el servidor veu l'adreça LAN de la passarel·la en lloc de la del client, que és com un client real darrere d'un NAT d'operador es veu des d'un cap de xarxa. Deseu el valor de sysctl a /etc/sysctl.d/ i la regla al servei de tallafoc que faci servir la distribució, o un reinici tornarà el laboratori silenciosament a un estat encaminat però no traduït.

El reenviament no és autorització. Sota la política FORWARD per defecte de ACCEPT, un convidat la ruta per defecte del qual apunta a la passarel·la surt per la interfície que triï la taula d'encaminament, amb túnel o sense. Si la passarel·la també té un adaptador NAT per instal·lar paquets, aquest adaptador és una sortida no xifrada que funciona en el moment que el túnel cau, i la vostra prova només-VPN mai no va ser una prova només-VPN.

Quan el servidor és remot i és la passarel·la qui acaba el túnel, la mateixa decisió apunta a la interfície del túnel, no a la NIC que arriba 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

Manteniu el transport exterior propi del túnel i una ruta de gestió fora de banda separats del trànsit reenviat. Si l'única manera de reparar la passarel·la és a través del túnel que esteu depurant, el laboratori es converteix en un exercici de bloqueig. Una consola sèrie, un adaptador de gestió només per a l'amfitrió o una instantània d'un estat bo conegut són més barats que recuperar a mà un encaminador espatllat.

Verifiqueu el camí des del convidat, no des de l'amfitrió

Treballeu cap enfora. Confirmeu que el client arriba a l'adreça WAN de la passarel·la, després al servidor a través de la passarel·la, després que una connexió al port VPN surt i torna. Una captura a les dues interfícies de la passarel·la mostra si la resposta arriba i es descarta al camí de tornada, cosa que una captura només al client no pot distingir:

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

Després demostreu la sortida. Pregunteu des del convidat a un servei de reflex d'adreces quina font veu i compareu-ho amb l'adreça de sortida de la passarel·la; si la resposta coincideix amb l'adreça de l'amfitrió, existeix un camí al voltant del túnel. Comproveu quin resolutor fa servir realment el convidat, i comproveu IPv6 per separat, perquè un segment on IPv6 està activat mentre el túnel només porta IPv4 filtra per disseny, no per accident.

Finalment, trenqueu-ho expressament. Atureu el túnel, o bloquegeu-ne el port exterior, i obriu una connexió nova des del convidat. Ha de fallar, i el motiu ha de ser un que pugueu anomenar: cap ruta, una regla de rebuig o un resolutor mort. Reinicieu el túnel i confirmeu que el convidat es recupera sense reconstruir la xarxa. Si una VPN de malla com Hamachi o ZeroTier comparteix el laboratori, recordeu que un adaptador pont segueix el nom de l'adaptador, no la malla, així que el pont s'ha de reorientar després que el client instal·li el seu propi adaptador virtual.

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

Compartir el túnel del convidat amb l'amfitrió reflecteix el problema. Apuntar la ruta per defecte de l'amfitrió al convidat funciona, i també un proxy dins del convidat; el NAT a través de l'amfitrió no porta el túnel del convidat per al trànsit que l'amfitrió ha originat. Deseu els noms dels segments i les regles del tallafoc en un sol lloc, feu una instantània de l'estat que funciona i anoteu l'adreça d'origen que el servidor ha observat. El següent canvi de perfil costarà aleshores una execució d'un script en lloc d'un laboratori reconstruït.