Há anos a imprensa escreve sobre o problema de que agora existem muito poucos endereços IPv4 disponíveis. Mas, por outro lado, estou usando uma empresa de hospedagem de servidores que oferece endereços IPv4 públicos por uma pequena quantia de dinheiro. E minha conexão privada à Internet vem com um endereço IPv4 público.

Como isso é possível? O problema é tão ruim quanto a imprensa quer que acreditemos?

É muito ruim. Aqui está uma lista de exemplos do que tenho experiência em primeira mão com ISPs de consumidores para combater a falta de endereços IPv4:

• Trocar repetidamente os blocos IPv4 entre cidades, causando breves interrupções e redefinições de conexão para os clientes.
• Diminuindo o tempo de concessão do DHCP de dias para minutos.
• Permita que os usuários escolham se desejam conversão de endereço de rede (NAT) no Customer Premise Equipment (CPE) ou não e, em seguida, ative-o de forma retroativa para todos.
• Ativando o NAT no CPE para clientes que já usaram a oportunidade de optar por não participar do NAT.
• Reduzir o limite para o número de endereços de controle de acesso à mídia (MAC) ativos simultaneamente aplicados pelo CPE.
• Implantando NAT de classe de operadora (CGN) para clientes que tinham um endereço IP real quando se inscreveram no serviço.

Tudo isso reduz a qualidade do produto que o ISP está vendendo para seus clientes. A única explicação sensata para o motivo de eles estarem fazendo isso com seus clientes é a falta de endereços IPv4.

A falta de endereços IPv4 levou à fragmentação do espaço de endereço que possui várias falhas:

• Despesas administrativas que não apenas custam tempo e dinheiro, mas também são propensas a erros e causaram interrupções.
• O grande uso da capacidade de memória endereçável de conteúdo (CAM) em roteadores de backbone, que há alguns anos leva a uma interrupção significativa em vários ISPs, quando ultrapassou o limite de um modelo popular de roteador.

Sem o NAT, não há como sobreviver hoje com os 3700 milhões de endereços IPv4 roteáveis. Mas o NAT é uma solução quebradiça que oferece uma conectividade menos confiável e problemas difíceis de depurar. Quanto mais camadas de NAT, pior será. Duas décadas de trabalho duro fizeram com que uma única camada de NAT funcionasse principalmente, mas já cruzamos o ponto em que uma única camada de NAT era suficiente para solucionar a escassez de endereços IPv4.

Antes de começarmos a ficar sem endereços IPv4, não usamos (amplamente) o NAT. Todo computador conectado à Internet teria seu próprio endereço globalmente exclusivo. Quando o NAT foi introduzido pela primeira vez, passou de fornecer aos clientes do ISP 1 endereço real por dispositivo que o cliente usava / possuía para fornecer 1 endereço real a 1 cliente. Isso resolveu o problema por um tempo (anos) enquanto devíamos mudar para o IPv6. Em vez de mudar para o IPv6, (principalmente) todos esperavam que todos mudassem e, portanto, (principalmente) ninguém lançava o IPv6. Agora, estamos enfrentando o mesmo problema novamente, mas desta vez, uma segunda camada de NAT está sendo implantada (CGN) para que os ISPs possam compartilhar um endereço real entre vários clientes.

A exaustão do endereço IP não é grande coisa se o NAT não for terrível, inclusive no caso em que o usuário final não tem controle sobre ele (NAT ou CGN de ​​grau de operadora).

Mas eu argumentaria que o NAT é terrível, especialmente no caso em que o usuário final não tem controle sobre ele. E (como uma pessoa cujo trabalho é engenharia / administração de rede, mas possui um diploma em engenharia de software), eu argumentaria que, ao implantar o NAT em vez do IPv6, os administradores de rede mudaram o peso de resolver a exaustão de endereços fora de seu campo e para os usuários finais e desenvolvedores de aplicativos.

