Cómo configurar el acceso OOB a través de IP


7

Solo dispositivo Cisco IOS en un DC remoto, tengo una conexión OOB entregada en el rack (longitud de Cat5e en mi rack desde otro rack de proveedores en el sitio, que tienen diversas rutas desde la mía, dentro y fuera del edificio) que es simplemente un Conexión L3 a Internet, se entrega un / 29 por él.

El acceso VTY a través de Telnet o SSH generalmente está limitado por una lista de acceso a dispositivos en la red, con IP locales a la red / AS. Este enrutador remoto está en un PoP con circuitos Ethernet de larga distancia de regreso a la red central. La conexión OOB se usaría en emergencias por dispositivos fuera de la red (como un enlace roto, IGP muerto, etc.), con conexiones que provienen potencialmente de cualquier IP o sistema autónomo en todo el mundo.

Si creemos que el dispositivo está configurado de la siguiente manera, con la interfaz OOB configurada con una IP pública del proveedor de conexión OOB;

Interface Fa0/2
 Descriptioc OOB Connection
 ip address 5.5.5.1 255.255.255.248
!
line vty 0 4
 access-class 10
!
access-list 10 remark ACL-ON-NET-MANAGEMENT-IPS
access-list 10 permit 10.0.0.0 0.0.0.255

Mi pregunta es esencial dos realmente;

¿Cómo manejo un escenario durante el cual los dispositivos tienen un L3 derretido, y no puede enrutar el tráfico fuera del PoP porque IGP se ha colapsado o similar; la tabla de enrutamiento se ha vaciado ahora que contiene solo rutas conectadas localmente. Si estoy de vacaciones y me conecto a la IP OOB desde algún Wi-Fi del hotel, el tráfico no tendrá una ruta de regreso a mi IP remota si IGP se ha colapsado y los dispositivos han perdido a sus pares.

Podría poner la interfaz OOB Fa0 / 2 en un VRF y agregar una ruta estática 0/0 a través de la dirección de la puerta de enlace del proveedor OOB dentro del / 29 que me han asignado. Podría cambiar la declaración vty para que sea:

 access-class 10 in vrf-also

Para permitir el acceso de administración desde la interfaz VRF, pero esto chocará con mi ACL. Necesitaría agregar 0/0 a la ACL, eliminando el punto de tener la ACL. ¿Puedo mantener la ACL como está, pero permitir que se conecte cualquier IP cuando se conecte específicamente a la interfaz OOB?

¿Tal vez pueda usar un mapa de ruta de alguna manera para enrutar cualquier tráfico que ingresa desde la interfaz OOB de regreso a través de esa puerta de enlace? O no use un VRF y agregue una ruta 0.0.0.0/0 a la tabla predeterminada con la métrica 254, y agregue un ACL saliente en la interfaz OOB que solo permita el tráfico proveniente del TCP 22 desde la IP de esa interfaz (entonces SSH gestión de tráfico). De esa forma, solo se permitiría el tráfico de gestión. Estoy perdido por la idea aquí.


¿Está utilizando autenticación de dos factores (como Secure-ID) o simplemente simples contraseñas de nombre de usuario para la autenticación de este enrutador?
Mike Pennington

Lo siento, pero hay algo que no puedo entender. ¿Cómo podría evitar 0/0 en ACL 10 si se pregunta cómo conectarse desde la habitación $ HOTEL?
Marco Marzetti

@MikePennington Solo nombre de usuario y contraseña por ahora, para simplificar las cosas durante la prueba
jwbensley

@MarcoMarzetti No sé cómo puedo evitar eso. Este es mi problema, ¿puedo tener una ACL separada para una interfaz en un VRF?
jwbensley

1
¿Aparece este ACL 10 en todos sus VTY? Además, si se está conectando desde un hotel, lo que sea que se esté conectando es darle una dirección IP en su red
fredpbaker

Respuestas:


2

Dependiendo del hardware del que esté hablando, debe tomar diferentes consideraciones.

Por ejemplo, Cisco proporciona un conjunto dedicado de puerto / RAM y flash para acceso OOB en SUP2T, por lo que podrá acceder a su dispositivo incluso cuando RP se cuelgue. OTOH, en algunas cajas de Juniper, el puerto de administración está conectado directamente al RE, por lo que debe colgar fácilmente su enrutador desde allí.

Dicho esto, le recomendaría que coloque un CPE de administración entre sus dispositivos y su acceso a Internet OOB y configure un túnel GRE entre él y su servidor de administración central.


Lamentablemente, la lógica no me permite tener mi escenario deseado. Se requiere un dispositivo separado (y probablemente el mejor). Salud.
jwbensley

1

Estoy lidiando con problemas similares. Desde mi experiencia, lo mejor es tener un procesador de gestión dedicado que siempre sea accesible e independiente del motor de Sup / enrutamiento. No especificó qué tipo de enrutador tiene. En su situación, confiaría en un ASA pequeño (¿5505 quizás?), Conéctelo de forma consecutiva con la interfaz OOB de este enrutador y muestre SSL VPN. No necesita una ruta predeterminada, excepto si desea hacer un monitoreo a través de esta conexión. Y aún necesita la ACL en las líneas VTY.


En este escenario, estoy de acuerdo con fredpbaker en que una caja de salto es probablemente el camino a seguir. Sin embargo, esta es una buena idea, así que gracias por esta idea. Si necesito acceso a más de un dispositivo (solo uno, no es muy común), entonces sigo por esta ruta de un dispositivo separado, pero utilizo un servidor serie.
jwbensley
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.