
Tenho dois clientes que precisam se conectar a um servidor OpenVPN. É possível usar o mesmo gateway para ambos os clientes no parâmetro ifconfig?
Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1
Client B config file
[...]
ifconfig 10.0.0.3 10.0.0.1
A situação no servidor é a seguinte:
tun0
inet 10.10.0.1 destination 10.10.0.2
tun1
inet 10.10.0.1 destination 10.10.0.3
Agora tudo está funcionando bem, mas isso pode causar algum problema?
Disseram-me para usar um gateway diferente como este:
Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1
Client B config file
[...]
ifconfig 10.0.1.2 10.0.1.1
Mas pensei que um gateway diferente fosse necessário apenas para fins de roteamento, se eu quiser adicionar uma rota e encaminhar meu tráfego em uma interface tun específica, eu realmente preciso de um gateway diferente ou o servidor não sabe para qual enviar os pacotes, mas se eu não não preciso de uma rota específica posso usar minha primeira configuração?
Obrigado
Responder1
É possível e correto. O parâmetro gateway define a configuração do cliente que será utilizado para enviar dados à VPN, para que seja possível definir o roteamento normalmente em IP. Uma vez que o pacote é enviado para o processo OpenVPN, ele cuida do seu roteamento (até sair de algum outro processo OpenVPN).
Em particular, você define:
ifconfig 10.10.0.3 10.10.0.1
OapenasO resultado deste comando é como se você executasse os seguintes comandos no cliente:
ip address add 10.10.0.3 dev tun0
ip route add 10.10.0.1 dev tun0
Isso é tudo. Outros clientes, um servidor, sistemas externos — ninguém mais sabe sobre a configuração deste cliente.
A única coisa onde o gateway é usado é escrever rotas para VPN assim:
ip route add 192.168.0.0/24 via 10.10.0.1
por exemplo, para configurar esta rede para ser acessível através de VPN. Por exemplo, a rota para o servidor VPN e outros clientes é feita assim. É claro que, se você tiver vários clientes, poderá usar o mesmo endereço de gateway neles (e você faz isso naturalmente, por exemplo, para computadores vizinhos na mesma LAN).
A mesma coisa também se aplica a um servidor. Por exemplo, eu executo várias VPNs em uma única máquina (uma é via UDP, a outra é via TCP na porta 443 com opção de compartilhamento de porta — para poder passar furtivamente por firewalls que bloqueiam portas normais, mas permitem 443 e até verificar se há é um servidor web). Esses servidores têm o mesmolocalendereço configurado e diferem porcontrolo remoto(isso torna possível definir por qual VPN eu roteio o pacote).
Agora, sobre os problemas que você encontrará. Com o Linux OpenVPN completo, não há problemas, é claro. Se você for usar o "Cliente OpenVPN", seja ele cliente Linux, Windows, iOS/iPadOS/macOS ou Android, depende de qual topology
você definir. Na net30
topologia eles rejeitarão tal configuração como inválida. Neste caso, o endereço do cliente e seu remoto devem pertencer à mesma sub-rede /30.
Responder2
Normalmente, uma interface ponto a ponto, como tun0
qualquer outra interface semelhante a um túnel, precisa de um endereço local apenas para fins de gerenciamento de túnel ou para uma identificação específica de túnel.
Pense em uma interface de túnel como um endpoint conectado remotamente. Esta interface tem duas extremidades - você eO outro fim. Em geral, não há necessidade de usarqualquerendereços em interfaces como esta quando apenas duas partes conectadas estão envolvidas na troca de dados - você pode simplesmente enviar um pacote por esta interface e ele será entregue na outra extremidade, não há outra maneira.
As coisas ficam um pouco mais complicadas se algum terceiro precisar acessar seu endpoint remoto conectado. Para chegar a esse ponto final, eles precisarão de umendereço remotocomo destino de pacote. O lado remoto, por outro lado, usa seu endereço local para identificar sua versão doO outro fimquando necessário, ou seja, ele instala a rota padrão para ele; no entanto, ele poderia usar a própria interface do túnel como destino da rota, mesmo sem saber seu endereço local e ainda funcionaria.
Portanto, a menos que você precise identificar sua interface de túnel por seu endpoint local (ou seja, para usá-la como endereço de origem para determinados cenários de protocolo de roteamento dinâmico no túnel), você pode usar qualquer endereço que desejar como endereço local no túnel - isso não acontece. nem precisa estar na mesma sub-rede que o endereço remoto.