Então (na minha opinião), por que o NAT é uma coisa terrível e maligna que deve ser evitada?

Vamos ver se eu posso fazer justiça ao explicar o que quebra (e quais os problemas causados ​​por nós nos acostumamos tanto que nem percebemos que poderia ser melhor):

• Independência da camada de rede
• Conexões ponto a ponto
• Nomeação e localização consistentes de recursos
• Roteamento ideal de tráfego, hosts sabendo seu endereço real
• Rastreando a origem do tráfego malicioso
• Protocolos de rede que separam dados e controlam em conexões separadas

Vamos ver se consigo explicar cada um desses itens.

Independência da camada de rede

Os ISPs devem apenas passar pacotes da camada 3 e não se importar com o que está nas camadas acima disso. Esteja você passando TCP, UDP ou algo melhor / mais exótico (talvez SCTP? Ou mesmo algum outro protocolo que seja melhor que TCP / UDP, mas que seja obscuro por falta de suporte a NAT), seu ISP não deve Cuidado; tudo deve parecer com dados para eles.

Mas isso não acontece - não quando eles estão implementando a "segunda onda" do NAT, NAT "Carrier Grade". Então eles necessariamente precisam examinar e dar suporte aos protocolos da camada 4 que você deseja usar. No momento, isso praticamente significa que você só pode usar TCP e UDP. Outros protocolos seriam apenas bloqueados / descartados (grande parte dos casos na minha experiência) ou apenas encaminhados para o último host "dentro" do NAT que usava esse protocolo (eu já vi 1 implementação que faz isso). Mesmo encaminhar para o último host que usou esse protocolo não é uma correção real - assim que dois hosts o usam, ele quebra.

Eu imagino que existem alguns protocolos de substituição para TCP e UDP por aí que atualmente não são testados e não são usados ​​apenas por causa desse problema. Não me interpretem mal, o TCP e o UDP foram impressionantemente bem projetados e é incrível como os dois foram capazes de escalar a maneira como usamos a Internet hoje. Mas quem sabe o que perdemos? Eu li sobre o SCTP e parece bom, mas nunca o usei porque era impraticável por causa do NAT.

Conexões ponto a ponto

Este é um grande problema. Na verdade, o maior na minha opinião. Se você tiver dois usuários finais, ambos atrás do seu próprio NAT, não importa qual deles tente se conectar primeiro, o NAT do outro usuário descartará o pacote e a conexão não será bem-sucedida.

Isso afeta jogos, bate-papo por voz / vídeo (como o Skype), hospedando seus próprios servidores, etc.

Existem soluções alternativas. O problema é que essas soluções alternativas custam tempo do desenvolvedor, tempo do usuário final e inconveniência ou custos de infraestrutura de serviço. E eles não são infalíveis e às vezes quebram. (Veja os comentários de outros usuários sobre a interrupção sofrida pelo Skype.)

Uma solução alternativa é o encaminhamento de porta, em que você programa o dispositivo NAT para encaminhar uma porta de entrada específica para um computador específico atrás do dispositivo NAT. Existem sites inteiros dedicados a como fazer isso para todos os diferentes dispositivos NAT existentes no mercado. Consulte https://portforward.com/ . Isso normalmente custa tempo e frustração ao usuário final.

Outra solução alternativa é adicionar suporte a coisas como perfuração nos aplicativos e manter a infraestrutura do servidor que não está atrás de um NAT para apresentar dois clientes com NAT. Isso geralmente custa tempo de desenvolvimento e coloca os desenvolvedores em uma posição de manutenção potencial da infraestrutura do servidor, onde ela não seria necessária anteriormente.

(Lembre-se do que eu disse sobre a implantação do NAT em vez de o IPv6 mudar o peso do problema dos administradores de rede para usuários finais e desenvolvedores de aplicativos?)

Nomeação / localização consistente de recursos de rede

