Publicamos quaisquer serviços localizados no hypervisor doméstico por meio do serviço
EC2 Amazon Web Services por meio de uma instância gratuita do Amazon Linux AMI 2018 usando
libreswan ,
xl2tpd e com um pouco de distorção ...
Os administradores de sistema de uma empresa tradicional (que não é de TI) com experiência, geralmente depois de um tempo, têm seu próprio farm de virtualização de servidores em casa para testar o monte de soluções no local. Isso pode ser uma imitação banal de uma rede distribuída de filial de escritório, testando uma infraestrutura integrada de alta disponibilidade, implantação de novas versões de algumas soluções, etc.
Externamente, ele pode olhar de um PC doméstico simples com bomba de memória com um hipervisor integrado e um NAS de nível consumidor como armazenamento iSCSI (ou na forma de uma máquina virtual simples no mesmo PC) a servidores de montagem em rack de unidade pequena de pleno direito adquiridos por unidades de controle baixadas de forma mais barata com uma linhagem dos datacenters ocidentais, com o mesmo BU tsiska para conectividade de rede e preso no Fibre Channel da mesma forma, comprado no NAS do mercado secundário, mas já em classe executiva.
Obviamente, em nossa era da mania de nuvens, toda a infraestrutura pode ser facilmente implantada em data centers em nuvem, mas isso nem sempre é possível, principalmente por causa do custo. Não importa se os testes exigem várias máquinas virtuais leves a partir dos planos disponíveis, mas e se você estiver de serviço, você precisará alterar várias dúzias ou até centenas de "máquinas virtuais" separadas com uma ampla variedade de serviços e também desejar ter um arquivo para que você possa obtê-lo a qualquer momento houve uma amostra que girou nas configurações / definições de um ano atrás. Ou é necessário transferir todas as armadilhas com a mesma sincronização entre o ADDS e o ADFS antes de transferir alguns dos serviços comerciais existentes para o mesmo MS Azure.
O principal problema nesse caso é a publicação (encaminhamento) de toda essa infraestrutura para o exterior, para que você possa praticar a conexão de usuários externos ao "site do servidor" doméstico ou aos seus próprios serviços "em nuvem" ou integração com serviços de terceiros etc.
É bom que a conexão doméstica seja projetada para uma tarifa comercial; nesse caso, não há problemas com as solicitações recebidas e o endereço IP é quase sempre "branco", estático.
Mas o que fazer quando o provedor "doméstico" usual estiver presente no local de residência, que além disso só pode fornecer um endereço da rede Privada. Ou fornecerá um endereço branco, mas tradicionalmente cortará todas as entradas do intervalo de portas privilegiadas (<1024)? Ou você é um estudante pobre e brega e simplesmente não pode pagar uma taxa mensal criada para pessoas jurídicas. Ou você geralmente precisa mudar de local de residência, arrastando os "pertences" do servidor virtual para a corcunda? Um caso especial também é relevante para aqueles que vivem fora do CIS, quando o provedor forçosamente fornece seu próprio equipamento para conectar-se à Internet e simplesmente não é possível configurar fisicamente o encaminhamento das portas necessárias para o farm virtual doméstico externo.
Uma solução é usar qualquer um dos serviços VPN de terceiros. Infelizmente, poucos deles permitem a permissão de conexões de entrada em relação ao túnel, na maioria das vezes é um serviço pago separado. Além disso, nesse caso, a escolha de endereços IP externos será muito limitada se você quiser testar a situação com a presença de um endereço IP externo em um país específico. Além disso, como regra geral, não há garantia de que ao mesmo tempo vários outros clientes de serviços VPN não estejam presos nesse endereço. , ou permanecerá estático por um longo tempo, o que é importante para configurar registros de subdomínio de serviço no DNS.
Também digno de nota (IMHO), apesar de alguns métodos pervertidos, é implantar seu próprio roteador "virtual" em alguma plataforma de nuvem externa com a capacidade de configurar um túnel VPN do farm do hipervisor doméstico para esta máquina virtual na nuvem, com as conexões de entrada necessárias encaminhadas a partir da interface de rede externa nuvens para serviços de hypervisor doméstico. E, idealmente, pagar quase nada pela coisa toda.
Tendo perdido recentemente meu emprego e, com ele, acesso a um farm de testes corporativo acolhedor e confortável, mas em troca recebi muito tempo livre para atualizar minhas habilidades, decidi dar aos serviços do hipervisor doméstico a oportunidade de ver as conexões dos clientes que chegavam.
O autor dessas linhas
“ama todos os tipos de perversões de infraestrutura” , portanto, como roteador virtual, usaremos a instância gratuita do Amazon Web Services (AWS) EC2 t2.micro para Linux, que em vez de AWS: VPC (em teoria) dará um pouco mais de flexibilidade na depuração e recursos , e a topologia dessa perversão da VPN é mostrada abaixo:
O que vemos aqui?
Há uma máquina virtual (instância) gratuita (750 horas de trabalho por mês durante o ano), no Linux, implantada no AWS: EC2. As chamadas recebidas de alguns usuários de seus serviços domésticos caem no endereço IPv4 branco externo do Elastic IP; em seguida, pelas regras de entrada (Entrada) nos "Grupos de Segurança", as portas que precisamos mapear para a interface de rede da instância; os pacotes dessas solicitações através de iptables passam pelo túnel IPSec para uma máquina virtual para Windows 2016, onde, usando o roteamento, o RRAS obtém o serviço desejado dentro do farm virtual doméstico. Prestamos atenção especial à presença de três NATs de uma só vez: um no AWS Linux, um no roteador de “rede do escritório” e mais um, implícito, no roteador doméstico.
Nesse (meu) caso, uma máquina virtual no Windows Server 2016 desempenha o papel de um roteador para simular uma rede do escritório e sua plataforma de servidor, o MS WAP é implantado em conjunto com uma máquina separada com o MS ADFS e outros, portanto, não há problema em substituí-lo por qualquer outro SO até uma peça caseira a gosto. A propósito, com o Windows RRAS, as coisas ficam complicadas, ao longo do caminho, tive que lidar com vários momentos desagradáveis (sobre os quais abaixo); portanto, se você optar por não gostar do MS Windows Server como roteador, então com outro sistema operacional provavelmente será mais fácil.
Primeiro, criaremos uma conta da AWS se você ainda não tiver uma. Não há problemas com a criação da própria conta, você só precisa indicar os detalhes do seu cartão de plástico, dos quais 1 dólar será debitado (e depois devolvido) como um cheque.
Apenas dois pontos precisam ser mencionados aqui:
- Certifique-se de acessar AWS: IAM (Gerenciamento de identidade e acesso) e habilitar o MFA (autenticação multifator) para sua nova conta, ou melhor ainda, como recomenda a AWS - crie uma conta separada com o MFA e continue a trabalhar com a restrição dos direitos correspondentes. ela. Caso contrário, você pode acabar em uma situação desagradável quando um Trojan rouba credenciais da AWS do seu PC e, por exemplo, alguém mina do seu coração às suas custas em planos caros de instância de alto desempenho ...
- Por motivos práticos, é recomendável que você configure um alerta de orçamento. Isso é feito nas configurações da conta, o item de menu correspondente é chamado de "Painel de gerenciamento de faturamento e custo". No painel que é aberto, selecione o item "Orçamentos" à esquerda e configure o orçamento mensal planejado a seu gosto usando o assistente interno. Não se esqueça de configurar um alerta lá: em caso de exceder a quantidade especificada, você receberá uma mensagem imediatamente. Isso é útil se você não trabalhou com a AWS antes e tem medo de "obter" acidentalmente uma soma redonda no decorrer de suas experiências.
Em seguida, precisamos da
AWS: EC2 .
Uma das etapas mais importantes é selecionar a região da AWS (essencialmente um data center) na qual queremos implantar nossa máquina virtual. O posicionamento afetará diretamente a localização geográfica do seu “roteador virtual” e, portanto, o atraso da rede ao trabalhar com ele. Isso é importante porque A AWS não fornece migração ao vivo entre regiões (o
Serviço de Migração de Servidor da AWS interno pode migrar apenas algo para a própria nuvem da AWS) e, no caso de um erro de posicionamento, é mais fácil recriar uma nova instância novamente no local desejado. Como alternativa, você precisará remover a imagem da instância (Imagem, EC2 embutido) no
AWS: S3 (serviço de armazenamento) e daí puxar essa imagem para a instância do EC2 na nova região. No meu caso, a região de
Frankfurt foi originalmente selecionada:
Criamos uma nova instância, selecione a opção
"Somente nível gratuito" à esquerda, o que limitará a lista de imagens proposta a apenas imagens gratuitas. Eu escolhi
"Amazon Linux AMI 2018" (
mais sobre distribuições Linux na AWS), porque no "Amazon Linux 2 AMI", o xl2tpd não funciona corretamente devido à natureza do kernel montado pela Amazon.
Você pode escolher qualquer outra imagem do Linux que lhe seja familiar na lista fornecida. Você também pode ir mais fundo no
AWS Marketplace e procurar imagens alternativas no local, apenas leia atentamente os comentários sobre o custo: a própria imagem e os recursos de computação podem ser gratuitos, mas você terá que pagar mais por espaço em disco etc.
Selecionamos o tipo proposto
"t2.micro" , ele fornece 1 vCPU, 1 GB de memória, 8-30 GB (SSD / Magnetic) de espaço em disco e 750 horas de trabalho gratuitamente todos os meses, durante um ano. O suficiente para o nosso "roteador virtual". Vale a pena notar que o espaço livre em disco e o tempo de trabalho são gastos em todas as instâncias; portanto, em caso de dificuldades financeiras, você não precisa criar / executá-las mais do que pode, exceto de graça.
Clique no assistente "Next ...", na terceira etapa, deixamos todos os valores padrão, na quarta concordamos com os 8 gigabytes de disco padrão SSD propostos e a instância começa com o botão Review and Launch:
Depois disso, obteremos uma janela com uma mensagem sobre a criação de um novo par de chaves para conectar-se ao nosso via SSH e uma proposta para nomear esse par e fazer o download da chave privada no formato * .pem. Nós realmente precisaremos disso no futuro, por isso é aconselhável salvá-lo imediatamente em um local seguro. Se esse arquivo for perdido, você perderá a capacidade de se conectar remotamente às instâncias que o utilizam. No EC2, não há como regenerá-lo novamente para uma instância existente, a única maneira é conectar o disco da instância a outra instância que tenha acesso e edição subsequente da chave.
Depois de um tempo, a instância será iniciada, ela terá um endereço IPv4 interno (privado) e externo (público), além de dois nomes DNS correspondentes.
Configure imediatamente grupos de segurança para garantir o fluxo de tráfego dos serviços necessários:
Necessitaremos das portas de entrada abertas 500, 1701, 4500 UDP e 4500 TCP para organizar o túnel IPSec L2TP VPN, HTTP e HTTPS para publicar serviços de farm doméstico, o acesso externo à instância via SSH foi criado automaticamente ao criar a instância, porque O EC2 essencialmente não contém nenhum acesso interno ao console da máquina virtual por meio de sua interface da web. Existe apenas a capacidade de visualizar a tela:
É aconselhável configurar o acesso via VPN e SSH apenas a partir do seu endereço IP residencial. A ordem das regras nos Grupos de Segurança não importa.
Como usaremos várias documentações NAT, a AWS recomenda desativar a
“Verificação de origem / destino da rede” neste caso:
Como usaremos o encapsulamento IPSec, e não o transporte, essa configuração não faz muito sentido para nós, mas, por precaução, é melhor desativá-la.
Conecte-se através do SSH à nossa instância. Se você usar um cliente SSH gráfico, por exemplo, PuTTY, para se conectar, a ajuda interna na conexão, chamada pelo RMB na instância -> Conectar, ajudará você a:
O Amazon Linux mantém um pedigree do RHEL e do CentOS, portanto, o gerenciador de pacotes yum é usado.
Todas as operações descritas abaixo devem ser executadas com escalonamento de privilégios; portanto, as precedemos com sudo ou apenas trabalhamos como root.
Primeira atualização:
Como software para organizar um servidor VPN, usaremos uma combinação de libreswan e xl2tpd.
O LibreSwan (fork do Openswan e um análogo do strongSwan) é uma implementação popular do VPN IPSec e do IKE (Internet Key Exchange). Ele pode ignorar corretamente vários tipos de NAT e suas combinações, o que é especialmente importante ao organizar o encapsulamento IPSec.
O xl2tpd também
é amplamente utilizado, sua principal vantagem é a capacidade
interna de autenticar e transmitir parâmetros de conexão do cliente via ppp ao conectar (por exemplo, endereços IP, configurações de rota padrão, servidores DNS etc.), o que elimina a necessidade de implantação adicional de DHCP e Radius para o nosso tarefas simples.
Como o xl2tpd não está nos repositórios padrão do Amazon Linux, precisamos habilitar o EPEL (Pacotes Extra para Enterprise Linux):
Instale os pacotes necessários:
Habilite o roteamento no nível do kernel:
no arquivo
/etc/sysctl.conf, escrevemos:
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
Desative
rp_filter na sessão atual para não reiniciar:
Aplicamos as configurações e verificamos a disponibilidade do roteamento:
Precisamos garantir o encaminhamento de pacotes de entrada (com relação à interface pública da instância) das portas dos serviços necessários para o nosso futuro túnel IPSec. Para isso, é necessário não apenas remover o NAT desses pacotes, mas também fazer o mascaramento na interface
ppp0 .
Usaremos os recursos
internos do
iptables para isso, que no caso do Amazon Linux são configurados inicialmente para permitir completamente qualquer tráfego em qualquer direção:
faça DNAT das portas necessárias:
encaminhe todos os pacotes que vieram para essas portas para o endereço do gate do Windows:
mascarar para estes pacotes:
É aconselhável manter as regras do iptables para que elas sejam automaticamente apertadas quando a instância for reiniciada:
Nesse caso, usamos o DNAT (NAT de destino) da porta TCP necessária a partir da interface de rede eth0 da instância na direção do endereço IPv4 10.100.0.2, que é o endereço na interface ppp do serviço RRAS do nosso portal RRAS do nosso portão do Windows no hypervisor doméstico.
A seguir, vem um ponto muito importante: como os serviços dentro do hypervisor precisam responder às solicitações recebidas da instância da AWS, é necessário fornecer mascaramento (substituindo o endereço do remetente) na interface
ppp0 da instância antes de enviar o pacote, caso contrário, a resposta seguirá uma direção completamente diferente: o portão do Windows no hipervisor após o túnel IPSec direto para o roteador padrão (roteador doméstico), como resultado, é claro, será descartado no lado do cliente do serviço, como se fosse de um recurso não solicitado. Se o mascaramento for usado no cabeçalho do pacote na entrada do túnel VPN, o endereço do remetente mudará do endereço em algum lugar da Internet para o endereço
ppp0 da interface da instância da AWS: EC2, ou seja, no meu caso em 10.100.0.1
Como alternativa ao uso do iptables para outras distribuições Linux ou sistemas * NIX, você pode recomendar o bom e velho rinetd, onde tudo isso é feito geralmente em uma linha na sua configuração
rinetd.conf :
<ip source> <port source> <ip destination> <port destination>
A única coisa que precisará ser ativada neste caso no kernel é a possibilidade de roteamento / tráfego NAT.
É hora de cozinhar libreswan.
O arquivo
/etc/ipsec.conf contém instruções para baixar todos os arquivos .conf de /etc/ipsec.d/, portanto, criamos um novo arquivo de configuração no diretório /etc/ipsec.d/aws_vpn.conf e o adicionamos a ele:
config setup
Por uma questão de simplicidade, usaremos a autenticação IPSec com base em uma chave compartilhada (PSK), não em certificados, portanto devemos especificá-la explicitamente. O arquivo
/etc/ipsec.secrets contém instruções para o download de todos os arquivos .secrets de
/etc/ipsec.d/ , onde criamos um novo arquivo
/etc/ipsec.d/aws_vpn.secrets e especificamos o PSK no formato:
< 172...> %any : PSK "< PSK>"
Como exemplo:
172.31.20.120 %any : PSK "Pa$$w0rd"
Como a conexão ppp será usada dentro do túnel IPSec e há sua própria autenticação, nós a configuramos também:
Nós inserimos o nome de usuário e senha no arquivo
/ etc / ppp / chap-secrets no formato:
<user> * <password> *
Como exemplo:
aws_user * Pa$$w0rd *
Ao conectar-se ao cliente ppp, é possível passar várias opções para configurar a interface de rede e a tabela de roteamento de sua parte.
No arquivo
/etc/ppp/options.xl2tpd , defina estas opções:
Porque não precisamos passar endereços de DNS, vitórias etc. para o cliente. coisas - todas as outras opções precisam ser comentadas.
Aqui você precisa de uma explicação da configuração.
O comportamento padrão para conexões VPN é instalar uma nova rota padrão na tabela do cliente, o que força todo o tráfego a partir da Internet para "passar" pelo servidor vpn. No nosso caso, isso está errado, porque o objetivo do portão do Windows é fornecer acesso simulado à Internet da rede de escritório virtual por trás dele no hipervisor e publicar os recursos de serviços internos através da AWS: EC2, por isso é irracional direcionar todo o tráfego da instância para a AWS: EC2. É por isso que você precisa impedir que uma conexão VPN no RRAS altere a rota padrão (para um roteador doméstico).
Também é importante escolher os valores corretos de MTU e MRU: usamos o encapsulamento IPSec e um tamanho de carga útil muito grande pode não se encaixar no limite de encapsulamento, o que levará à fragmentação e provavelmente a um erro. Se aparecer, tente primeiro reduzir esses valores, por exemplo, para 1280. Os valores indicados na configuração fornecida são compatíveis com o cliente VPN do Windows.
Resta configurar o xl2tpd
Configuramos tudo o que é necessário no arquivo de configuração 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 tudo o que fizemos
Tentamos executar os dois serviços e verificamos as configurações:
service ipsec start service xl2tpd start ipsec verify
Os serviços já podem estar em execução; nesse caso, eles são simplesmente reiniciados.
Se tudo estiver bem, a saída do ipsec Verifique deve ser semelhante à captura de tela:
Você pode depurar o xl2tpd interativamente, executando-o com a opção -D e pendurando-o em uma “janela” separada do terminal SSH usando o utilitário de
tela :
Nesse caso, o processo xl2tpd não entrará em segundo plano, mas exibirá todas as suas atividades na tela do terminal.
Em caso de problemas, é necessário descomentar as opções de depuração nas configurações (consulte os comentários) e examinar o conteúdo dos logs do sistema e o arquivo
/var/log/pluto.log . Também vale a pena prestar atenção ao conteúdo da opção
virtual_private / virtual-private no arquivo
/etc/ipsec.conf , que lista todas as redes privadas disponíveis para troca de dados por meio do IPSec. Se, por algum motivo, você tiver seu próprio endereçamento, por exemplo, usar seu próprio conjunto de endereços IPv4 brancos, faça alterações nesse parâmetro.
Vamos para a última etapa - configurar o serviço RRAS no portão do Windows e verificar a publicação de serviços da Internet
Supõe-se que o seu hipervisor doméstico tenha uma máquina virtual executando o Windows 2012R2 ou mais recente, implantada no modo gráfico (Área de Trabalho), e há dois adaptadores de rede nessa máquina virtual: uma analisa a rede doméstica e possui um roteador doméstico como a rota padrão e o outro em uma rede virtual de “escritório” local, na qual existem serviços publicados fora. Um domínio do Windows é opcional, a menos que os próprios serviços o exijam.
Instalamos todas as funções necessárias usando o Gerenciador do Servidor ou o cmdlet PowerShell
Install-WindowsFeature :
Aqui, demonstro a instalação de funções por meio de gráficos, porque ainda será muito mais conveniente chamar o assistente de instalação do Server Manager e configurar o serviço RRAS no cronograma, o que nos agradará com a boa e antiga interface desde o Windows Server 2003:
Clique em RMB no seu servidor, selecione
"Configurar e ativar roteamento e acesso remoto" e, em seguida, configure manualmente:
Sinta-se livre para selecionar todas as gralhas, concluir o assistente e iniciar o serviço:
Primeiro, vamos lançar nossa rede local virtual fora. Vamos para IPv4-> NAT e criamos uma nova interface, como a interface existente na qual o NAT será implementado, selecione a interface externa (que fica na Internet ou melhor na sua rede doméstica), marque-a como pública e ative a NAT:
Verificamos como o tráfego da LAN virtual sai pelo nosso portão. Ainda não precisamos configurar o Firewall do Windows.
Se estiver tudo bem, finalmente criaremos o que estávamos lutando, uma conexão VPN à nossa instância da AWS e verificaremos a publicação de nossos serviços. Vamos no snap-in do RRAS para
"Interfaces de rede" e criamos uma nova interface de discagem por demanda com um nome arbitrário:
Selecione imediatamente a conexão L2TP, para que nossa nova interface não tente determinar automaticamente o tipo de VPN e, como resultado, ela se conectará mais rapidamente:
Mais adiante, no assistente, indicamos o endereço público da nossa nuvem (no meu caso, o Elastic IP). Nas próximas etapas, deixe tudo como está, porque não precisamos de uma conexão site a site:
Especifique a conta do usuário sob a qual configuramos a conexão ppp (no arquivo
/ etc / ppp / chap-secrets ). Nenhum nome de domínio é necessário:
O assistente cria uma nova conexão. Agora resta configurá-lo. Ajustamos o tempo limite ocioso (tempo ocioso), removemos o CHAP desatualizado em favor de apenas o MS-CHAPv2, especificamos a chave PSK em "Propriedades avançadas" (a que foi definida para xl2tpd no arquivo /etc/ipsec.d/aws_vpn. segredos) e remova o IPv6:
Depois de criar uma nova interface, você também deve acessar as propriedades do serviço RRAS, habilitar sua diretiva IPSec para L2TP e especificar seu PSK. Eles são solicitados a reiniciar o serviço RRAS.
Parece que tudo pode ser criado com segurança em uma nova interface e aproveitar o trabalho. Mas não. Devido ao fato de termos utilizado o NAT no lado da instância do AWS: EC2, o cliente VPN do Windows não poderá se conectar a um nó Nat-Traversal. Isso vale tanto para as versões do cliente (até a última versão deste artigo da compilação do Windows 10) quanto para as do servidor.
Felizmente, existe uma solução oficial para esse problema na forma de edições no registro das configurações do serviço de diretiva IPSec, seguidas por uma reinicialização:
At
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ PolicyAgentcrie uma chave DWORD (32 bits)
AssumeUDPEncapsulationContextOnSendRule = 2e reinicie o nosso Windows Gate.
Infelizmente, o serviço RRAS é famoso por seu capricho na configuração e operação e, mesmo após uma reinicialização, executa um início atrasado. Assim, você pode apressá-lo após uma reinicialização.
Se tudo for feito corretamente, a conexão funcionará dentro de 5 a 10 segundos.
Resta fazer a publicação dos recursos necessários no próprio portão do Windows.
Para o teste, elaboraremos a publicação do servidor web. Primeiro, verifique nosso túnel IPSec e as regras do iptables.
Com mãos trêmulas, verificamos a partir de um PC arbitrário conectado à Internet:
Uau, funciona ...
Durante a instalação das funções necessárias, o MS IIS “nativo” foi instalado à força, mas queremos ainda mais fácil. Para isso, em uma plataforma Windows, o
HFS (HTTP File Server) é adequado - é gratuito, não requer instalação, fornece uma página específica e um cabeçalho HTTP, pode funcionar em uma porta arbitrária (por padrão é 8080, portanto, no nosso caso, será necessário reconfigurar para 80), e também grava imediatamente em seu console de onde a conexão veio, o que é muito conveniente para depurar a publicação de muitos recursos da Web na plataforma Windows. Para usá-lo, você deve primeiro parar o site do MS IIS para desatar o servidor incorporado da porta necessária. Como não queremos instalar o console de gerenciamento do MS IIS (na verdade, o console do MS IIS 6 estará presente para compatibilidade, mas o IIS 7+ não pode ser controlado por ele), faremos isso pelo PowerShell:
Stop-WebSite -Name "Default Web Site"
ou simplesmente através do utilitário de gerenciamento iisreset:
iisreset /stop
Depois disso, você precisa permitir o tráfego de entrada para a porta 80 no Firewall do Windows interno.
Iniciamos o HFS e verificamos:
Tudo está ótimo. Conseguimos que, de qualquer lugar da Internet, você possa ver o servidor Web que mora em nossa casa como uma máquina virtual em um hipervisor arbitrário.
O toque final: ensinamos o RRAS a encaminhar todos esses pedidos de fora para a rede do escritório virtual, onde, segundo a lenda, temos outro servidor da web.
Para fazer isso, vamos novamente ao snap-in de gerenciamento do RRAS em IPv4-> NAT e RMB em nossa interface VPN, onde selecionamos a guia
"Serviços e portas" , marcamos o servidor Web na lista e especificamos o servidor Web na rede virtual interna cujos recursos queremos publicar internet:
Clique em OK e ... tudo está pronto. Verificamos - tudo deve funcionar bem.
De uma maneira tão simples, você pode publicar rapidamente quase todos os serviços e recursos, de sites, servidores de correio a algumas integrações complexas. Naturalmente, para a maioria deles, você precisará ter seu próprio domínio DNS com a capacidade de criar subdomínios nele e editar os registros necessários. Também é aconselhável usar certificados SSL para publicar recursos da Web,
graças ao LetsEncrypt e serviços similares compatíveis com ACME, tudo isso pode ser feito de forma totalmente gratuita e com atualização automática.
Quando você reinicia a instância, o endereço IPv4 público não é alterado - apenas quando é parado, mas ainda é recomendável usar um endereço IPv4 estático na AWS: EC2. Estático no sentido de que, quando você desliga sua instância, ela permanece atribuída a ela e não se enquadra no conjunto gratuito geral. Obviamente, isso é necessário para não se preocupar sempre com a reconfiguração dos registros DNS nos domínios, e ninguém cancelou o TTL com o cache. Custa muito dinheiro e é chamado, como já mencionado acima,
IP Elastic .
Automação primitiva de processos
Por fim, quero mencionar outro ótimo recurso da AWS: EC2 - configuração rápida de instância implementável. Existem muitas opções de implantação rápida na AWS: EC2, até serviços especiais (e bastante complexos, mas muito poderosos), mas há a mais simples: na etapa 3 do assistente para criar uma nova instância na parte inferior, é o campo
"Dados do usuário" . Você pode colocar um script no bash ou mesmo no PowerShell (no caso de uma instância para Windows), e esse script será executado automaticamente imediatamente após a criação da instância.
I.e. você pode modificar levemente todos os comandos e configurações acima para criar seu próprio script bash e usá-lo para criar rapidamente um roteador virtual AWS: EC2.
Saiba mais sobre esse recurso .
Obrigado por ler este artigo.