Publicamos todos los servicios ubicados en el hipervisor doméstico a través del servicio
EC2 Amazon Web Services a través de una instancia gratuita para Amazon Linux AMI 2018 usando
libreswan ,
xl2tpd y con un poco de distorsión ...
Los administradores de sistemas de una empresa tradicional (sin TI) con experiencia, generalmente después de un tiempo, tienen su propia granja de virtualización de servidores en casa para probar el montón de soluciones en el terreno. Esto puede ser una imitación banal de una red distribuida de oficinas y sucursales, pruebas de una infraestructura integrada de alta disponibilidad, implementación de nuevas versiones de algunas soluciones, etc.
Externamente, puede verse desde una simple PC hogareña llena de memoria con un hipervisor incorporado y un NAS de nivel de consumidor como almacenamiento iSCSI (o incluso como una máquina virtual simple en la misma PC) a servidores completos de montaje en bastidor de tamaño pequeño comprados para unidades de control dañadas a bajo costo con un pedigrí de los centros de datos occidentales, con el mismo BU tsiska para conectividad de red y atascado en el Fibre Channel, el mismo, comprado en el NAS del mercado secundario, pero ya una clase empresarial.
Por supuesto, en nuestra era de locura por las nubes, toda la infraestructura se puede implementar fácilmente en los centros de datos en la nube, pero esto no siempre es posible, principalmente debido al costo. No importa si las pruebas requieren varias máquinas virtuales livianas de los planes disponibles, pero ¿qué sucede si en servicio tiene que torcer varias docenas o incluso cientos de "máquinas virtuales" separadas con una amplia variedad de servicios, y también desea tener un archivo para que pueda tenerlo en cualquier momento hubo una muestra que se retorció en configuraciones / configuraciones hace un año. O bien, es necesario transferir todas las dificultades con la misma sincronización entre ADDS y ADFS antes de transferir algunos de los servicios empresariales existentes a la misma MS Azure.
El principal problema en este caso es la publicación (reenvío) de toda esta infraestructura al exterior, para que pueda practicar la conexión de usuarios externos al "sitio del servidor" de su hogar o a sus propios servicios "en la nube", o la integración con servicios de terceros, etc.
Es bueno si la conexión doméstica está diseñada para una tarifa comercial, en este caso no hay problemas con las solicitudes entrantes, y la dirección IP es casi siempre "blanca", estática.
Pero qué hacer cuando el proveedor habitual de "hogar" está presente en el lugar de residencia, que además solo puede proporcionar una dirección de la red privada. ¿O dará una dirección blanca, pero tradicionalmente cortará todas las entradas del rango de puertos privilegiado (<1024)? O usted es un estudiante cursi pobre y simplemente no puede pagar una tarifa mensual diseñada para entidades legales. ¿O a menudo tiene que cambiar su lugar de residencia, arrastrando sus "pertenencias" del servidor virtual a la joroba? Un caso especial también es relevante para aquellos que viven fuera del CIS, cuando el proveedor proporciona por la fuerza su propio equipo para conectarse a Internet y allí simplemente no puede configurar físicamente el reenvío de los puertos que necesita a la granja virtual de su casa.
Una solución es usar cualquiera de los servicios VPN de terceros. Desafortunadamente, pocos de ellos permiten el permiso de las conexiones entrantes con respecto al túnel, a menudo es un servicio pago separado. También en este caso, la elección de direcciones IP externas será muy limitada si desea probar la situación con la presencia de una dirección IP externa en un país en particular, además, por regla general, no hay garantía de que al mismo tiempo un montón de otros clientes de servicios VPN no se cuelguen de esta dirección , o será estático durante mucho tiempo, lo cual es importante para configurar registros de subdominio de servicio en DNS.
También vale la pena (en mi humilde opinión), aunque algunos métodos pervertidos, es implementar su propio enrutador "virtual" en alguna plataforma de nube externa con la capacidad de configurar un túnel VPN desde la granja de hipervisores domésticos a esta máquina virtual en la nube, con las conexiones entrantes necesarias enviadas desde la interfaz de red externa servicios de hipervisor de nubes a casa. E idealmente, no pagar casi nada por todo el asunto.
Habiendo perdido recientemente mi trabajo, y con el acceso a una granja de pruebas corporativas cálida y cómoda, pero a cambio recibí mucho tiempo libre para actualizar mis habilidades, decidí dar a los servicios del hipervisor de mi hogar la oportunidad de ver las conexiones entrantes de clientes.
El autor de estas líneas
"ama todo tipo de perversiones de infraestructura" , por lo tanto, como enrutador virtual, usaremos la instancia gratuita de Amazon Web Services (AWS) EC2 t2.micro para Linux, que en lugar de AWS: VPC (en teoría) le dará un poco más de flexibilidad en la depuración y características , y la topología de esta perversión VPN se muestra a continuación:
¿Qué vemos aquí?
Hay una máquina virtual (instancia) gratuita (750 horas de trabajo por mes durante el año), en Linux, implementada en AWS: EC2. Las llamadas entrantes de algunos usuarios de sus servicios domésticos caen en la dirección IPv4 blanca externa de Elastic IP, luego, a través de las reglas entrantes (Entrantes) en los "Grupos de seguridad", los puertos que necesitamos asignar a la interfaz de red de la instancia, luego los paquetes de estas solicitudes a través de iptables pasan por el túnel IPSec para una máquina virtual para Windows 2016, donde, mediante el enrutamiento, RRAS obtiene el servicio deseado dentro de la granja virtual doméstica. Prestamos especial atención a la presencia de tres NAT a la vez: uno en AWS Linux, uno en el enrutador de "red de oficina" y uno más, implícito, en el enrutador doméstico.
En este (mi) caso, una máquina virtual bajo Windows Server 2016 desempeña el papel de un enrutador para simular una red de oficina y su plataforma de servidor, MS WAP se implementa junto con una máquina separada con MS ADFS y otros, por lo que no hay problema para reemplazarla con cualquier otro sistema operativo o incluso una pieza casera al gusto. Con Windows RRAS, por cierto, las cosas se complican en el camino, en el camino tuve que lidiar con varios momentos desagradables (sobre los cuales a continuación), por lo que si elige no gustar MS Windows Server como un enrutador, entonces con otro sistema operativo puede ser más fácil.
Primero crearemos una cuenta de AWS si aún no tiene una. No hay problemas con la creación de la cuenta en sí, solo necesita indicar los detalles de su tarjeta de plástico, de la cual se cargará (y luego se devolverá) 1 USD como cheque.
Solo dos puntos deben mencionarse aquí:
- Asegúrese de ir a AWS: IAM (Identity and Access Management) y habilitar MFA (Multi-Factor Authentication) para su nueva cuenta, y aún mejor, como lo recomienda AWS: cree también una cuenta separada con MFA y continúe trabajando a través de la restricción de los derechos correspondientes. ella De lo contrario, puede terminar en una situación desagradable cuando un troyano roba las credenciales de AWS de su PC y, por ejemplo, alguien extrae de su corazón a su costa en costosos planes de instancias de alto rendimiento ...
- Por razones prácticas, se recomienda que configure una alerta de presupuesto. Esto se hace en la configuración de la cuenta, el elemento de menú correspondiente se llama "Panel de control de facturación y costos". En el panel que se abre, seleccione el elemento "Presupuestos" a la izquierda y configure el presupuesto mensual planificado a gusto utilizando el asistente incorporado. No olvide configurar una alerta allí: en caso de exceder la cantidad especificada, recibirá un mensaje de inmediato. Esto es útil si no ha trabajado con AWS antes y tiene miedo de "obtener" accidentalmente una suma redonda en el transcurso de sus experimentos.
A continuación, necesitamos
AWS: EC2 .
Uno de los pasos más importantes es seleccionar la región de AWS (esencialmente un centro de datos) en el que queremos implementar nuestra máquina virtual. La ubicación afectará directamente la ubicación geográfica de su "enrutador virtual" y, por lo tanto, el retraso de la red al trabajar con él. Esto es importante porque AWS no proporciona migración en vivo entre regiones (el
servicio de migración de servidor AWS incorporado solo puede migrar algo a la nube de AWS) y en caso de un error de ubicación, es más fácil recrear una nueva instancia nuevamente en la ubicación deseada. Alternativamente, deberá eliminar la imagen de la instancia (Imagen, EC2 incorporada) en
AWS: S3 (servicio de almacenamiento) y desde allí extraer esta imagen a la instancia de EC2 en la nueva región. En mi caso, la región de
Frankfurt fue seleccionada originalmente:
Creamos una nueva instancia, seleccione la opción
"Solo nivel gratuito" a la izquierda, que limitará la lista de imágenes propuesta a solo las gratuitas. Elegí
"Amazon Linux AMI 2018" (
más información sobre las distribuciones de Linux en AWS), porque en "Amazon Linux 2 AMI" xl2tpd no funciona correctamente debido a la naturaleza del núcleo ensamblado por Amazon.
Puede elegir cualquier otra imagen de Linux que le sea familiar de la lista provista. También puede profundizar en
AWS Marketplace y buscar imágenes alternativas allí, solo lea cuidadosamente los comentarios sobre el costo: la imagen en sí y los recursos informáticos pueden ser gratuitos, pero tendrá que pagar más por el espacio en disco, etc.
Seleccionamos el tipo propuesto
"t2.micro" , proporciona 1 vCPU, 1 GB de memoria, 8-30 GB (SSD / Magnetic) de espacio en disco y 750 horas de trabajo gratis cada mes durante un año. Suficiente para nuestro "enrutador virtual". Vale la pena señalar que el espacio libre en disco y el tiempo de trabajo se gastan en todas las instancias, por lo que en caso de dificultades financieras, no necesita crearlos / ejecutarlos más de lo que puede pagar, excepto gratis.
Haga clic en el asistente "Siguiente ...", en el tercer paso dejamos todos los valores predeterminados, en el cuarto estamos de acuerdo con los 8 gigabytes de disco predeterminado de SSD propuestos y la instancia comienza con el botón Revisar e iniciar:
Después de eso, obtendremos una ventana con un mensaje sobre la creación de un nuevo par de claves para conectarse a la nuestra a través de SSH y una propuesta para nombrar este par y descargar la clave privada en formato * .pem. Realmente lo necesitaremos en el futuro, por lo que es aconsejable guardarlo inmediatamente en un lugar seguro. Si se pierde este archivo, perderá la capacidad de conectarse de forma remota a las instancias que lo utilizan. En EC2, no hay forma de regenerarlo nuevamente para una instancia existente, la única forma es conectar el disco de la instancia a otra instancia que tenga acceso y posterior edición de claves.
Después de un tiempo, se lanzará la instancia, tendrá una dirección IPv4 interna (privada) y externa (pública), así como dos nombres DNS correspondientes.
Configure inmediatamente los grupos de seguridad para garantizar el flujo de tráfico para los servicios que necesita:
Necesitaremos los puertos entrantes abiertos 500, 1701, 4500 UDP y 4500 TCP para organizar el túnel VPN IPSec L2TP, HTTP y HTTPS para publicar servicios de granja doméstica, el acceso externo a la instancia a través de SSH se creó automáticamente al crear la instancia, porque Básicamente, EC2 no contiene ningún acceso integrado a la consola de la máquina virtual a través de su interfaz web. Solo existe la posibilidad de ver la pantalla:
Es recomendable configurar el acceso a través de VPN y SSH solo desde la dirección IP de su hogar. El orden de las reglas en los grupos de seguridad no importa.
Dado que utilizaremos múltiples documentos NAT, AWS recomienda deshabilitar la
"Comprobación de origen / destino de red" en este caso:
Como utilizaremos el túnel IPSec, y no el transporte, esta configuración no tiene mucho sentido para nosotros, pero por si acaso, es mejor desactivarla.
Conéctese a través de SSH a nuestra instancia. Si utiliza un cliente SSH gráfico, por ejemplo, PuTTY, para conectarse, la ayuda integrada sobre la conexión, llamada por RMB en la instancia -> Conectar, lo ayudará a:
Amazon Linux mantiene un pedigrí de RHEL y CentOS, por lo que se utiliza el administrador de paquetes yum.
Todas las operaciones que se describen a continuación deben realizarse con escalamiento de privilegios, por lo tanto, las precedemos con sudo o simplemente trabajamos como root.
Primera actualización:
Como software para organizar un servidor VPN, usaremos una combinación de libreswan y xl2tpd.
LibreSwan (fork de Openswan y un análogo de strongSwan) es una implementación popular de VPN IPSec e IKE (Internet Key Exchange). Puede omitir correctamente varios tipos de NAT y sus combinaciones, lo cual es especialmente importante al organizar el túnel IPSec.
xl2tpd también se usa ampliamente, su principal ventaja es la capacidad incorporada para autenticar y transmitir los parámetros de conexión del cliente a través de ppp cuando se conecta (por ejemplo, direcciones IP, configuración de ruta predeterminada, servidores DNS, etc.), lo que elimina la necesidad de una implementación adicional de DHCP y Radius para nuestro tareas simples
Dado que xl2tpd no se encuentra en los repositorios estándar de Amazon Linux, debemos habilitar EPEL (Paquetes adicionales para Enterprise Linux):
Instale los paquetes necesarios:
Habilitar el enrutamiento a nivel de kernel:
en el archivo
/etc/sysctl.conf escribimos:
net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.lo.secure_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.eth0.secure_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0
Deshabilite
rp_filter en la sesión actual para no reiniciar:
Aplicamos la configuración y verificamos la disponibilidad de enrutamiento:
Necesitamos asegurar el reenvío de los paquetes entrantes (con respecto a la interfaz pública de la instancia) desde los puertos de los servicios requeridos a nuestro futuro túnel IPSec. Para esto, es necesario no solo
quitar la NAT de estos paquetes, sino también enmascarar en la interfaz
ppp0 .
Usaremos las funciones incorporadas de
iptables para esto, que en el caso de Amazon Linux está configurado inicialmente para permitir completamente cualquier tráfico en cualquier dirección:
hacer DNAT de los puertos requeridos:
reenvíe todos los paquetes que llegaron a estos puertos a la dirección de puerta de Windows:
enmascarar estos paquetes:
Es aconsejable mantener las reglas de iptables para que se ajusten automáticamente cuando se reinicia la instancia:
En este caso, utilizamos el DNAT (Destino NAT) del puerto TCP requerido desde la interfaz de red eth0 de la instancia en la dirección IPv4 10.100.0.2, que es la dirección en la interfaz ppp del servicio RRAS de nuestra puerta de Windows en el hipervisor doméstico.
El siguiente es un punto muy importante: dado que los servicios dentro del hipervisor deben poder responder a las solicitudes recibidas de la instancia de AWS, es necesario proporcionar enmascaramiento (reemplazar la dirección del remitente) en la interfaz
ppp0 de la instancia antes de enviar el paquete, de lo contrario la respuesta irá en una dirección completamente diferente: desde la puerta de Windows en el hipervisor pasa el túnel IPSec directamente al enrutador predeterminado (enrutador doméstico), como resultado de lo cual, por supuesto, se colocará en el lado del cliente del servicio, como si viniera de un recurso no solicitado. Si se usa el enmascaramiento en el encabezado del paquete en la entrada del túnel vpn, la dirección del remitente cambiará de la dirección en algún lugar de Internet a la dirección
ppp0 de la interfaz de la instancia de AWS: EC2, es decir en mi caso al 10.100.0.1
Como alternativa al uso de iptables para otras distribuciones de Linux o sistemas * NIX, puede recomendar el viejo rinetd, donde todo esto se hace generalmente en una línea en su configuración
rinetd.conf :
<ip source> <port source> <ip destination> <port destination>
Lo único que deberá habilitarse en este caso en el kernel es la posibilidad de enrutamiento / tráfico NAT.
Es hora de cocinar libreswan.
El archivo
/etc/ipsec.conf contiene instrucciones para descargar todos los archivos .conf de /etc/ipsec.d/, por lo tanto, creamos un nuevo archivo de configuración en el directorio /etc/ipsec.d/aws_vpn.conf y lo agregamos:
config setup
Para simplificar, utilizaremos la autenticación IPSec basada en una clave compartida (PSK), no en certificados, por lo que debemos especificarla explícitamente. El archivo
/etc/ipsec.secrets contiene instrucciones para descargar todos los archivos .secrets de
/etc/ipsec.d/ , allí creamos un nuevo archivo
/etc/ipsec.d/aws_vpn.secrets y especificamos el PSK en el formato:
< 172...> %any : PSK "< PSK>"
Como un ejemplo:
172.31.20.120 %any : PSK "Pa$$w0rd"
Dado que la conexión ppp se usará dentro del túnel IPSec, y existe su propia autenticación, también la configuramos:
Ingresamos el nombre de usuario y la contraseña en el archivo
/ etc / ppp / chap-secrets en el formato:
<user> * <password> *
Como un ejemplo:
aws_user * Pa$$w0rd *
Al conectarse al cliente ppp, es posible pasar una serie de opciones para configurar la interfaz de red y la tabla de enrutamiento por su parte.
En el archivo
/etc/ppp/options.xl2tpd , configure estas opciones:
Porque no necesitamos pasar direcciones de dns, victorias, etc. al cliente. cosas: todas las demás opciones deben comentarse.
Aquí necesitas una explicación de la configuración.
El comportamiento estándar para las conexiones VPN es instalar una nueva ruta predeterminada en la tabla del cliente, lo que obliga a todo el tráfico desde Internet a "pasar" a través del servidor vpn. En nuestro caso, esto está mal, porque El objetivo de la puerta de Windows es proporcionar acceso simulado a Internet de la red de la oficina virtual detrás de él en el hipervisor y publicar los recursos de los servicios internos hacia afuera a través de AWS: EC2, por lo que es irracional conducir todo el tráfico a través de la instancia a AWS: EC2. Es por eso que debe evitar que una conexión VPN en RRAS cambie la ruta predeterminada (a un enrutador doméstico).
También es importante elegir los valores correctos de MTU y MRU: utilizamos el túnel IPSec y un tamaño de carga útil demasiado grande puede no encajar en el límite de encapsulación, lo que conducirá a la fragmentación y muy probablemente a un error. Si aparece, intente en primer lugar reducir estos valores, por ejemplo, a 1280. Los valores indicados en la configuración dada son compatibles con el cliente VPN de Windows.
Queda por configurar xl2tpd
Configuramos todo lo necesario en el archivo de configuración xl2tpd
/etc/xl2tpd/xl2tpd.conf :
[global] port=1701 ipsec saref = yes ; , ;debug tunnel = yes ;debug avp = yes ;debug network = yes ;debug state = yes ;debug tunnel = yes [lns default] name = AWSvpnServer ; ppp ip range = 10.100.0.2-10.100.0.2 ; ppp0 AWS:EC2 local ip = 10.100.0.1 require authentication = yes require chap = yes refuse pap = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes
Verificamos todo lo que hemos hecho
Intentamos ejecutar ambos servicios y verificar las configuraciones:
service ipsec start service xl2tpd start ipsec verify
Es posible que los servicios ya se estén ejecutando, en cuyo caso simplemente se reinician.
Si todo está bien, el resultado de la verificación de ipsec debería ser similar a la captura de pantalla:
Puede depurar xl2tpd de forma interactiva ejecutándolo con el modificador -D y colgándolo en una "ventana" separada del terminal SSH utilizando la utilidad de
pantalla :
En este caso, el proceso xl2tpd no pasará a segundo plano, sino que mostrará todas sus actividades en la pantalla del terminal.
En caso de problemas, debe descomentar las opciones de depuración en las configuraciones (ver comentarios) y mirar el contenido de los registros del sistema y el archivo
/var/log/pluto.log . También vale la pena prestar atención al contenido de la opción
virtual_private / virtual-private en el archivo
/etc/ipsec.conf , enumera todas las redes privadas disponibles para el intercambio de datos a través de IPSec. Si, por alguna razón, tiene su propio direccionamiento, por ejemplo, utiliza su propio grupo de direcciones IPv4 blancas, debe realizar cambios en este parámetro.
Pasemos al último paso: configurar el servicio RRAS en la puerta de Windows y verificar la publicación de servicios desde Internet
Se supone que su hipervisor doméstico tiene una máquina virtual que ejecuta Windows 2012R2 o posterior, implementada en modo gráfico (Escritorio), y hay dos adaptadores de red en esta máquina virtual: uno "mira" a la red doméstica y tiene un enrutador doméstico como la ruta predeterminada y el otro en una red virtual de "oficina" local, en la que hay servicios publicados fuera. Un dominio de Windows es opcional, a menos que, por supuesto, los propios servicios lo requieran.
Instalamos todas las funciones necesarias con el Administrador del servidor o con el cmdlet PowerShell
Install-WindowsFeature :
Aquí demuestro la instalación de roles a través de gráficos, porque aún será mucho más conveniente llamar al asistente de configuración desde el Administrador del servidor y configurar el servicio RRAS en el cronograma, lo que nos complacerá con la buena interfaz desde el momento de Windows Server 2003:
Haga clic en RMB en su servidor, seleccione
"Configurar y habilitar enrutamiento y acceso remoto" y luego configure manualmente:
Siéntase libre de seleccionar todas las grajillas, completar el asistente e iniciar el servicio:
Primero, publiquemos nuestra red de área local virtual afuera. Vamos a IPv4-> NAT y creamos una nueva interfaz, como la interfaz existente en la que se implementará NAT, seleccionamos la interfaz externa (que se ve en Internet, o más bien en su red doméstica), la marcamos como pública y habilitamos NAT en ella:
Verificamos cómo sale el tráfico de la LAN virtual a través de nuestra puerta. No necesitamos configurar Windows Firewall todavía.
Si todo está bien, finalmente crearemos por lo que estábamos luchando, una conexión VPN a nuestra instancia de AWS y verificaremos la publicación de nuestros servicios. Entramos en el complemento RRAS a
"Interfaces de red" y creamos una nueva interfaz de marcado a petición con un nombre arbitrario:
Seleccione inmediatamente la conexión L2TP, por lo que nuestra nueva interfaz no intentará determinar automáticamente el tipo de VPN y, como resultado, se conectará más rápido:
Además en el asistente indicamos la dirección pública de nuestra nube (en mi caso, Elastic IP). En los próximos pasos, deje todo como está, porque no necesitamos una conexión de sitio a sitio:
Especifique la cuenta de usuario con la que configuramos la conexión ppp (en el archivo
/ etc / ppp / chap-secrets ). No se requiere nombre de dominio:
El asistente crea una nueva conexión. Ahora queda por configurarlo. Ajustaremos el tiempo de espera inactivo (tiempo de inactividad), eliminaremos el CHAP obsoleto en favor de solo MS-CHAPv2, especificaremos la clave PSK en las "Propiedades avanzadas" (la que se configuró para xl2tpd en el archivo /etc/ipsec.d/aws_vpn. secretos) y elimine IPv6:
Después de crear una nueva interfaz, también debe acceder a las propiedades del servicio RRAS, habilitar su política IPSec para L2TP y especificar su PSK. Se les pide que reinicien el servicio RRAS.
Parece que todo se puede elevar de forma segura una nueva interfaz y disfrutar del trabajo. Pero no Debido al hecho de que utilizamos NAT en el lado de la instancia de AWS: EC2, el cliente VPN de Windows no podrá conectarse a dicho nodo Nat-Traversal. Esto es cierto tanto para las versiones de cliente (hasta la última en el momento de escribir este artículo de la compilación de Windows 10) como para las de servidor.
Afortunadamente, hay una solución oficial a este problema en forma de ediciones en el registro de la configuración del servicio de Política IPSec seguido de un reinicio:
En
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ PolicyAgentcrear una clave DWORD (32 bits)
AsumeUDPEncapsulationContextOnSendRule = 2y reinicie nuestra puerta de Windows.
Desafortunadamente, el servicio RRAS es famoso por su capricho en la configuración y operación, e incluso después de un reinicio, realiza un inicio retrasado. Para que pueda apresurarse después de un reinicio.
Si todo se hace correctamente, la conexión funcionará dentro de 5-10 segundos.
Queda por hacer la publicación de los recursos necesarios en la puerta de Windows.
Para la prueba, trabajaremos en la publicación del servidor web. Primero, consulte nuestro túnel IPSec y las reglas de iptables.
Con manos temblorosas, verificamos desde una PC arbitraria conectada a Internet:
Wow, funciona ...
Durante la instalación de los roles necesarios, el MS IIS "nativo" se instaló por la fuerza, pero queremos que sea aún más fácil. Para esto, en una plataforma Windows,
HFS (Servidor de archivos HTTP) es muy adecuado: es gratuito, no requiere instalación, proporciona una página específica y un encabezado HTTP, puede funcionar en un puerto arbitrario (por defecto es 8080, por lo que en nuestro caso será necesario reconfigurar a 80), y también escribe inmediatamente en su consola de dónde proviene la conexión, lo cual es muy conveniente para depurar la publicación de muchos recursos web en la plataforma Windows. Para usarlo, primero debe detener el sitio de MS IIS para desatar el servidor incrustado del puerto requerido. Como no queremos instalar la consola de administración de MS IIS (de hecho, la consola de MS IIS 6 estará presente por compatibilidad, pero IIS 7+ no se puede controlar a través de ella), lo haremos a través de PowerShell:
Stop-WebSite -Name "Default Web Site"
o simplemente a través de la utilidad de administración iisreset:
iisreset /stop
Después de eso, debe permitir el tráfico entrante al puerto 80 en el Firewall de Windows incorporado.
Iniciamos HFS y verificamos:
Todo es genial Hemos logrado que desde cualquier lugar en Internet pueda ver el servidor web que vive en nuestro hogar como una máquina virtual en un hipervisor arbitrario.
El toque final: enseñamos a RRAS a reenviar todas esas solicitudes desde el exterior a la red de la oficina virtual, donde, según la leyenda, tenemos otro servidor web.
Para hacer esto, volvemos al complemento de administración RRAS en IPv4-> NAT y RMB en nuestra interfaz VPN, donde seleccionamos la pestaña
"Servicios y puertos" , la marcamos en la lista de servidores web y especificamos el servidor web en la red virtual interna cuyos recursos queremos publicar. internet:
Haga clic en Aceptar y ... todo está listo. Verificamos que todo debería funcionar bien.
De una manera tan simple, puede publicar rápidamente casi todos los servicios y recursos, desde sitios, servidores de correo hasta algunas integraciones complejas. Naturalmente, para la mayoría de ellos, necesitará tener su propio dominio DNS con la capacidad de crear subdominios y editar los registros necesarios. También es recomendable utilizar certificados SSL para publicar recursos web,
gracias a LetsEncrypt y servicios similares compatibles con ACME, todo esto se puede hacer de forma completamente gratuita y con actualizaciones automáticas.
Cuando reinicia la instancia, la dirección IPv4 pública no cambia, solo cuando se detiene, pero se recomienda utilizar una dirección IPv4 estática en AWS: EC2. Estática en el sentido de que cuando apaga su instancia, permanecerá asignada a ella y no caerá en el grupo libre general. Por supuesto, esto es necesario para no molestarse cada vez con la reconfiguración de registros DNS en dominios, y nadie canceló TTL con almacenamiento en caché. Cuesta mucho dinero y se llama, como ya se mencionó anteriormente,
Elastic IP .
Automatización de procesos primitiva.
Finalmente, quiero mencionar otra gran característica de AWS: EC2: configuración rápida de instancia desplegable. Hay muchas opciones de implementación rápida en AWS: EC2, hasta servicios especiales (y bastante complejos, pero muy potentes), pero existe la más simple: en el paso 3 en el asistente para crear una nueva instancia en la parte inferior se encuentra el campo
"Datos de usuario" . Puede colocar una secuencia de comandos en bash o incluso PowerShell (en el caso de una instancia para Windows), y esta secuencia de comandos se ejecutará automáticamente inmediatamente después de crear la instancia.
Es decir puede modificar ligeramente todos los comandos y configuraciones anteriores para crear su propio script bash y usarlo para generar rápidamente un enrutador virtual AWS: EC2.
Obtenga más información sobre esta función .
Gracias por tomarse el tiempo de leer este artículo.