Como um espaço de endereço diferente é usado na parte interna de um NAT e no exterior, qualquer serviço oferecido por um dispositivo dentro de um NAT tem vários endereços para alcançá-lo, e o correto a ser usado depende de onde o cliente está acessando. . (Isso ainda é um problema, mesmo depois que o encaminhamento de porta está funcionando.)

Se você possui um servidor Web dentro de um NAT, digamos na porta 192.168.0.23, porta 80, e seu dispositivo NAT (roteador / gateway) possui um endereço externo 35.72.216.228, e você configura o encaminhamento de porta para a porta TCP 80, agora seu o servidor da web pode ser acessado usando a porta 80 ou 192.168.0.23 da porta 80 ou 35.72.216.228 porta 80. O que você deve usar depende se você está dentro ou fora do NAT. Se você estiver fora do NAT e usar o endereço 192.168.0.23, não chegará ao ponto esperado. Se você estiver dentro do NAT e usar o endereço externo 35.72.216.228, poderá chegar onde deseja, se a implementação do NAT for avançada e suportar hairpin, mas o servidor da web que atende sua solicitação verá a solicitação como proveniente do seu dispositivo NAT. Isso significa que todo o tráfego deve passar pelo dispositivo NAT, mesmo se houver um caminho mais curto na rede atrás do NAT, e significa que os logs no servidor da Web se tornam muito menos úteis, porque todos listam o dispositivo NAT como a fonte de a conexão. Se sua implementação de NAT não suportar hairpin, você não chegará aonde esperava.

E esse problema piora assim que você usa o DNS. De repente, se você deseja que tudo funcione corretamente para algo hospedado por trás do NAT, você deve dar respostas diferentes sobre o endereço do serviço hospedado dentro de um NAT, com base em quem está perguntando (AKA split horizon DNS, IIRC). Que nojo.

E isso pressupõe que você tenha alguém com conhecimento sobre encaminhamento de porta e NAT hairpin e DNS de horizonte dividido. E os usuários finais? Quais são as chances de que tudo esteja configurado corretamente quando eles compram um roteador de consumidor e uma câmera de segurança IP e querem que "funcione"?

E isso me leva a:

Roteamento ideal de tráfego, hosts sabendo seu endereço real

Como vimos, mesmo com o hairpin avançado, o tráfego NAT nem sempre flui através do caminho ideal. Isso ocorre mesmo no caso em que um administrador experiente configura um servidor e possui um NAT hairpin. (O DNS com divisão de horizonte concedido pode levar ao roteamento ideal do tráfego interno nas mãos de um administrador de rede.)

O que acontece quando um desenvolvedor de aplicativos cria um programa como o Dropbox e o distribui para usuários finais que não se especializam em configurar equipamentos de rede? Especificamente, o que acontece quando coloco um arquivo de 4 GB no meu arquivo de compartilhamento e tento acessar o próximo computador novamente? Ele é transferido diretamente entre as máquinas ou eu tenho que esperar o upload para um servidor em nuvem por meio de uma conexão WAN lenta e, em seguida, esperar uma segunda vez para fazer o download pela mesma conexão lenta WAN?

Para uma implementação ingênua, ela seria carregada e baixada, usando a infraestrutura de servidor do Dropbox que não está atrás de um NAT como mediador. Mas se as duas máquinas pudessem perceber que estão na mesma rede, elas poderiam transferir o arquivo diretamente muito mais rapidamente. Portanto, em nossa primeira tentativa de implementação menos ingênua, poderíamos perguntar ao sistema operacional qual o endereço IP (v4) da máquina e verificar isso com outras máquinas registradas na mesma conta do Dropbox. Se estiver no mesmo intervalo que nós, basta transferir diretamente o arquivo. Isso pode funcionar em muitos casos. Mas mesmo assim há um problema: o NAT funciona apenas porque podemos reutilizar endereços. E daí se o endereço 192.168.0.23 e o 192.168.0. 42 endereços registrados na mesma conta do Dropbox estão em redes diferentes (como sua rede doméstica e sua rede comercial)? Agora você deve voltar a usar a infraestrutura do servidor Dropbox para mediar. (No final, o Dropbox tentou resolver o problema fazendo com que cada cliente do Dropbox transmitisse na rede local na esperança de encontrar outros clientes. Mas essas transmissões não cruzam nenhum roteador que você possa ter por trás do NAT, o que significa que não é uma solução completa ,especialmente no caso da CGN .)

