Dónde sale realmente la salida a internet de su VPN gestionada
«Internet incluido» no dice nada sobre dónde sale el tráfico público, quién lo filtra o qué sobrevive a un fallo. Siga la ruta y luego escriba los dos casos de fallo.
No puede decir quién filtra el tráfico público de una sucursal hasta que la propuesta muestre por dónde sale ese tráfico de la red del proveedor. El acceso a internet incluido en una VPN gestionada es un segundo servicio, que va por una ruta con sus propias pasarelas, su propia traducción y su propia cola de escalado. La mayoría de los contratos describen el lado privado con detalle y dejan el lado público en una sola frase. Las comprobaciones de abajo convierten esa frase en un diagrama que puede defender.
Siga un destino público por sede
Elija un host de una sucursal y siga un destino público, anotando la última dirección que pertenece al proveedor y la primera que pertenece a internet. El salto entre esas dos direcciones es la salida, y a menudo no está cerca de la sede que envió el paquete. Marque el dispositivo que hace la transición, porque ese dispositivo tiene el filtro que decide qué sale. Repita el seguimiento desde una segunda sede y compare las direcciones de salida, porque dos sucursales que en la factura parecen idénticas pueden salir por pasarelas distintas en ciudades distintas.
Anote también la dirección de origen que el destino ve en realidad, porque la traducción puede ocurrir en un salto que nunca dibujó. Escriba las respuestas observadas junto a las dibujadas, y la distancia entre ambas es de donde vendrá el primer incidente. Un ingeniero del proveedor que no puede dar la dirección de salida de una sede concreta ya le ha dicho algo útil sobre el diseño.
Tres disposiciones de salida y qué concentra cada una
Una salida central que usted opera lleva el tráfico público a una pasarela propia, lo que le da la política de filtrado y los registros mientras concentra la carga de todas las sedes en un solo circuito. Una salida operada por el proveedor traslada la política y los registros al otro lado del límite contractual, lo que simplifica las operaciones y le quita visibilidad en el mismo movimiento. Una salida en cada sede mantiene el tráfico público local y multiplica el número de superficies de política que deben permanecer idénticas.
| Arrangement | Blast radius of one failure | Address a partner allowlists |
|---|---|---|
| Central exit you operate | Every site, through one circuit and one team | Your own exit pool |
| Provider-run exit | Their shared gateway and its change window | Their NAT pool, often shared |
| Exit at each site | One branch, one local device | Each site's local address |
Pregunte cuál de las tres ofrece realmente el proveedor antes de tratar la lista como un menú, y pregunte si una sede puede pasar de una a otra sin un circuito nuevo. La respuesta sobre la migración separa lo contractual de lo meramente técnico. Anote también quién posee la traducción de origen, porque eso decide qué debe poner un socio en la lista de permitidos. Las pasarelas compartidas también significan capacidad compartida y, a veces, reputación compartida, lo que cambia cómo tratan los socios sus direcciones. La capacidad merece su propia pregunta, porque una pasarela compartida está atendiendo a otros clientes en ese mismo momento.
El filtrado, la traducción y el cifrado tienen propietarios separados
Una ruta establece alcanzabilidad y no dice nada sobre la inspección, así que trate ambas cosas como preguntas distintas con propietarios distintos. Para cada ruta por defecto anunciada, nombre el dispositivo que filtra, el que autentica, el que traduce y el que inspecciona, y luego diga quién administra cada uno. La separación de rutas del proveedor no dice dónde termina el cifrado, y un servicio privado puede acabar su túnel en un límite mientras la salida pública acaba en otro. Pregunte si la traducción ocurre en el borde del proveedor, en una pasarela compartida o en su propia salida, y si existen registros de sesión y durante cuánto tiempo. Cuente los propietarios en las respuestas, porque un contrato que nombra a una parte para cuatro tareas suele dejar tres de ellas sin documentar.
Una ruta por defecto amplia importada al contexto de enrutamiento privado merece el mismo escrutinio, porque una importación es un acuerdo deliberado y no una comodidad inocua. La sección 11 de la RFC 4364 recorre varias disposiciones de acceso a internet para VPN BGP/MPLS y trata el intercambio de rutas entre el contexto VPN y el contexto de reenvío por defecto del proveedor exactamente como ese tipo de acuerdo. Pregunte qué impide que el tráfico público tome una ruta privada por accidente, y obtenga la respuesta junto a la política de rutas y no en una diapositiva.
Dos casos de fallo que acordar antes de firmar
Escriba dos pruebas en el contrato: perder la salida a internet y perder una conexión privada. Para cada una, enumere los recursos internos, los servicios de internet locales y las rutas de gestión que deben seguir funcionando. Luego enumere el camino alternativo que debe permanecer bloqueado, porque un camino que rodea los controles centrales es peor que una interrupción limpia. Dé ambas pruebas al proveedor y pida su resultado esperado por escrito, incluidos la detección y el aviso.
Ejecute las mismas pruebas desde una sede piloto y compárelas con esa respuesta escrita. Donde las dos no coincidan, el contrato describe una red distinta de la que compró. Dos comandos cubren los casos habituales: uno muestra el camino que toma un destino público, el otro muestra la dirección que ve.
traceroute -n 203.0.113.10
curl -s https://example.net/ipAte los compromisos de disponibilidad al segmento que midió, no al nombre del servicio. Un circuito local, una red troncal del proveedor y una pasarela compartida llevan obligaciones separadas y equipos de escalado separados. Las letras L2VPN, L3VPN y MPLS describen un mecanismo de reenvío, no una garantía de extremo a extremo.
Las pruebas vencen a los adjetivos de la propuesta
Palabras como redundante, seguro y resistente describen una intención y no un diseño. Pida en cambio la lista de dispositivos, las ubicaciones de salida, el esquema de traducción y la ruta de notificación. Un proveedor que puede entregar esos cuatro elementos tiene un diseño; el que no puede tiene una diapositiva. Guarde las respuestas en la documentación del servicio y no en un hilo de correo, y revíselas en cada cambio de contrato.
Las disposiciones de salida se mueven en silencio a medida que los proveedores consolidan pasarelas, así que un diagrama de hace tres años es una carga. Cuando un socio informa de una dirección de origen desconocida, debería poder decir en minutos si vino de su diseño o de un cambio que nadie anunció. Esa capacidad, y no los adjetivos, es lo que sobrevive a la primera caída.