☰

Gestión Remota sólo vía VPN en un TL-ER6020

tag-icon • tag-icon vpn tp-link
Gestión Remota sólo vía VPN en un TL-ER6020

Tenemos un TL-ER6020 que estamos configurando en modo "No NAT" (el lado WAN está en una red /30 y enruta una red /29).

Quiero poder "Administrar remotamente" el enrutador, pero quiero evitar que sea accesible a través de HTTP desde el lado WAN.

En un Cisco RV042, había configurado cosas para poder realizar PPTP en el enrutador y luego poder acceder al enrutador a través de su IP interna. Sin embargo, este enrutador tenía NAT configurado.

¿Cuál es la forma correcta de abordar este problema?

Respuesta1

Si tiene acceso al firewall dentro del enrutador, negaría los paquetes HTTP provenientes de la interfaz WAN.

Si el HTTP se acepta desde adentro entonces con el vpn es solo cuestión de conectarse al vpn y luego al acceso remoto.

Respuesta2

Según sus declaraciones, entiendo que tanto las redes internas como las WAN utilizan direcciones IP públicas (debido a que no hay NAT desde el interior a la WAN).

Ahora, como estás hablando de la red interna como una red segura, supongo que el TL-ER6020 está negando/bloqueando todo el tráfico desde la WAN hacia la interna, y tal vez permita conexiones a través de la WAN si se inician en la red interna.

Dicho esto, estos son algunos enfoques de uso general:

  1. Habilite la gestión remota directa de forma segura: para hacerlo de forma eficaz debe:

    1. Utilice únicamente protocolos seguros (HTTP, SSH, etc.)
    2. Bloquea todas las conexiones de WAN al TL-ER6020, excepto el protocolo de gestión segura
    3. Restringir las IP de origen permitidas para conectarse
    4. Utilice un mecanismo de autenticación muy sólido (con SSH, por ejemplo, debe utilizar una clave de autenticación RSA en lugar de una contraseña/frase de contraseña)

    Si se conecta al dispositivo remoto desde una red con IP estáticas y su dispositivo admite estas funciones, esta es una solución factible. Desafortunadamente, el TL-ER6020 parece no poder hacerlo.

  2. Reducción de la superficie de ataque al limitar la conectividad remota al servicio VPN únicamente. Vale la pena señalar que incluso el bloqueo del dispositivo, con excepción de SSH, por ejemplo, reduce la superficie de ataque. Las principales ventajas del enfoque VPN son:

    1. Los servidores/demonios/servicios VPN se consideran más seguros y resistentes que la mayoría de los otros servicios de acceso remoto (Telnet es un claro ejemplo). De todos modos, una buena implementación de SSH o SSL también sería sólida.
    2. De hecho, puede reducir la superficie de ataque cuando permite múltiples servicios: por ejemplo, si permite FTP, HTTP y SSH a través de la VPN, expondría solo el servicio VPN a Internet, reduciendo efectivamente los componentes que necesita mantener en gran medida.

Volviendo a su situación en el mundo real, dado que la opción 1 parece no ser adecuada para su dispositivo, puede optar por una VPN.

Refiriéndose a "En un Cisco RV042, había configurado cosas para poder realizar PPTP en el enrutador y luego poder acceder al enrutador a través de su IP interna. Sin embargo, este enrutador tenía NAT configurado", si las suposiciones sobre su diseño son correcto, solo necesitas iniciar la conexión VPN y luego acceder a la IP pública interna del propio enrutador. En otras palabras, la ausencia de NAT simplemente significaría que usted tendrá que lidiar con las IP reales (probablemente públicas) que asignó a su red interna.

información relacionada