IPs estáticos

Além disso, como a primeira escassez (e onda de NAT) ocorreu quando muitas conexões de consumidores nem sempre estavam em conexões (como discagem), os ISPs poderiam usar melhor seus endereços alocando apenas endereços IP públicos / externos quando você estava realmente conectado. Isso significava que, quando você se conectava, obtinha qualquer endereço disponível, em vez de sempre obter o mesmo. Isso torna a execução do seu próprio servidor muito mais difícil e o desenvolvimento de aplicativos ponto a ponto, porque eles precisam lidar com os colegas que se deslocam ao invés de estarem em endereços fixos.

Ofuscação da fonte de tráfego malicioso

Como o NAT reescreve as conexões de saída como se fossem provenientes do próprio dispositivo NAT, todo o comportamento, bom ou ruim, é rolado em um endereço IP externo. Não vi nenhum dispositivo NAT que registrasse cada conexão de saída por padrão. Isso significa que, por padrão, a origem do tráfego malicioso passado só pode ser rastreada no dispositivo NAT pelo qual passou. Embora o equipamento da classe da empresa ou da operadora possa ser configurado para registrar cada conexão de saída, eu não vi nenhum roteador de consumidor que faça isso. Eu certamente acho que será interessante ver se (e por quanto tempo) os ISPs manterão um log de todas as conexões TCP e UDP feitas por meio de CGNs à medida que forem lançadas. Esses registros seriam necessários para lidar com reclamações de abuso e DMCA.

Algumas pessoas pensam que o NAT aumenta a segurança. Se isso acontecer, o faz através da obscuridade. A queda padrão do tráfego de entrada que o NAT torna obrigatório é o mesmo que ter um firewall com estado. Entendo que qualquer hardware capaz de fazer o rastreamento de conexão necessário para o NAT possa executar um firewall com estado, para que o NAT realmente não mereça nenhum ponto.

Protocolos que usam uma segunda conexão

Protocolos como FTP e SIP (VoIP) tendem a usar conexões separadas para controle e conteúdo de dados real. Cada protocolo que faz isso deve ter um software auxiliar chamado ALG (gateway da camada de aplicativo) em cada dispositivo NAT por onde passa ou solucionar o problema com algum tipo de mediador ou perfuração. Na minha experiência, os ALGs raramente são atualizados, e foram a causa de pelo menos alguns problemas com os quais eu lidei envolvendo o SIP. Sempre que ouço alguém relatar que o VoIP não funcionou para eles, porque o áudio só funcionou de uma maneira, suspeito instantaneamente que em algum lugar existe um gateway NAT que libera pacotes UDP e não consegue descobrir o que fazer.

Em resumo, o NAT tende a quebrar:

• protocolos alternativos ao TCP ou UDP
• sistemas ponto a ponto
• acessando algo hospedado atrás do NAT
• coisas como SIP e FTP. Os ALGs para contornar isso ainda causam problemas aleatórios e estranhos atualmente, especialmente com o SIP.

No núcleo, a abordagem em camadas adotada pela pilha de rede é relativamente simples e elegante. Tente explicá-lo a alguém novo na rede, e eles inevitavelmente assumem que sua rede doméstica é provavelmente uma rede boa e simples de tentar entender. Eu já vi isso levar em alguns casos a algumas idéias bastante interessantes (excessivamente complicadas) sobre como o roteamento funciona devido à confusão entre endereços externos e internos.

