Mantén l’SSH local quan l’amfitrió executa una VPN de sortida

Un servidor Linux petit executa una VPN de sortida per a l’aplicació que allotja, i l’administrador encara vol arribar-hi per SSH des del despatx del costat. És un requisit raonable, i normalment no necessita ni redirecció de ports, ni adreça del proveïdor, ni cap forat al túnel. El que necessita és un camí de gestió dissenyat a propòsit en lloc d’heretat del que el client VPN hagi fet amb la taula d’encaminament.

Els passos següents assumeixen que l’administrador és a la mateixa LAN.L’administració remota és un problema diferent amb una resposta diferent.

Vincula l’SSH a l’adreça que fan servir els administradors

Comença per l’oient.ss -ltnp | grep :22 mostra a què està lligat sshd, i un oient a 0.0.0.0 accepta connexions de totes les interfícies, inclòs el túnel. Lligar-se a l’adreça de la LAN és més estret i fa visible la intenció:ListenAddress 192.168.10.20 dins de sshd_config, seguit d’una prova de configuració i una recàrrega. Una errata en aquesta adreça és més visible que un comodí, perquè sshd es nega a arrencar quan l’adreça no existeix.

Mantén la comprovació de clau d’amfitrió i l’autenticació per usuari exactament com estan. «Només és la xarxa local» no és un mètode d’autenticació, i un canal de gestió que es salta la verificació de clau perquè la ruta és curta és un canal de gestió esperant ser abusat. Una reserva DHCP o una adreça estàtica fa previsible l’objectiu sense convertir-lo en la identitat pública del servidor.

Mantingues la ruta de la LAN fora del túnel

Un amfitrió amb una adreça a 192.168.10.0/24 té una ruta connectada per a aquest prefix, i una ruta més específica guanya la predeterminada de la VPN dins de la mateixa taula. Per això l’SSH local sovint continua funcionant sol quan el túnel s’aixeca. Verifica-ho en lloc d’assumir-ho:ip route get 192.168.10.50 anomena la interfície i l’adreça d’origen que el nucli faria servir, i la resposta hauria de ser el dispositiu de la LAN, no el túnel. Repeteix la comprovació també des de la màquina de l’administrador, perquè la seva pròpia taula decideix si els paquets arriben alguna vegada. Dos amfitrions al mateix cable poden discrepar sobre quina direcció és abastable.

L’assumpció es trenca en dos llocs. Una regla d’encaminament per política pot enviar trànsit a una taula la predeterminada de la qual apunta al túnel abans que es consulti la taula principal. Un client VPN amb funció de bloqueig o kill-switch també pot bloquejar trànsit que no entra al túnel, sense importar què digui la taula d’encaminament.

Les VLAN de gestió encaminades són l’altre cas. Si l’administrador és a 192.168.50.0/24 darrere del router local, el servidor necessita una ruta explícita per a aquest prefix a través de 192.168.10.1, i aquesta ruta ha de sobreviure a una reconnexió. Mantingues l’excepció específica per al prefix de gestió; una excepció àmplia per a rangs privats anul·la el propòsit del túnel.

Fes l’excepció del tallafoc tan estreta com la regla

Si l’amfitrió executa un tallafoc, permet l’SSH només des de la font de gestió i només a la interfície de la LAN. Una regla que permet el port 22 des de qualsevol lloc és més àmplia que el requisit i més difícil de justificar en una revisió. En un amfitrió nftables la regla va a la cadena d’entrada amb la interfície i la font coincidents; en un amfitrió iptables l’equivalent és un parell de coincidències a -i i -s. Comenta la regla amb el grup d’administradors a qui serveix, perquè la propera auditoria no hagi d’endevinar per què el port 22 és obert.

Comprova també el filtre propi del client VPN. Alguns clients instal·len regles que descarten trànsit local per disseny, i una regla de tallafoc correcta damunt d’un descart a nivell de client no canvia res. Llegeix la configuració del client abans d’editar el tallafoc de l’amfitrió, perquè dos filtres en sèrie produeixen una fallada que no s’assembla a cap dels dos.

Prova tots dos estats

Fes la prova dues vegades: una amb el túnel connectat i una amb el túnel desconnectat. A cada estat, confirma l’oient, la ruta i un inici de sessió SSH real des de la màquina de l’administrador. Un camí que només funciona mentre el túnel és aixecat no és un camí de gestió local; és una coincidència.

Després reinicia el túnel mentre una sessió SSH és oberta. Una sessió que sobreviu demostra que l’encaminament és estable; una sessió que cau et diu que el client reescriu rutes o filtres en reconnectar-se, cosa que val la pena saber abans d’un incident més que durant un.

Anota l’adreça d’origen des de la qual has provat, perquè una regla escrita per a 192.168.10.50 falla en silenci quan l’ordinador portàtil de l’administrador es mou a una altra subxarxa.

Escriu el camí de recuperació al runbook

Decideix ara què passa si la VPN de sortida trenca el camí local. L’accés per consola, una segona adreça de gestió o un procediment documentat per aturar el client són totes respostes legítimes, i qualsevol d’elles és millor que descobrir el problema en el moment que necessites iniciar sessió. Si el servidor és remot, el camí local no existeix, i el disseny correcte és una ruta d’accés remot aprovada i separada o un bastió en lloc d’un port públic exposat.

Mantingues els dos papers separats a la documentació: l’SSH local per a l’administrador que és a prop, i el túnel de sortida per al trànsit de l’aplicació. Quan aquests papers estan escrits, un canvi futur en qualsevol dels dos té un lloc obvi on ser comprovat, i la propera persona no ha de redescobrir per què un servidor amb una VPN encara respon a la seva adreça de la LAN.