Como o tráfego de rede de encaminhamento da VPN? (Camada 3)


8

Estou procurando algumas informações sobre como as VPNs (Rede Privada Virtual) encaminham o tráfego de rede através de seu VPS (Servidor Privado Virtual).

Veja um exemplo em que você está conectado a uma VPN. Você faz uma solicitação para um site, que desce a pilha de rede até a Camada 3.

Temos um pacote IP - ele possui cabeçalhos, incluindo o endereço de destino e uma carga útil.

Se você alterar o endereço de destino do pacote IP para o endereço IP do VPS, como o servidor encaminha a solicitação para o endereço de destino original?

A única coisa em que consigo pensar é que, na Camada 3 (a Camada IP), o endereço de destino do cabeçalho é alterado para o endereço IP do VPS e o endereço de destino original é anexado à carga útil do pacote.

Isso não significa que o comprimento do pacote e o cabeçalho da soma de verificação do pacote precisariam ser recalculados e o pacote IP novamente modificado?

E o VPS faz o mapeamento inverso do pacote para montar e fazer a solicitação original no servidor.

Parece que haveria um tempo de alta latência associado a ele?

Talvez esteja faltando algum aspecto técnico de como isso funciona. Alguém mais pode explicar isso?

Respostas:


7

Tomemos, por exemplo, o cabeçalho do GRE (o GRE é um protocolo usado para realizar VPNs - geralmente não é usado, pois não é seguro, mas o conceito com encapsulamento é quase o mesmo em todas as conexões VPN (também com o IPsec, por exemplo) ):

insira a descrição da imagem aqui

Como você pode ver, o pacote original é encapsulado em outro pacote IP.

Vamos supor que existem duas redes / roteadores (A e B, um roteador pode ser um VPS) conectado entre si por meio de uma VPN (site a site).

Se um host na rede A quiser acessar um servidor FTP na rede B, o host na rede A enviará um pacote, onde o endereço de destino é o endereço IP do servidor FTP e o endereço de origem é seu.

Em seguida, o pacote original chega ao VPN-Gateway (provavelmente seu roteador), que encapsula esse pacote original em, por exemplo, um pacote IPv4 em que o endereço de destino é o VPN-Gateway (rede B) e o endereço de origem é seu. Dessa forma, o pacote pode viajar pela Internet para o outro VPN-Gateway (rede B). Aqui, o protocolo / cabeçalho ou tipo de pacote original não importa, pois será encapsulado com um cabeçalho IPv4 para viajar pela Internet e outros roteadores não se importarão com o protocolo / cabeçalho original, pois apenas veem o "novo" Cabeçalho IPv4.

Uma nova soma de verificação para o pacote "novo" deve ser calculada e anexada; caso contrário, não seria possível viajar pela Internet (como por exemplo, o PPP às vezes é usado entre pontos na Internet, que calcula uma soma de verificação). Portanto, deve haver duas somas de verificação no pacote inteiro.

Com o IPsec (que é usado quase sempre para conexões VPN), o pacote original é criptografado (principalmente via AES) e um cabeçalho de texto sem formatação (o cabeçalho "novo" para viajar pela Internet). Ele deve ser texto sem formatação para que possa ser roteado corretamente. Para isso, uma nova soma de verificação também deve ser calculada (como a soma de verificação original é criptografada).

Quando atinge o outro gateway VPN (rede B), o cabeçalho da VPN é desmontado e o pacote original é enviado para a rede (para o servidor FTP).


Então você está dizendo que o roteador é responsável por encapsular o pacote, e não o dispositivo?
cg14

11
@ cg14 boa pergunta! Existem dois tipos de VPNs, como VPNs site a site (VPN Gateway to VPN Gateway (principalmente roteador a roteador)) e VPNs de ponta a ponta (o dispositivo final se conecta por meio de uma VPN a um gateway VPN). Com o Site a site, o roteador é responsável pelo encapsulamento do pacote. Com o site, o próprio dispositivo cria o "pacote original" que é encapsulado pelo cliente VPN instalado nele. Após o encapsulamento, o dispositivo envia o pacote.
Watchme

Isso é interessante. Para uma VPN ponto a ponto, em que camada o pacote original está encapsulado? E, em teoria, se eu quisesse dizer, transmitir algum identificador além do IP, como um ID de dispositivo do cliente VPN, haveria uma maneira de anexar essas informações à carga útil, de forma que a carga útil possa ser | Cabeçalho IP | Cabeçalho do GRE | informação injectada + pacote original. E, dependendo de onde ocorre a injeção de dados personalizados no pacote encapsulado, você determinaria se seria necessário recalcular a soma de verificação e o comprimento do pacote gre que eu assumo.
Cg14