Eu suspeito que, sem o NAT, o VoIP seria onipresente e integrado à PSTN, e que fazer chamadas de um telefone celular ou computador seria gratuito (exceto pela Internet pela qual você já pagou). Afinal, por que eu pagaria pelo telefone quando você e eu podemos simplesmente abrir um fluxo de 64K VoIP e funciona tão bem quanto a PSTN? Hoje parece que o problema número 1 na implantação do VoIP está passando pelos dispositivos NAT.

Suspeito que geralmente não percebemos o quanto as coisas poderiam ser mais simples se tivéssemos a conectividade de ponta a ponta que o NAT quebrou. As pessoas ainda enviam por e-mail (ou Dropbox) os próprios arquivos porque se o problema principal é precisar de um mediador para quando dois clientes estão atrás do NAT.

Um grande sintoma da exaustão do IPv4 que não vi mencionado em outras respostas é que alguns provedores de serviços móveis começaram a usar o IPv6 - há apenas alguns anos. Há uma chance de você estar usando o IPv6 há anos e nem sabia disso. Os provedores móveis são mais novos no jogo da Internet e não têm necessariamente grandes alocações IPv4 preexistentes. Eles também exigem mais endereços que cabo / DSL / fibra, porque seu telefone não pode compartilhar um endereço IP público com outros membros da sua família.

Meu palpite é que os provedores de IaaS e PaaS serão os próximos, devido ao seu crescimento que não está vinculado aos endereços físicos dos clientes. Não ficaria surpreso ao ver provedores de IaaS oferecendo apenas IPv6 com desconto em breve.

Os RIRs principais ficaram sem espaço para alocações normais há um tempo atrás. Para a maioria dos provedores, portanto, as únicas fontes de endereços IPv4 são seus próprios estoques e os mercados.

Existem cenários em que é preferível ter um IP público IPv4 dedicado, mas isso não é absolutamente essencial. Também existem vários endereços IPv4 públicos alocados, mas não atualmente em uso na Internet pública (eles podem estar em uso em redes privadas ou podem não estar em uso). Finalmente, existem redes mais antigas com endereços alocados muito mais livremente do que precisam.

Os três maiores RIRs agora permitem a venda de endereços entre seus membros e entre si. Portanto, temos um mercado entre organizações que possuem endereços que não estão usando ou que têm endereços que podem ser liberados por um custo por um lado e organizações que realmente precisam de mais endereços IP por outro.

O que é difícil prever é quanta oferta e demanda haverá a cada preço e, portanto, o que o preço de mercado fará no futuro. Até agora, o preço por IP parece ter permanecido surpreendentemente baixo.

Idealmente, todos os hosts da Internet devem obter um endereço IP de escopo global; no entanto, a exaustão do endereço IPv4 é real, na verdade o ARIN já ficou sem endereço em seu pool gratuito .

A razão pela qual todos ainda podem acessar bem os serviços da Internet é graças às técnicas de conversão de endereços de rede (NAT) que permitem que vários hosts compartilhem endereços IP públicos. No entanto, isso não ocorre sem problemas.

Os ISPs costumavam distribuir blocos de 256 endereços IP às empresas. Agora, os provedores de serviços de Internet são mesquinhos e oferecem a você (uma empresa) como 5. Na época (2003), todos os PCs e dispositivos conectados em sua casa tinham seu próprio endereço IP de Internet. Agora, o roteador a cabo / DSN / Fios possui um endereço IP e fornece endereços IP 10.0.0.x a todos os PCs em sua casa. Resumo: os ISPs costumavam desperdiçar endereços IP e agora não os desperdiçam mais.

Você já tem muitas respostas excelentes, mas eu gostaria de acrescentar algo que ainda não foi mencionado.

Sim, a exaustão do endereço IPv4 é ruim, dependendo de como você a mede. Algumas empresas ainda têm uma enorme oferta de endereços IPv4, mas estamos começando a ver soluções alternativas, como NAT de operadora.

