Descobri recentemente que todos os meus dispositivos conectados a um roteador WiFi têm o mesmo IP externo. Chame-o 20.20.20.20. O que não entendo é como o roteador descobre de qual pacote IP vindo WANdeve ser encaminhado para qual dispositivo em WLAN.
Precisamente tenho a seguinte topologia:
PC (192.168.1.149) --
|
|-----> (192.168.1.1) WiFi router (20.20.20.20) ----> WAN
|
Phone (192.168.1.139) --
A princípio, pensei que o roteador encaminhasse todo o tráfego proveniente WANde todos os dispositivos, mas a captura tcpdumpem um PCnão mostrava o tráfego para o telefone. Ao pesquisar no Google, entendo que todos os roteadores fazem NAT, mas a questão é como iptables -t natficaria no caso?
Precisamente, como a TCPconexão de ambos PCe Phonepara o mesmo IP externo, por exemplo, 30.30.30.30e porta 22222é tratada.
Além disso, se eu enviar um pacote IP aleatório para o IP, 20.20.20.20para qual dispositivo ele será encaminhado?
O seguinte é uma explicação muito básica.
Seus dispositivos usam endereços privados. Endereços privados são sub-redes/redes com os seguintes endereços IP (consulte RFC 1918 ):
Endereços privados não são roteados pela Internet (em teoria, eles podem ser roteados por ISPs que os bloqueiam). Eles (endereços privados) são traduzidos via NAT (Network Address Translation) ou PAT (Port Address Translation) usando seu endereço público.
Para o mundo externo, os pacotes que saem do seu roteador têm o mesmo endereço. Seu roteador ao receber pacotes que devem ser encaminhados para rede externa adiciona um número de porta (no caso de PAT) para diferenciar o dispositivo que o enviou. Ele randomiza o número da porta e evita que a mesma porta seja usada por dois dispositivos em sua tabela de roteamento. Assim, embora seja utilizado o mesmo endereço público, o número da porta será diferente.
O NAT ainda é um recurso "add-on" sobre o roteamento real. Quando chega uma resposta, depois do NAT, ela ainda segue o processo de roteamento normal.
É apenas uma regra – a maior parte do trabalho é feita por um subsistema "conntrack" separado.
Para conexões de saída, o roteador precisa apenas de uma única regra
SNATouMASQUERADE:(As duas ações são idênticas, exceto por 'MASQUERADE' escolher automaticamente qual endereço IP usar - ele usará qualquer endereço que a interface WAN tenha, enquanto 'SNAT' requer que um seja especificado na regra.)
A tabela inteira
-t naté especial porque os pacotes só passam por ela quando não são correspondidos por nenhum estado de rastreamento. Você pode usarconntrack -Lpara ver uma lista de estados ativos.O primeiro pacote de uma conexão atinge a regra do iptables e estabelece o estado, todo o resto é feito pelo conntrack – quando chega uma resposta, a tradução inversa é feita pelo conntrack.
(Conntrack é usado tanto pelas regras de filtro quanto pelas regras NAT – por exemplo, a
-m state --state establishedregra de filtro comum também depende do mesmo conntrack, mesmo que nenhum NAT seja feito – então não se surpreenda se você ver uma tonelada de estados mesmo em um não- sistema de roteador ou em um roteador que não está configurado para NAT.)"Encaminhamento de porta" é semelhante; é uma
DNATregra.As duas conexões vêm de diferentes portas de origem . É a mesma situação de quando seu navegador web faz duas conexões idênticas com o mesmo servidor – mesmo que a porta de destino seja igual, a porta de origem é escolhida aleatoriamente para resultar em uma combinação única
(src, dst, proto, sport, dport).Com o NAT, caso ambos os dispositivos escolham a mesma porta de origem, o roteador traduzirá a porta de origem para manter a exclusividade.
(Tenho um exemplo melhor em Como um servidor de internet responde a uma solicitação de um IP privado? )
Ao examinar a tabela conntrack, observe como os campos "orig" e "reply" incluem não apenas o endereço IP, mas também a porta. Se um pacote de entrada chega a REPLY-IP:REPLY-PORT, é NATed para ORIG-IP:ORIG-PORT, permitindo que a porta "local" (porta de origem da perspectiva do PC) seja exclusiva, se necessário.
Nenhum, a menos que uma regra do iptables explicitamente o NAT para algo.
O endereço IP da WAN não pertence à sua LAN como um todo – ele pertence especificamente ao roteador como um dispositivo, portanto, por padrão, esses pacotes são tratados como se você estivesse se conectando ao próprio roteador .
Eles rastreiam as portas em cada nível de dispositivo ativo.
O ip externo está na rede da wan, então as conexões a ele serão tratadas pelo roteador através de uma porta local e remota específica no TCP/IP ou "Transport Layer".
Caso contrário sim não teria como fazer NAT.
Para verificar novamente, a resposta foi feita uma pesquisa.
Resposta Nat
Parece que alguém concorda. E sinceramente é a única coisa que faz sentido.
Portanto, na rede atrás do roteador e com a outra camada de hardware de rede local, a camada 2 é visível, que contém o hardware ou o endereço mac das peças do equipamento "ativo" envolvido em uma conversa de rede.
Esses endereços não passam da sub-rede local, que geralmente é encerrada logicamente quando o tráfego chega a um roteador.
Os endereços IP são atribuídos pelo dispositivo local ou pelo servidor dhcp e aplicados.
Nos bons velhos tempos caóticos, isso poderia resultar no que é chamado de colisão de IP quando dois endereços de camada dois tinham o mesmo endereço de camada 3.
Agora, tudo isso é para conveniência da rede local, pois obviamente o endereço IP externo é alugado por um ISP no caso de conexões à Internet por meio de hardware que faz interface com sua rede.
Seus computadores e dispositivos desejam acessar endereços de Internet, mas todos compartilharão o endereço IP na porta wan do roteador, portanto, quais informações são comumente incluídas ao forjar uma conexão de soquete TCP/IP ou abrir uma porta de software para escutar conexões de entrada?
A porta de software de um servidor de escuta começa da mesma forma, pois anuncia seu serviço por meio dessa porta.
A nota lateral confrontando nossa partida da realidade da realidade mais uma vez.
A maneira como as redes são projetadas, se você mudar a máscara de sub-rede, precisará de um roteador para passar o tráfego de rede de uma para a outra porque o intervalo de endereços não corresponde. Isso também foi feito para controlar o tráfego com mais eficiência, em vez de apenas agir como um hub e repetir o pacote de cada porta até que outro dispositivo respondesse.
De qualquer forma, forjei uma conexão com www.google.com:80 .
Meu endereço IP é 192.168.1.2.
O roteador, um dispositivo de camada 3, vê isso e diz... 'bem, diabos, o que fazer... o que fazer...'. Ele verifica sua tabela de roteamento para uma rota padrão configurada ou para um intervalo de IP específico, e o roteador diz "o endereço IP de destino é este, se eu tiver um intervalo de IP configurado associado a uma porta de hardware específica, use esta rota, caso contrário, use o rota padrão", então ele traduz os endereços para a próxima rede em que o IP da porta de hardware está definido.
Então, o que ele faz é atualizar uma estrutura de dados listando conexões que deveriam estar em andamento entre ips locais e ips em outros lugares, e tem uma tabela que diz "qual porta atinge este endereço IP".
então diz "ok, ei google (desculpe o jogo de palavras), ei google, quero me conectar a você na porta 80" agora o endereço IP externo é o que o google vê.
então o google diz "Ok, bem, eu preciso limpar esta porta para aceitar outras conexões, então aqui está a primeira porta disponível 62433" (ou talvez seja aleatório, quem se importa). Enquanto isso, seu dispositivo local já decidiu qual é a porta local, que diremos ser 5020, e o roteador disse "ok, estou conectando em seu nome, fale comigo na porta 6120", mas o roteador está falando com google em 62433 e o google está falando com ele na porta 5111.
então você tem uma estrutura de dados que provavelmente acompanhará a idade da conexão para fins de tempo limite e diga:
192.168.1.2, 5020, 6120, www.google.com , 5111,62433,
agora a transação pode continuar.
google através de vários saltos de rede que replicam isso, retransmite sua resposta da porta 62433 (que pode ser a porta fornecida por outro roteador) para seu endereço IP externo na porta 5111, o roteador procura e diz "OH ITS THIS ITEM, AND ITS GOING TOOOOOOOO" 192.168.1.2 NA PORTA 5020 DA PORTA 6120, QUE ESTÁ NESTA PORTA FÍSICA (Ou wifi, desculpe, então não há portas apenas o dispositivo wlan), e atualiza os cabeçalhos da camada de transporte e, em seguida, descarta um frame na rede local, depois de fazer muito barulho e aguardar a confirmação de recebimento do pacote.
faz sentido ?
PS observe com certeza em qual formato ele armazena a data da última atividade, mas isso seria necessário, caso contrário, você teria várias portas sendo consumidas por conexões que estavam sendo feitas e seu hardware não teria mais portas de software no caso de conexões perdidas ou tempos limite.
Tenho certeza de que o ip de origem do host na wan é sempre mantido o mesmo quando a resposta é enviada de volta, então toda a mágica que acontece entre replica esse processo a cada grande salto de hardware.
Você pode ver isso até certo ponto, embora parte dele seja ofuscado usando o utilitário traceroute, que mostrará os saltos.
Você também pode visualizar a atividade empacotada usando um farejador de pacotes como o wireshark.