Eu não sei exatamente o que você quer dizer, infelizmente. Mas explicarei um pouco o IPsec para responder à sua pergunta "em que camada". Quando um cliente envia o pacote original (digamos TCP, IP, Ethernet), ele é totalmente criptografado. Esta é a nova "carga útil". Então, você pode enviar carga útil normal pela internet? Provavelmente não. Você precisará de algumas informações. Esta informação é então adicionada pelo cliente VPN - então as informações das camadas 4,3 e 2!
Watchme

@ cg14 Está tudo claro para você? :) ... (Ah, eu só percebi que eu não tenha marcado você em minha resposta à sua "no que layer" -Pergunta, sorry)
WatchMe

6

Portanto, a resposta curta para sua pergunta é encapsulamento. Isso significa que há outro conjunto de cabeçalhos de pacote colocados no pacote que você está enviando para um site que é retirado pelo ponto de extremidade da VPN.

Pense desta maneira:

-----------------------------------------------
| src_ip=2.2.2.2, dest_ip=3.3.3.3             |
|---------------------------------------------|
|| src_ip=10.10.10.10, dest_ip=5.5.5.5       ||
|| Data goes here. This could be a HTTP GET  ||
|| or pretty much anything.                  ||
|---------------------------------------------|
-----------------------------------------------

Seu cliente VPN em execução na sua máquina local fornecerá um novo endereço IP (10.10.10.10) e alterará sua tabela de rotas de forma que a rota padrão seja direcionada para o túnel criado. Ele enviará o tráfego para o servidor VPN ou, no seu exemplo, um VPS (3.3.3.3). Freqüentemente, seu pacote terá um NAT aplicado quando for descapsulado; portanto, para o servidor de destino (5.5.5.5), parecerá que o tráfego está vindo do IP de destino do tráfego encapsulado (3.3.3.3). o tráfego retorna para você, primeiro acessando o servidor VPN.

Vamos para a terceira pergunta. Como você está colocando um pacote adicional essencialmente do lado de fora, o comprimento e a soma de verificação são calculados no pacote resultante. Então, sim, existem dois comprimentos e duas somas de verificação. Quanto ao tamanho máximo que é feito pelo VPS dizendo, use este MTU ou através da descoberta de MTU como normal.

Quanto à latência. Você não pode quebrar a física. Você será responsável pela sobrecarga de acessar o VPS e executar sua pilha de rede. Embora possa parecer que haja uma alta latência, isso às vezes não é o caso. Se o seu VPS estiver topologicamente alinhado com o local em que o pacote já está indo, pode haver uma sobrecarga mínima adicionada. Por exemplo, se você estiver em Seattle e seu VPS estiver em Nova York e o site com o qual você está tentando conversar estiver em Londres. Mas se você estiver indo de Seattle para Nova York para voltar a um site em Seattle, haverá uma latência adicional da viagem pelos Estados Unidos.


3

Um pacote é criado pela camada de transporte e passado para a camada de rede. O host examina sua tabela de roteamento e a envia para a interface virtual criada pelo software VPN.

O software VPN pega o pacote da interface virtual. Ele pode criptografá-lo ou adicionar seus próprios cabeçalhos e, em seguida, devolvê-lo à pilha de rede como uma carga útil. Dependendo da implementação específica da VPN, ela pode passar essa carga útil para a camada de transporte ou ignorar a camada de transporte e ir diretamente para a camada de rede.

Outra camada de cabeçalhos da camada de rede é então adicionada ao direcionamento de pacotes ao servidor VPN. O pacote é pesquisado novamente na tabela de roteamento e enviado à Internet (se a VPN é de "cobertura total", o software VPN deve tomar cuidado para configurar a tabela de roteamento de maneira que o tráfego da VPN saia do interface real voltada para a Internet em vez de retornar ao software VPN).

Quando o pacote encapsulado chega ao servidor VPN, ele é devolvido ao software VPN. Os cabeçalhos "externos" são removidos e o pacote é passado de volta à pilha de rede através de uma interface virtual.

Depois disso, cabe à pilha de rede no servidor VPN o que fazer com ele. No caso de uma VPN usada para acesso à Internet, a pilha de rede no servidor VPN provavelmente será configurada para atuar como um roteador NAT, portanto, modifica a fonte do pacote e a envia de volta à Internet.

Quando a resposta volta, acontece o mesmo processo. O pacote chega, o processo NAT é revertido, é passado de volta para o software VPN pela interface virtual, é encapsulado e enviado de volta ao software VPN no cliente que o desencapsula e passa para a pilha da rede para que pode ser entregue ao aplicativo cliente.


ok, bem, isso provavelmente é uma explicação melhor que a minha!
Watchme
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.