Mas muitas das respostas estão erradas quando se desviam para o IPv6.

Aqui está uma lista de tecnologias que podem ajudar a lidar com a falta de endereços IPv4. Cada um tem suas próprias vantagens e desvantagens.

• IPv6

  • Vantagem: padronizada e disponível na maioria dos sistemas operacionais.
  • Desvantagem: apesar das frequentes declarações em contrário, sérios problemas de segurança. Já em 2005, o US CERT alertou para problemas de segurança causados ​​pelo endereçamento global do IPv6. O IPv6 pode ser protegido adequadamente, mas, devido ao estado dos roteadores de consumidor, isso pode não acontecer.
  • Desvantagem: a migração leva tempo, dinheiro e conhecimento.
  • Desvantagem: muitos dispositivos de consumo são seriamente falhos. Por exemplo, vários roteadores D-Link suportam IPv6 simplesmente encaminhando todo o tráfego sem oferecer nenhum firewall.

Outra consideração: mesmo se o IPv6 travar completamente hoje, ainda levaria mais 20 anos para eliminar o IPv4, devido ao equipamento herdado que as pessoas usarão por muito tempo (ainda vejo servidores Windows 2003 e estações de trabalho Windows XP para não mencionar todas as impressoras, câmeras e gadgets de IoT que não oferecem suporte ao IPv6).

• CGNat:
  • Vantagem: funciona sem alterações nas instalações do cliente.
  • Desvantagem: suporta apenas conexões de saída.
  • Desvantagem: pode não suportar alguns protocolos.

Eventualmente, o CGNat não será suficiente. Talvez o IPv6 continue assim, mas também é bem possível que acabemos vendo o NAT de nível nacional ou algo assim.

Atualmente, como consultor, muitas vezes tenho que apontar para meus clientes que eles estão expostos ao IPv6 (muitas vezes graças a Teredo). A próxima pergunta será invariavelmente: "quanto custa para consertar isso?" e depois "Quanto custa para bloqueá-lo? O que perdemos se o desativarmos?" Adivinhe qual será a decisão sempre.

Conclusão: para responder sua pergunta, sim, a exaustão do IPv4 é real. E veremos alguns mecanismos para lidar com isso. O IPv6 pode ou não acabar sendo a equação.

Para ser claro: não estou dizendo que gosto dessa situação. Gostaria que o IPv6 fosse bem-sucedido (e gostaria de ver várias melhorias no IPv6). Eu só estou olhando para a situação no momento.

NAT foi o que aconteceu quando o IPv6 era uma idéia, antes que fosse realidade, e a alocação de endereços IP estava se tornando um problema real (alguém se lembra de quando eles estavam distribuindo classes C basicamente para perguntar?) E o mundo real precisava de uma solução nesse meio tempo .

O NAT não é suficiente para a IoT. Se a IoT acontecer, acontecerá com o IPv6. A natureza da IoT está mais alinhada com o funcionamento do mundo dial-up, exceto que haverá várias ordens de magnitude a mais de dispositivos conectados ao mesmo tempo.

A questão do endereço IPv4 inteiro é bastante complicada. Você pode encontrar um artigo relatando que está esgotado, mas outro falando sobre um grande número de endereços excedentes (nunca usados) sendo vendidos de uma parte para outra. A questão seria: por que eles não estão disponíveis para aqueles (regiões emergentes e áreas rurais dos países desenvolvidos) com falta deles?

Abaixo está o resultado de um estudo em que nos aventuramos acidentalmente. Ele utiliza nada mais que o protocolo IPv4 original RFC791 e o bloco de endereços 240/4, reservado há muito tempo, mas pouco utilizado, para expandir o pool de IPv4 em 256M vezes. Enviamos um projeto de proposta chamado EzIP (fonético para Easy IPv4) à IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Basicamente, a abordagem EzIP não apenas resolverá problemas de falta de endereço IPv4, mas também reduzirá amplamente a causa raiz das vulnerabilidades de segurança cibernética, além de abrir novas possibilidades para a Internet, tudo dentro dos limites do domínio IPv4. De fato, esse esquema pode ser implantado "furtivamente" para regiões isoladas, quando necessário. Isso deve aliviar a urgência de implantar o IPv6 por um período apreciável e invalidar o mercado de negociar os endereços IPv4.

