Estou tentando usar o OpenVPN como cliente no NetBSD usando este comando:
openvpn --client --config /etc/openvpn/config.ovpn
Estou recebendo a seguinte saída e erros:
localhost# openvpn --client --config /etc/openvpn/openvpn.ovpn
2024-04-26 10:29:35 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-04-26 10:29:35 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2024-04-26 10:29:35 OpenVPN 2.6.10 x86_64--netbsd [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] [AEAD]
2024-04-26 10:29:35 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10
Enter Auth Username:********
Enter Auth Password:********
2024-04-26 10:32:48 TCP/UDP: Preserving recently used remote address: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 Socket Buffers: R=[32768->32768] S=[32768->32768]
2024-04-26 10:32:48 Attempting to establish TCP connection with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCP connection established with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCPv4_CLIENT link local: (not bound)
2024-04-26 10:32:48 TCPv4_CLIENT link remote: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2024-04-26 10:32:48 TLS: Initial packet from [AF_INET]**.191.33.**:1701, sid=0006909e 9b0d208f
2024-04-26 10:32:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-04-26 10:32:48 VERIFY OK: depth=1, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_CA, CN=UniFi_OpenVPN_CA
2024-04-26 10:32:48 VERIFY KU OK
2024-04-26 10:32:48 Validating certificate extended key usage
2024-04-26 10:32:48 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-26 10:32:48 VERIFY EKU OK
2024-04-26 10:32:48 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_Server, CN=UniFi_OpenVPN_Server
2024-04-26 10:33:53 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-04-26 10:33:53 [UniFi_OpenVPN_Server] Peer Connection Initiated with [AF_INET]**.191.33.**:1701
2024-04-26 10:33:53 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-04-26 10:33:53 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-04-26 10:33:53 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.7.1,route 192.168.4.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.1.0 255.255.255.0,route 192.168.3.0 255.255.255.0,route-gateway 192.168.7.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.7.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2024-04-26 10:33:53 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route-related options modified
2024-04-26 10:33:53 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-04-26 10:33:53 TUN/TAP device /dev/tun0 opened
2024-04-26 10:33:53 /sbin/ifconfig tun0 192.168.7.2 192.168.7.1 mtu 1500 netmask 255.255.255.0 up
2024-04-26 10:33:53 /sbin/route add -net 192.168.7.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.7.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net **.191.33.** 192.168.1.254 -netmask 255.255.255.255
route: writing to routing socket: File exists
add net **.191.33.**: gateway 192.168.1.254: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 0.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 0.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 128.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 128.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.4.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.4.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.2.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.2.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.1.0 192.168.7.1 -netmask 255.255.255.0
route: writing to routing socket: File exists
add net 192.168.1.0: gateway 192.168.7.1: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 192.168.3.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.3.0: gateway 192.168.7.1
2024-04-26 10:33:53 GID set to nogroup
2024-04-26 10:33:53 UID set to nobody
2024-04-26 10:33:53 Initialization Sequence Completed
2024-04-26 10:33:53 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'lzo'
2024-04-26 10:33:53 Timers: ping 10, ping-restart 60
Tenho uma conexão de Internet funcionando ao executar o OpenVPN como cliente, mas não consigo acessar nenhuma das máquinas na rede **.191.33.**, sei que deveria ser capaz de fazer SSH em 192.168.1.114, mas não consigo acessar essa máquina através do OpenVPN , existem regras de firewall na caixa Ubuiquity permitindo tráfego de 192.168.7.* a 192.168.1.* Eu sei que isso está funcionando, foi testado em Mac e PC usando o cliente OpenVPN, simplesmente não consigo fazê-lo funcionar NetBSD
Esta é minha tabela de roteamento antes de executar o OpenVPN:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
Esta é minha tabela de roteamento ao executar o OpenVPN:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
0/1 192.168.7.1 UGS - - - tun0
default 192.168.1.254 UGS - - - iwn0
**.191.33.**/32 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
128/1 192.168.7.1 UGS - - - tun0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.2/24 192.168.7.1 UGS - - - tun0
192.168.3/24 192.168.7.1 UGS - - - tun0
192.168.4/24 192.168.7.1 UGS - - - tun0
192.168.7/24 192.168.7.1 UGS - - - tun0
192.168.7.1 192.168.7.2 UH - - - tun0
192.168.7.2 tun0 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
Esta é minha tabela de roteamento após interromper o OpenVPN:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
0/1 192.168.7.1 UGS - - - tun0
default 192.168.1.254 UGS - - - iwn0
**.191.33.**/32 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
128/1 192.168.7.1 UGS - - - tun0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.2/24 192.168.7.1 UGS - - - tun0
192.168.3/24 192.168.7.1 UGS - - - tun0
192.168.4/24 192.168.7.1 UGS - - - tun0
192.168.7/24 192.168.7.1 UGS - - - tun0
192.168.7.2 tun0 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
Esta é minha tabela de roteamento quando destruí o tun0:
ifconfig tun0 destroy
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 192.168.1.254 UGS - - - iwn0
**.191.33.**/32 192.168.1.254 UGS - - - iwn0
127/8 127.0.0.1 UGRS - - 33624 lo0
127.0.0.1 lo0 UHl - - 33624 lo0
192.168.1/24 link#2 UC - - - iwn0
192.168.1.68 link#2 UHl - - - lo0
192.168.1.254 00:1e:80:a2:2e:ff UHL - - - iwn0
A rota para **.191.33.**ainda existe ao parar o OpenVPN e destruir o túnel tun0, não sei se esse é o comportamento esperado.
Atualização Já verifiquei vários computadores e nenhum deles tem a rota 192.168.1/24, é apenas no PC rodando NetBSD, tentei excluí-lo, sem sucesso. Também li muitas páginas de manual e várias outras documentações, mas ainda não encontrei nada útil.
Configuração OpenVPN
client
dev tun
proto tcp
remote **.191.33.** 1701
resolv-retry infinite
nobind
# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup
persist-key
persist-tun
auth-user-pass
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
verb 3
auth SHA1
key-direction 1
reneg-sec 0
redirect-gateway def1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
Intenção
Estou tentando me conectar a uma VPN em um local remoto, de casa. A rede remota é protegida por um firewall voltado para a internet, todos os computadores da rede atrás do roteador estão acessíveis, a rede 192.168.7.* é padrão Ubuiquity e usada para clientes VPN, adicionei uma regra de firewall para permitir o tráfego de 192.168 .7.* para a rede 192.168.1.*, funciona bem em todos os computadores com os quais experimentei, Mac, PC, Windows, Linux, MacOS. etc. exceto um PC rodando NetBSD.
A configuração da rede no PC rodando NetBSD foi realizada durante a instalação e usei o recurso de configuração automática, portanto não especifiquei nenhuma rede, rota ou regra. Consigo acessar a internet ao usar o cliente OpenVPN, mas não consigo acessar nenhuma das máquinas da rede remota. Então acho que a parte que está faltando é o roteamento de 192.168.7.* para 192.168.1.* para poder acessar computadores conectados a essa rede
Embora eu não esteja familiarizado com o NetBSD, mas com base na tabela de rotas que você colou e na página de manual do
routecomando online do NetBSD, parece que o sistema operacional não suporta algo chamado métrica de rota, que é basicamente um número que indica uma rota precedência.No Linux moderno, e provavelmente também no Windows e no macOS, é possível ter rotas com o mesmo destino (observe que destino significa o intervalo/bloco de IP que é coberto pela rota, não o "nexthop" ou qualquer coisa equivalente) na mesma tabela de rotas. (E vamos chamar essa rota de "rotas duplicadas", mesmo quando elas não são realmente "duplicadas".) A rota com o menor valor de métrica (maior precedência) seria usada para tráfegos que possuem um destino coberto pelas rotas.
(Na verdade, pelo menos no Linux, IIRC , você não está proibido de ter "rotas duplicadas" que tenham os mesmos valores de métrica, incluindo, mas não se limitando ao valor mais baixo
0, o que pode ocultar o valor em pelo menos saídas de alguns comandos relacionados . Não sei qual comportamento/política exato isso resultaria.)Portanto, pelo que podemos dizer pelas saídas/logs que você colou, o NetBSD não permite rotas duplicadas e/ou métricas de rota. Como resultado, uma rota necessária para um site/host remoto, ou seja,
192.168.1.0/24(192.168.1/24é apenas outra forma de representação disso), que é a sub-rede IP usada na LAN local em que o host NetBSD está, não é adicionada, o que é por isso que você não consegue acessar192.168.1.114(o do lado remoto).Como solução alternativa, você pode adicionar rotas de substituição que não sejam "duplicadas". Por exemplo, se
192.168.1.114for o único192.168.1.0/24host que você precisa acessar:ou , se você quiser acessar o maior número
192.168.1.0/24possível de hosts no lado remoto:(que basicamente divide uma
192.168.1.0/24rota em duas metades, para que você possa ter uma "duplicação efetiva" de maior precedência. Se quiser entender a lógica de tal substituição, você precisará mergulhar nos conceitos de rede L3 como VLSM, comprimento do prefixo e e/ou como a decisão de roteamento é tomada em geral).Se quiser que esses comandos sejam automatizados pelo OpenVPN, você pode ter
routeopções equivalentes no arquivo conf/ovpn do seu cliente. (Estou com preguiça de fornecer a sintaxe exata aqui, mas você só precisa inserir os mesmos conjuntos de "números". Consulte o manual do OpenVPN para obter detalhes.)Com essa abordagem/solução alternativa, você NÃO precisa tentar se livrar da
192.168.1.0/24rota "original", pois ela ficaria efetivamente "inativa".(De modo geral, você precisa ter certeza de que uma rota específica para o gateway LAN foi adicionada antes de adotar a abordagem. No caso do DHCP, muitas vezes, como no seu caso, aparentemente , mas não necessariamente AFAIK, essa rota é anunciada pelo Servidor DHCP e/ou configurado pelo cliente DHCP, dado o fato de que é uma espécie de redundância para a rota de prefixo em uma configuração típica de rede.)
Observe que independente de como você faça isso, já que o destino (
192.168.1.0/24) ainda é um "conflito" entre sua LAN e o site remoto, portanto, se você optar por ter rota para/obter acesso ao site remoto, ou apenas um dos os hosts gostam192.168.1.114, você não pode acessar o (s) host (s) com o mesmo IP no lado local, não até que você remova a (s) rota (s) adicionada (s), apenas removendo-as ou destruindo a interface tun.No entanto, é mais ou menos impossível ter acesso a um host remoto que esteja atribuído ao IP do seu gateway LAN (nomeadamente
192.168.1.254no seu caso) ou ao IP deste próprio host cliente (ou seja192.168.1.68, que pode mudar para outro se estivermos falando sobre DHCP aqui).As
ERROR: OpenBSD/NetBSD route add command failedlinhas que você vê podem ser consideradas inofensivas. Como mencionei no comando, uma vez que/se esses erros não impedem o OpenVPN de estabelecer a conexão/configuração com sucesso, tudo que você precisa é "compensar" o que falhou/foi perdido, ou seja, no seu caso, adicionar rotas alternativas/substituíveis para192.168.1.0/24manualmente. (Embora eu não possa dizer com certeza se uma conexão "não livre de erros" é ou não a razão pela qual o OpenVPN não reverte suas operações quando a conexão está sendo interrompida.)(O de
**.191.33.**também é inofensivo porque é apenas uma consequência de uma rota duplicada "real" para o "endereço remoto" da VPN ser encontrada na tabela de rotas, devido ao fato de que o seu programa OpenVPN de alguma forma não reverte o que fez quando foi está parado. Tenho certeza que você não verá isso se, digamos, você estiver se conectando pela primeira vez após uma reinicialização E, obviamente, nada que você precise "compensar" aqui. sendo adicionado, verifique aredirect-gatewayopção no manual do OpenVPN. É basicamente por um motivo semelhante que mencionei acima para a rota do gateway LAN.)You only "need" a pull filter if what you are trying to accomplish is to prevent certain route being pushed by the server from stopping you from accessing hosts on the local side, or, more precisely, via your existing / physical interface. (Certainly that means you don't mind "losing" access to hosts on the remote side that are in the conflicting subnet.) But in your case, NetBSD more or less "did it for you" already, whether you want it or not.
I do think you want to find out why in your case OpenVPN does not revert its "manipulations" (including but not limited to adding the tun interface, i.e. removing it for reversion) when being stop, like whether you are / NetBSD is stopping it in a wrong way or so (e.g. SIGKILL?). I myself have no idea to contribute with that regard though.
Esta é agora uma reescrita com base em novas informações do OP postadas como comentários a esta resposta, atualizações da pergunta, informações apontadas por @TomYan, bem como minhas próprias investigações sobre o código-fonte do OpenVPN.
Como prefácio, deixe-me dizer que já se passaram muitos anos desde a última vez que usei o OpenVPN. No entanto, fundamentalmente, tudo o que o cliente OpenVPN está fazendo é autenticar a conexão e, em seguida, configurar um túnel local e rotas para passar o tráfego através desse túnel e, em seguida, passar pacotes de/para o terminal do usuário desse túnel por meio de uma conexão criptografada de/para o servidor OpenVPN remoto .
Também estou assumindo que o recurso de "configuração automática" que você usou durante a instalação do NetBSD é o mesmo que eu associaria a "usar DHCP para configurar a interface de rede", e que você o configurou para usar o mesmo roteador WiFi e Servidor DHCP como seus outros computadores locais estão usando.
Você afirma em um comentário abaixo:
De acordo com os logs, você mostra que está em conflito com as rotas de rede enviadas pelo servidor OpenVPN remoto.
Você não pode ter duas sub-redes IPv4 com prefixos idênticos em locais diferentes e esperar poder se comunicar entre elas.
Portanto, primeiro você deve reconfigurar seu roteador local para usar uma sub-rede diferente. Pode ser qualquer uma das redes privadas RFC 1918, exceto aquelas que são enviadas pelo seu servidor OpenVPN remoto. Eu evitaria qualquer coisa com o prefixo 192.168, já que parece ser o favorito do servidor OpenVPN remoto.
Observe que você não deve colocar seu roteador WiFi no modo bridge. Basta alterar o endereço da LAN e a sub-rede que ele fornece.
Lembre-se de reiniciar todos os seus computadores locais após fazer a alteração de sub-rede e testar se eles continuam funcionando (com e sem VPN) também.
Se você não pode alterar a sub-rede da sua rede WiFi local, então (se quiser usar esse servidor OpenVPN), você terá que colocar outro roteador (com NAT) e gateway WiFi na frente do existente e configurá-lo para que faça NAT para uma nova sub-rede exclusiva de sua escolha. Essa configuração não seria ideal e não seria confiável!
Em segundo lugar, a configuração do seu cliente OpenVPN local tem a seguinte linha:
A maneira atual como o cliente OpenVPN tenta implementar isso, conforme mostrado pelas entradas de log abaixo (e confirmado pela minha leitura do código), é provavelmente incompatível com o NetBSD ou qualquer outro sistema com código de rede BSD:
Essas entradas de rota (provavelmente) não terão o efeito desejado em nenhum sistema BSD (e se o fizerem é por acidente, não por projeto). O cliente OpenVPN ainda não foi portado corretamente para o BSD.
Portanto, também recomendo fortemente remover a
redirect-gateway def1linha da configuração do seu cliente OpenVPN e substituí-la por:Também como observação, eu diria que, na minha opinião, redirecionar todo o tráfego através da VPN raramente é a melhor maneira de configurar as coisas.
Finalmente, você diz que nenhum dos seus outros computadores tem uma rota para 192.168.1/24. Isso parece impossível e bastante confuso. Ou esses outros computadores não estão na mesma LAN que a máquina NetBSD, ou de alguma forma não estão usando o mesmo servidor DHCP nessa LAN e/ou não estão se conectando ao mesmo servidor OpenVPN. De uma forma ou de outra, todos eles deveriam ter uma rota 192.168.1/24, pelo menos quando seus clientes OpenVPN estiverem em execução e conectados.
Você tem certeza de que todos os seus computadores locais estão realmente conectados à mesma LAN através do mesmo roteador WiFi e servidor DHCP? Desative o OpenVPN em um deles e reinicie-o sem iniciar o cliente OpenVPN, e verifique novamente como sua interface de rede está configurada.