{"id":39000,"date":"2019-10-31T22:27:16","date_gmt":"2019-10-31T19:27:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/shifruemsya-po-gostu-pamyatka-po-nastrojke-dinamicheskoj-marshrutizatsii-trafika\/"},"modified":"2019-10-31T22:27:16","modified_gmt":"2019-10-31T19:27:16","slug":"shifruemsya-po-gostu-pamyatka-po-nastrojke-dinamicheskoj-marshrutizatsii-trafika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/shifruemsya-po-gostu-pamyatka-po-nastrojke-dinamicheskoj-marshrutizatsii-trafika","title":{"rendered":"Cifr\u00e1ndonos seg\u00fan GOST: gu\u00eda para configurar el enrutamiento din\u00e1mico del tr\u00e1fico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cifr\u00e1ndonos
\nSi su empresa transmite o recibe datos personales y otra informaci\u00f3n confidencial que debe ser protegida de acuerdo con la legislaci\u00f3n, es necesario aplicar encriptaci\u00f3n seg\u00fan GOST. Hoy les contaremos c\u00f3mo implementamos dicha encriptaci\u00f3n utilizando el gateway criptogr\u00e1fico S-Terra para uno de nuestros clientes. Esta historia ser\u00e1 interesante para especialistas en seguridad de la informaci\u00f3n, as\u00ed como para ingenieros, dise\u00f1adores y arquitectos. No profundizaremos en los matices de la configuraci\u00f3n t\u00e9cnica en este post, sino que nos detendremos en los puntos clave de la configuraci\u00f3n b\u00e1sica. Hay una gran cantidad de documentaci\u00f3n sobre la configuraci\u00f3n de demonios de sistemas operativos Linux, sobre los que se basa el S-Terra, disponible p\u00fablicamente en Internet. La documentaci\u00f3n sobre la configuraci\u00f3n del software propietario S-Terra tambi\u00e9n est\u00e1 disponible al p\u00fablico en portal<\/a><\/noindex> el fabricante.
\n<\/a><\/noindex><\/p>\n

Unas palabras sobre el proyecto <\/h2>\n

\nLa topolog\u00eda de red del cliente era t\u00edpica: full mesh entre la sede central y las sucursales. Era necesario implementar la encriptaci\u00f3n de los canales de intercambio de informaci\u00f3n entre todos los sitios, que eran 8. <\/p>\n

Normalmente, en proyectos como este, todo es est\u00e1tico: se configuran rutas est\u00e1ticas en los gateways criptogr\u00e1ficos (KSh) hacia la red local del sitio, se especifican listas de direcciones IP (ACL) para la encriptaci\u00f3n. Sin embargo, en este caso, los sitios no tienen gesti\u00f3n centralizada, y dentro de sus redes locales puede ocurrir cualquier cosa: las redes pueden ser a\u00f1adidas, eliminadas y modificadas de diversas formas. Para evitar la reconfiguraci\u00f3n de rutas y ACL en los KSh al cambiar la direccionamiento de las redes locales en los sitios, se tom\u00f3 la decisi\u00f3n de utilizar t\u00faneles GRE y enrutamiento din\u00e1mico OSPF, en el que est\u00e1n incluidos todos los KSh y la mayor\u00eda de los routers de n\u00facleo de la red en los sitios (en algunos sitios, los administradores de infraestructura prefirieron utilizar SNAT hacia los KSh en los routers de n\u00facleo). <\/p>\n

El t\u00fanel GRE permiti\u00f3 resolver dos tareas:
\n1.<\/b> Utilizar en las ACL para la encriptaci\u00f3n la direcci\u00f3n IP de la interfaz externa del KSh, en la que se encapsula todo el tr\u00e1fico que se dirige a otros sitios.
\n2.<\/b> Organizar t\u00faneles p-t-p entre los KSh, que permiten configurar el enrutamiento din\u00e1mico (en nuestro caso, se organiz\u00f3 un MPLS L3VPN de proveedor entre los sitios).<\/p>\n

El cliente solicit\u00f3 la implementaci\u00f3n de cifrado como servicio. De lo contrario, tendr\u00eda que no solo mantener los criptoenrutadores o externalizarlo a alguna organizaci\u00f3n, sino tambi\u00e9n monitorear por s\u00ed mismo el ciclo de vida de los certificados de cifrado, renovarlos a tiempo e instalar nuevos.
\n\"Cifr\u00e1ndonos
\nY ahora, en realidad, la nota \u2013 c\u00f3mo y qu\u00e9 configuramos<\/p>\n

Nota para el sujeto del KII: configuramos el criptoenrutador <\/h2>\n

<\/p>\n

Configuraci\u00f3n b\u00e1sica de la red<\/h3>\n

\nPrimero iniciamos el nuevo CE y accedemos a la consola de administraci\u00f3n. Es recomendable comenzar por cambiar la contrase\u00f1a del administrador incorporado \u2014 el comando change user password administrator<\/b>. Luego es necesario llevar a cabo el procedimiento de inicializaci\u00f3n (comando initialize<\/b>) durante el cual se introducen los datos de la licencia y se inicializa el generador de n\u00fameros aleatorios (GNA).<\/p>\n

\u00a1Atenci\u00f3n!<\/u><\/b> Al inicializar el CE S-Terra, se establece una pol\u00edtica de seguridad en la que las interfaces del enrutador de seguridad no permiten paquetes. Es necesario crear una pol\u00edtica propia o activar la pol\u00edtica de permisos preestablecida mediante el comando run csconf_mgr activate<\/b> .
\nA continuaci\u00f3n, es necesario configurar las direcciones de las interfaces externas e internas, as\u00ed como la ruta por defecto. Se recomienda trabajar con la configuraci\u00f3n de red del CE y la configuraci\u00f3n de cifrado a trav\u00e9s de la consola tipo Cisco. Esta consola est\u00e1 dise\u00f1ada para introducir comandos similares a los comandos de Cisco IOS. La configuraci\u00f3n formada mediante la consola tipo Cisco se convierte a su vez en los correspondientes archivos de configuraci\u00f3n, que son manejados por los demonios del sistema operativo. Se puede acceder a la consola tipo Cisco desde la consola de administraci\u00f3n mediante el comando \u2014 simplemente ejecuto<\/b>.<\/p>\n

Cambiamos las contrase\u00f1as del usuario incorporado cscons y enable: <\/p>\n

>enable
\nContrase\u00f1a: csp (preestablecido)
\n#configure terminal
\n#username cscons privilege 15 secret 0 #enable secret 0 \u041d\u0430\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0435\u043c \u0431\u0430\u0437\u043e\u0432\u0443\u044e \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u044e:<\/p>\n

#interface GigabitEthernet0\/0
\n#ip address 10.111.21.3 255.255.255.0
\n#no shutdown
\n#interface GigabitEthernet0\/1
\n#ip address 192.168.2.5 255.255.255.252
\n#no shutdown
\n#ip route 0.0.0.0 0.0.0.0 10.111.21.254<\/p>\n

GRE<\/h3>\n

\nSalimos de la consola tipo Cisco y pasamos a la shell de debian con el comando system<\/b>. Establecemos nuestra propia contrase\u00f1a para el usuario root<\/b> con el comando passwd<\/b>.
\nEn cada CE se configura un t\u00fanel separado para cada sitio. La configuraci\u00f3n de la interfaz de t\u00fanel se realiza en el archivo \/etc\/network\/interfaces<\/b>. La utilidad IP tunnel, que forma parte del conjunto preinstalado iproute2, es responsable de la creaci\u00f3n de la propia interfaz. El comando para crear la interfaz se registra en la opci\u00f3n pre-up.<\/p>\n

Ejemplo de configuraci\u00f3n de una interfaz de t\u00fanel t\u00edpica:
\nauto site1
\niface site1 inet static
\naddress 192.168.1.4
\nnetmask 255.255.255.254
\npre-up ip tunnel add site1 mode gre local 10.111.21.3 remote 10.111.22.3 key hfLYEg^vCh6p<\/p>\n

\u00a1Atenci\u00f3n!<\/u><\/b> Es importante notar que la configuraci\u00f3n de las interfaces de t\u00fanel debe estar fuera de la secci\u00f3n <\/p>\n

###netifcfg-begin###
\n*****
\n###netifcfg-end###<\/p>\n

De lo contrario, esta configuraci\u00f3n se sobrescribir\u00e1 al cambiar la configuraci\u00f3n de las interfaces f\u00edsicas a trav\u00e9s de la consola tipo Cisco.<\/p>\n

Enrutamiento din\u00e1mico<\/h3>\n

\nEn S-Terra, el enrutamiento din\u00e1mico se implementa a trav\u00e9s del paquete de software Quagga. Para configurar OSPF, necesitaremos habilitar y ajustar los demonios zebra<\/b> y ospfd<\/b>. El demonio zebra se encarga de la interacci\u00f3n entre los demonios de enrutamiento y el sistema operativo. El demonio ospfd, como se entiende por su nombre, es responsable de la implementaci\u00f3n del protocolo OSPF.
\nLa configuraci\u00f3n de OSPF se puede realizar a trav\u00e9s de la consola del demonio o directamente a trav\u00e9s del archivo de configuraci\u00f3n \/etc\/quagga\/ospfd.conf<\/b>. En el archivo se a\u00f1aden todas las interfaces f\u00edsicas y de t\u00fanel que participan en el enrutamiento din\u00e1mico, as\u00ed como las redes que se anunciar\u00e1n y recibir\u00e1n anuncios.<\/p>\n

Ejemplo de configuraci\u00f3n que debe a\u00f1adirse a ospfd.conf<\/b>:
\ninterface eth0
\n!
\ninterface eth1
\n!
\ninterface site1
\n!
\ninterface site2
\nrouter ospf
\n ospf router-id 192.168.2.21
\n network 192.168.1.4\/31 area 0.0.0.0
\n network 192.168.1.16\/31 area 0.0.0.0
\n network 192.168.2.4\/30 area 0.0.0.0<\/p>\n

En este caso, las direcciones 192.168.1.x\/31 est\u00e1n reservadas para redes ptp de t\u00faneles entre las ubicaciones, mientras que las direcciones 192.168.2.x\/30 son para redes de tr\u00e1nsito entre el KSH y los enrutadores centrales. <\/p>\n

\u00a1Atenci\u00f3n!<\/b><\/u> Para reducir la tabla de enrutamiento en instalaciones grandes, se puede filtrar el anuncio de las propias redes de tr\u00e1nsito mediante construcciones no redistribute connected<\/b> o redistribute connected route-map<\/b>.<\/p>\n

Despu\u00e9s de configurar los demonios, es necesario cambiar el estado de inicio de los demonios en \/etc\/quagga\/daemons<\/b>. En las opciones zebra<\/b> y ospfd<\/b> no se corrige a yes. Iniciar el demonio quagga y habilitar su inicio autom\u00e1tico al arrancar el KSH con el comando update-rc.d quagga enable<\/b>.<\/p>\n

Si la configuraci\u00f3n de los t\u00faneles GRE y OSPF se ha realizado correctamente, deber\u00edan aparecer rutas en el KSH y en los enrutadores centrales en la red de las otras ubicaciones, y as\u00ed establecer conectividad de red entre las redes locales.<\/p>\n

Ciframos el tr\u00e1fico transmitido <\/h3>\n

\nComo ya se mencion\u00f3, generalmente al cifrar entre plataformas, especificamos rangos de direcciones IP (ACL) entre los cuales se cifra el tr\u00e1fico: si las direcciones de origen y destino est\u00e1n dentro de estos rangos, el tr\u00e1fico entre ellas se cifra. Sin embargo, en este proyecto la estructura es din\u00e1mica y las direcciones pueden cambiar. Como ya hemos configurado un t\u00fanel GRE, podemos usar las direcciones externas de la red de control (\u041a\u0428) como direcciones de origen y destino para cifrar el tr\u00e1fico, ya que el tr\u00e1fico que se cifra ya est\u00e1 encapsulado por el protocolo GRE. En otras palabras, se cifra todo lo que llega a la red de control desde la red local de una plataforma hacia redes que han sido anunciadas por otras plataformas. Y dentro de cada una de las plataformas se puede realizar cualquier redirecci\u00f3n. As\u00ed, ante cualquier cambio en las redes locales, el administrador solo necesita modificar los anuncios que van desde su red hacia la red de control, y esta se volver\u00e1 accesible para otras plataformas.<\/p>\n

El cifrado en la red de control S-Terra se realiza a trav\u00e9s del protocolo IPSec. Utilizamos el algoritmo 'Grasshopper' de acuerdo con GOST R 34.12-2015, y para la compatibilidad con versiones m\u00e1s antiguas se puede aplicar GOST 28147-89. La autenticaci\u00f3n puede llevarse a cabo t\u00e9cnicamente tanto con claves predefinidas (PSK) como con certificados. Sin embargo, en la explotaci\u00f3n industrial es necesario usar certificados emitidos de acuerdo con GOST R 34.10-2012.<\/p>\n

El trabajo con certificados, contenedores y CRL se realiza mediante la utilidad cert_mgr<\/b>. Primero, con el comando cert_mgr create<\/b> , es necesario crear el contenedor de clave privada y la solicitud de certificado, que se enviar\u00e1 al Centro de gesti\u00f3n de certificados. Despu\u00e9s de recibir el certificado, este, junto con el certificado ra\u00edz de la CA y el CRL (si se utiliza), debe importarse con el comando cert_mgr import<\/b>. Se puede verificar que todos los certificados y CRL se instalaron correctamente con el comando cert_mgr show<\/b>.<\/p>\n

. Tras la instalaci\u00f3n exitosa de los certificados, pasamos a la consola tipo Cisco para configurar IPSec.
\nCreamos una pol\u00edtica IKE, en la que se especifican los algoritmos y par\u00e1metros deseados del canal seguro que se propondr\u00e1n al socio para la negociaci\u00f3n. <\/p>\n

#crypto isakmp policy 1000
\n#encr gost341215k
\n#hash gost341112-512-tc26
\n#authentication sign
\n#group vko2
\n#lifetime 3600<\/p>\n

Esta pol\u00edtica se aplica al establecer la primera fase de IPSec. El resultado de pasar exitosamente la primera fase es el establecimiento de SA (Asociaci\u00f3n de Seguridad).
\nA continuaci\u00f3n, necesitaremos definir la lista de direcciones IP de origen y receptor (ACL) para el cifrado, crear un conjunto de transformaciones (transform set), establecer un mapa criptogr\u00e1fico (crypto map) y vincularlo a la interfaz externa del K\u0421H. <\/p>\n

Establecemos ACL:
\n#ip access-list extended site1
\n#permit gre host 10.111.21.3 host 10.111.22.3<\/p>\n

Conjunto de transformaciones (al igual que en la primera fase, utilizamos el algoritmo de cifrado \u00abGrasshopper\u00bb en modo de producci\u00f3n de inserci\u00f3n de firma):<\/p>\n

#crypto ipsec transform-set GOST esp-gost341215k-mac<\/p>\n

Creamos el mapa criptogr\u00e1fico, especificando ACL, el conjunto de transformaciones y la direcci\u00f3n del par:<\/p>\n

#crypto map MAIN 100 ipsec-isakmp
\n#match address site1
\n#set transform-set GOST
\n#set peer 10.111.22.3<\/p>\n

Vinculamos el mapa criptogr\u00e1fico a la interfaz externa del K\u0421H:<\/p>\n

#interface GigabitEthernet0\/0
\n#ip address 10.111.21.3 255.255.255.0
\n#crypto map MAIN<\/p>\n

Para cifrar canales con otros sitios, es necesario repetir el procedimiento de creaci\u00f3n del ACL y del mapa criptogr\u00e1fico, cambiando el nombre del ACL, las direcciones IP y el n\u00famero del mapa criptogr\u00e1fico.<\/p>\n

\u00a1Atenci\u00f3n! <\/u><\/b>En caso de que no se utilice la comprobaci\u00f3n de certificados a trav\u00e9s de CRL, esto debe indicarse expl\u00edcitamente:<\/p>\n

#crypto pki trustpoint s-terra_technological_trustpoint
\n#revocation-check none<\/p>\n

Monitoreamos la \u00absalud\u00bb del sistema<\/h2>\n

\nEn el K\u0421H S-Terra, se utiliza el demonio est\u00e1ndar snmpd para la monitorizaci\u00f3n. Adem\u00e1s de los par\u00e1metros t\u00edpicos de Linux, S-Terra admite \u00about-of-the-box\u00bb la emisi\u00f3n de datos sobre los t\u00faneles IPSec de acuerdo con CISCO-IPSEC-FLOW-MONITOR-MIB, que utilizamos para rastrear el estado de los t\u00faneles IPSec. Tambi\u00e9n se admite la funcionalidad de OID personalizados que emiten como valores los resultados de la ejecuci\u00f3n de un script. Esta capacidad nos permite rastrear los plazos de caducidad de los certificados. El script escrito analiza la salida del comando cert_mgr show<\/b> y como resultado devuelve la cantidad de d\u00edas hasta la caducidad de los certificados local y ra\u00edz. Este enfoque es indispensable para administrar un gran n\u00famero de K\u0421H.
\n\"Cifr\u00e1ndonos
\n<\/p>\n

\u00bfCu\u00e1l es la esencia de este cifrado?<\/h2>\n

\nToda la funcionalidad descrita anteriormente est\u00e1 soportada 'de f\u00e1brica' por el KSH S-Terra. Es decir, no fue necesario instalar m\u00f3dulos adicionales que pudieran afectar la certificaci\u00f3n de los criptogateways y la validaci\u00f3n de todo el sistema de informaci\u00f3n. Los canales entre las plataformas pueden ser cualquier tipo, incluso a trav\u00e9s de Internet. <\/p>\n

Gracias a que no es necesario reconfigurar los criptogateways al cambiar la infraestructura interna, el sistema funciona como un servicio<\/b>, lo que es muy conveniente para el cliente: puede ubicar sus servicios (tanto los del cliente como los del servidor) en cualquier direcci\u00f3n, y todos los cambios se transmitir\u00e1n din\u00e1micamente entre el equipo de cifrado. <\/p>\n

Sin duda, el cifrado debido a los gastos operativos (overhead) afecta la velocidad de transmisi\u00f3n de datos, pero de manera insignificante: el ancho de banda del canal puede disminuir como m\u00e1ximo entre un 5 y un 10%. Adem\u00e1s, la tecnolog\u00eda ha sido probada y ha mostrado buenos resultados incluso en canales satelitales, que son bastante inestables y tienen un bajo ancho de banda. <\/p>\n

Igor Vinokhodov, ingeniero de segunda l\u00ednea de administraci\u00f3n en 'Rostelecom-Solar'<\/i>
\n
Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0415\u0441\u043b\u0438 \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0451\u0442 \u0438\u043b\u0438 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442 \u043f\u043e \u0441\u0435\u0442\u0438 \u043f\u0435\u0440\u0441\u0434\u0430\u043d\u043d\u044b\u0435 \u0438 \u0434\u0440\u0443\u0433\u0443\u044e \u043a\u043e\u043d\u0444\u0438\u0434\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u0443\u044e \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e, \u043f\u043e\u0434\u043b\u0435\u0436\u0430\u0449\u0443\u044e \u0437\u0430\u0449\u0438\u0442\u0435 \u0432 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0438 \u0441 \u0437\u0430\u043a\u043e\u043d\u043e\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e\u043c, \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0442\u044c \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u043e \u0413\u041e\u0421\u0422\u0443. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0432\u043d\u0435\u0434\u0440\u0438\u043b\u0438 \u0442\u0430\u043a\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0448\u043b\u044e\u0437\u0430 (\u041a\u0428) S-Terra \u0443 \u043e\u0434\u043d\u043e\u0433\u043e \u0438\u0437 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u043e\u0432. \u042d\u0442\u0430 \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u0431\u0443\u0434\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430 \u0418\u0411-\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430\u043c, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430\u043c, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440\u0430\u043c. \u0413\u043b\u0443\u0431\u043e\u043a\u043e \u043f\u043e\u0433\u0440\u0443\u0436\u0430\u0442\u044c\u0441\u044f \u0432 \u043d\u044e\u0430\u043d\u0441\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29260,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39000","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ciframos seg\u00fan GOST: gu\u00eda para la configuraci\u00f3n de la enrutaci\u00f3n din\u00e1mica del tr\u00e1fico | ProHoster","description":"Si su empresa.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/shifruemsya-po-gostu-pamyatka-po-nastrojke-dinamicheskoj-marshrutizatsii-trafika","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0428\u0438\u0444\u0440\u0443\u0435\u043c\u0441\u044f \u043f\u043e \u0413\u041e\u0421\u0422\u0443: \u043f\u0430\u043c\u044f\u0442\u043a\u0430 \u043f\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u0442\u0440\u0430\u0444\u0438\u043a\u0430 | ProHoster","og:description":"\u0415\u0441\u043b\u0438 \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/shifruemsya-po-gostu-pamyatka-po-nastrojke-dinamicheskoj-marshrutizatsii-trafika","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:27:16+00:00","article:modified_time":"2019-10-31T19:27:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39000","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-04 15:17:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:58:40","updated":"2026-02-04 15:17:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39000","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=39000"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39000\/revisions"}],"predecessor-version":[{"id":156680,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39000\/revisions\/156680"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29260"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=39000"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=39000"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=39000"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Con esto, la configuraci\u00f3n se puede considerar completada. En la salida de comandos de la consola tipo Cisco show crypto isakmp sa<\/b> y show crypto ipsec sa<\/b> deben reflejarse las fases uno y dos del IPSec construidas. Esta misma informaci\u00f3n se puede obtener mediante el comando sa_mgr show<\/b>, ejecutado desde el shell de debian. En la salida del comando cert_mgr show<\/b> deben aparecer los certificados de los sitios remotos. El estado de dichos certificados ser\u00e1 remoto<\/b>. En caso de que los t\u00faneles no se construyan, es necesario revisar el log VPN<\/a>-servicio, que se guarda en el archivo \/var\/log\/cspvpngate.log<\/b>. La lista completa de archivos de logs con la descripci\u00f3n de su contenido est\u00e1 presente en la documentaci\u00f3n.<\/p>\n