Qualquer pensamento ou comentário será muito apreciado.

Abe (2018-07-15 17:29)

Honestamente, acho que não é tão ruim quanto as pessoas pensam. Sim, talvez em alguns lugares, mas não tanto porque não há endereços suficientes. É porque eles são todos de propriedade. Talvez seja a minha localização ou algo assim, mas eu trabalhei com TI para várias empresas de pequeno e médio porte nos últimos sete anos, e todas as coisas de que você está falando geralmente são apenas configurações padrão. Muito fácil, a menos que você tenha um dispositivo de baixa qualidade ou uma instalação de merda com a rede em primeiro lugar que precisa ser resolvida.

Pessoalmente, estou bem com o NAT. É uma camada adicional de proteção, de um modo geral. Pelo menos eles precisam passar por um dispositivo extra ou encontrar uma maneira de seqüestrar indiretamente minha conexão. No que diz respeito à execução de servidores, isso geralmente está fora e / ou é considerado uma quebra de contrato com seu ISP, a menos que você esteja pagando por isso. Claro que você pode fazê-lo, e eles provavelmente não o incomodarão, mas podem.

Encaminhamento de porta e tudo o que não é exatamente complicado. Agora, talvez alguns dispositivos não sejam fáceis de configurar, mas isso não é devido ao IPv4. Ainda oferece a maior compatibilidade simplesmente porque é onipresente.

Na verdade, ninguém precisa enviar um e-mail para si mesmo, e enviar algo para o Drop-box ou Google Drive, ou um milhão de outros serviços semelhantes, não é exatamente ciência do foguete, nem é lento hoje em dia. Quero dizer, tudo é sincronizado. Você o solta em uma pasta. A menos que você seja nerd como eu e faça tudo através do ssh / sftp (tudo bem, não tudo ). E se você tem algum motivo para realmente executar seu próprio servidor, a hospedagem na nuvem é barata - eu tenho um servidor virtual dedicado que executa o linux em um ssd. A largura de banda é louca rapidamente. Inicializa mais rápido do que eu posso digitar uma seta para cima e pressionar Enter. E é escalável Toda a configuração custa entre 5 e 10 dólares por mês, com backups gratuitos e sem conta de luz.

Realmente não precisa de uma solução de rede ponto a ponto. Até a maioria dos jogos para vários usuários hoje em dia está configurada para interagir através de um servidor intermediário, configurada e pré-configurada. Por outro lado, se o que estou lendo neste post for verdadeiro, a TI estará superlotada e barata se / quando o IPv6 decolar. Até os celulares estão se aproximando da velocidade de fibra. Ou pelo menos cabo.

Se você executa um servidor interno e precisa acessá-lo com o mesmo nome de domínio dentro ou fora da rede, sempre pode falsificar seu endereço usando um roteador baseado em linux e dnsmasq ou entradas personalizadas nos hosts para redirecioná-lo para o endereço local, se você estiver do lado de dentro.

Realmente, não acho que seja realmente desejável que todos os dispositivos tenham seu próprio endereço flutuando aberto na rede. Se alguém quiser ofuscar a si mesmo enquanto o ataca, isso vai acontecer de qualquer maneira. Mas você é um pato sentado, se você está apenas sentado lá bolas na brisa aberta. Não, vou levar meu IPv4 e meu NAT a qualquer dia. Mas é bom que esteja lá.

De qualquer forma, adormecendo agora ... provavelmente mais a dizer, mas vou fazer o check-in amanhã, caso perca alguma coisa. Tenho certeza de que há mais.