Accedir a un lloc HTTPS només per VPN mitjançant un reenviament SSH

Una màquina ja té accés VPN aprovat, una segona màquina necessita exactament un servei HTTPS privat, i un reenviament SSH local pot salvar aquesta escletxa sense donar un túnel a la segona màquina. El reenviament transporta una sola destinació TCP en lloc de tota la xarxa, i aquesta limitació és precisament el punt. Feu els cinc passos següents en ordre, perquè cadascun falla per un motiu diferent i un pas posterior no pot rescatar una escletxa anterior. Si falta qualsevol condició prèvia, aquest disseny no la resol i cap ajust de comandes no ho farà.

Pas u: confirmeu les tres condicions prèvies

Tres coses han de ser certes abans que qualsevol comanda importi. Cal permís per fer servir la primera màquina com a amfitrió de reenviament, accés SSH operatiu a ella i una política de servidor que permeti la destinació prevista. Un compte SSH creat per transferir fitxers pot tenir el reenviament desactivat, i un servidor que permet reenviament encara pot restringir quines destinacions són accessibles a través seu. Pregunteu abans de provar, perquè fer servir l'estació de treball d'un col·lega com a punt de salt sense acord és un problema de política, fins i tot quan la comanda funciona perfectament.

Dues comandes resolen la meitat tècnica d'aquesta llista. La primera demostra que el compte i la clau funcionen sense cap indicació interactiva, i la segona imprimeix la política efectiva del servidor en lloc de l'exemple comentat al fitxer de configuració.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Pas dos: enllaceu un port de loopback i manteniu la sessió viva

A la màquina que executa l'aplicació client, obriu un reenviament local cap al servei privat. Enllaceu-lo explícitament al loopback perquè no es publiqui a la xarxa local, i trieu un port alt que cap servei local no ocupi ja. Manteniu la sessió en marxa mentre treballeu, ja que tancar-la tanca l'oient. ExitOnForwardFailure converteix un enllaç refusat o un port ocupat en una sortida immediata en lloc d'una sessió que queda encesa sense reenviament, i aquest és el mode de fallada que fa perdre més temps.

La connexió privada es fa des de l'amfitrió de salt, així que el DNS, les rutes, la política VPN i l'accés al servei d'aquest amfitrió han de funcionar tots. La sessió SSH no crea abastabilitat que l'amfitrió de salt no té, i no pot reparar una ruta que la VPN mai no ha empès. Confirmeu l'oient allà on és realment en lloc de confiar en el silenci de la comanda.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Pas tres: conserveu el nom HTTPS quan el sòcol és local

Navegar a https://127.0.0.1:9443/ canvia el nom del servidor TLS i l'autoritat de l'aplicació. Un certificat emès per a portal.lab.example no validarà contra una adreça de loopback, i l'error resultant sembla un certificat trencat més que una drecera de reenviament. Per a una prova de línia de comandes, conserveu l'URL real i canvieu només la destinació del sòcol. Això és el que fa --connect-to, i el manual de curl documenta la forma de quatre camps que s'utilitza a continuació.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

El nom es queda a l'URL, a l'encaixada de mans TLS i a la capçalera Host, mentre que la connexió TCP va a l'oient local. L'opció sense proxy manté la prova en aquest reenviament en lloc de deixar que un proxy HTTP configurat la intercepti, i mantenir la verificació de certificats activa és el que fa significatiu el resultat.

Pas quatre: sapigueu què no pot cobrir un sol reenviament

Un sol reenviament TCP cobreix un port de destinació. Una pàgina que redirigeix a un segon nom d'amfitrió, carrega recursos d'un amfitrió dins de la xarxa privada o envia a un altre port necessita el seu propi reenviament, i cadascun d'ells necessita la mateixa comprovació de política que el primer. Els fluxos de treball del navegador afegeixen requisits propis, perquè cal dir al navegador que enviï el nom real al port local mitjançant una configuració de proxy o un mapatge local. Per tant, una prova de línia de comandes que té èxit no demostra que el navegador en tindrà, encara que demostri el camí.

UDP, la descoberta SMB i l'inici de sessió de domini no viatgen gens a través d'un reenviament TCP. Si el requisit real és accés general a la xarxa, aquest disseny és l'eina equivocada i una passarel·la d'accés remot admesa és la correcta.

Pas cinc: netegeu i documenteu-ho

Atureu la sessió quan la prova hagi acabat i confirmeu que l'oient ha desaparegut. Si el port triat ja estava ocupat, trieu un altre port de loopback no utilitzat i actualitzeu alhora l'URL, la comanda de prova i la nota, en lloc d'aturar un servei local no relacionat per alliberar el número. Deixar un reenviament obert en un portàtil converteix un diagnòstic en un servei no gestionat.

Anoteu l'amfitrió de salt, la destinació reenviada, el port local i qui va aprovar l'acord. Un reenviament que només existeix a l'historial de shell d'algú és a un reinici d'una investigació repetida, i la següent persona no sabrà quina de les tres condicions prèvies ja s'ha comprovat.