Hipervisor del laboratori domèstic inaccessible per VPN: on cal mirar

El túnel s'aixeca, la pàgina web de l'hipervisor es queda sense temps d'espera i el client diu que està connectat. Aquesta combinació descarta moltes coses: l'aplec de mans de la VPN funciona, el client té una adreça i el punt final és abastable. El que queda és una llista curta de qüestions d'encaminament i de política, i tenen un ordre natural. Treballeu-les de l'hipervisor cap enfora i no del client cap endins, perquè l'estat propi de l'hipervisor és el més barat de confirmar.

Comenceu pel segment de gestió

Confirmeu l'adreça de gestió de l'hipervisor i el servei que hi escolta, i confirmeu que la pàgina carrega des d'un altre amfitrió d'aquell segment abans de diagnosticar res de remot. Una prova local que falla no és un problema de VPN, i és una comprovació de cinc minuts que estalvia una hora.

Després, els dos camins. El client de la VPN necessita una ruta cap a la xarxa de gestió, cosa que normalment vol dir que AllowedIPs del client o les rutes empenyades inclouen aquesta subxarxa. L'hipervisor, o la seva passarel·la per defecte, necessita un camí de tornada cap al conjunt d'adreces dels clients, tret que el disseny tradueixi deliberadament la font a l'entrada. Són dos fets separats i la manca de qualsevol dels dos produeix el mateix temps d'espera. Comproveu-los per separat: ip route get 192.168.10.20 al client i una captura a l'amfitrió de l'hipervisor que mostri si el paquet ha arribat o no.

Permeteu l'administrador remot real

L'autorització és una qüestió separada de l'abastabilitat. Feu servir política de passarel·la i d'amfitrió limitada a les fonts i serveis que necessiten accés de gestió. Un compte de VPN de convidat que necessita una aplicació del laboratori no ha d'arribar per això al pla de gestió, i una regla plana que admet tota la subxarxa del túnel és com passa això.

Manteniu activades l'autenticació pròpia de l'hipervisor i les comprovacions de certificat. Una ruta privada no és un motiu per clicar a través d'un avís d'identitat inesperat.

L'avís val la pena tractar-lo com una troballa i no com un obstacle. Si el certificat no coincideix amb el nom que heu fet servir, o el nom és incorrecte o el servei no és el que us penseu, i les dues respostes importen més en una interfície de gestió que a qualsevol altre lloc. Arribeu a la pàgina pel nom pel qual es va emetre el certificat, i deixeu que el DNS apunti aquest nom a l'adreça del túnel. Un nom privat que es resol de manera inconsistent entre la LAN i el túnel és una causa habitual de queixes de certificat que semblen fallades de VPN.

Comproveu les connexions secundàries

Algunes funcions fan servir connexions que la pàgina web no fa servir. Una sessió de consola, una càrrega d'ISO, un proxy VNC o SPICE i un canal de migració poden fer servir cadascun un port diferent o una adreça d'amfitrió diferent. Quan la pàgina carrega i una funció falla, llegiu el requisit d'aquell producte en lloc d'obrir tots els ports de l'amfitrió.

Obrir-ho tot és com una interfície de gestió es converteix en una de no gestionada. Cada port addicional és un altre oient que cal mantenir pedaçat, i un hipervisor ja n'exposa prou. Identifiqueu la connexió concreta que necessita la funció, confirmeu que és abastable a través del túnel i deixeu la resta tancada. Si la funció insisteix a tenir una connexió directa a una adreça d'amfitrió que no és encaminable pel vostre túnel, això és una restricció de disseny que cal esquivar deliberadament, no un motiu per reenviar un rang.

Manteniu un camí de tornada abans de tocar la xarxa

Abans de canviar la xarxa virtual que porta la vostra pròpia VPN, confirmeu que teniu un camí de tornada local o independent.

Això importa més en un laboratori domèstic, perquè el punt final de la VPN sovint és una màquina virtual al mateix hipervisor que intenteu assolir. Canviar un commutador virtual, un pont o una regla de tallafocs de manera remota pot eliminar el camí que feu servir, i la sessió pot sobreviure prou per veure-ho passar.

Proveu des de fora del laboratori i no des de la LAN, i verifiqueu les denegacions així com els permisos. Una xarxa que ha de romandre inabastable des del túnel ha de romandre inabastable després del vostre canvi, i això és una afirmació separada de la càrrega de la pàgina de gestió. Anoteu tots dos resultats, perquè el segon és el que es passa per alt i el que importa quan el laboratori creix.

El registre que cal guardar és curt: l'adreça i el servei de gestió, la ruta que necessita cada costat, les identitats permeses per arribar-hi i el camí de recuperació. Això n'hi ha prou perquè la persona següent reprodueixi l'estat de funcionament sense tornar a deduir-lo.

Si la pàgina encara es queda sense temps després de tot això, feu una captura a l'hipervisor i busqueu el paquet abans de canviar una altra regla. Un paquet que no arriba mai és una qüestió d'encaminament o de tallafocs; un paquet que arriba i es rebutja és una qüestió de servei o de política; un paquet que arriba i rep resposta mentre el client espera és una qüestió de camí de tornada. La documentació de strongSwan sobre reenviament explica com una passarel·la Linux reenvia el tràfic del túnel a un amfitrió intern. Tres captures superen una conjectura més.