Quero configurar um servidor VPN para que a conexão VPN seja usada apenas ao acessar recursos dentro do servidor. Normalmente, eu faria isso usando o IP interno do servidor, mas quero usar o nome de domínio para acessar este servidor.
Existem algumas maneiras de conseguir isso:
Use um servidor DNS personalizado
Vincule outro IP a este servidor
Definido
Endpoint
como igualAllowedIPs
ao "cliente" (estou ciente de que o wg não usa arquitetura servidor-cliente, mas é mais fácil para mim entender dessa forma). Por exemplo:# client [Interface] PrivateKey = ... Address = 10.0.0.2/24 [Peer] PublicKey = ... AllowedIPs = 1.2.3.4/32 Endpoint = 1.2.3.4:51820
Resumindo, a opção 3 funciona melhor para o meu caso de uso, mas causaria um loop na tabela de roteamento. Depois de fazer algumas pesquisas (seção "Roteamento baseado em regras aprimorado" na página wireguard e nesta solução ), aprendi que usar FwMark
a configuração do "servidor" pode resolver o problema.
Então eu pensei nisso:
# server
[Interface]
PrivateKey = ...
ListenPort = 51820
Address = 10.0.0.1/24
FwMark = 51820
PostUp = ip route add default dev wg0 table 2468
PostUp = ip rule add not fwmark 51820 table 2468
PostDown = ip route del default dev wg0 table 2468
PostDown = ip rule del not fwmark 51820 table 2468
[Peer]
...
Escusado será dizer que isso não funciona (tanto a VPN quanto a comunicação direta expiram, então acho que errei a regra de roteamento). Minhas perguntas são:
- Por que isso não funciona?
- A configuração
FwMark = 51820
na configuração do "servidor" marca os pacotes roteados da VPN? Ou preciso de algo parecidoPostUp = wg set wg0 fwmark 51820
? - O que acontece se eu substituir
2468
pordefault
,main
ou mesmolocal
? Acho que não entendo por que o documento oficial teve que definir uma nova tabela para isso.
Obrigado
EDIT: Corrija erro de digitação na porta
Introdução
Existem dois comandos:
wg
o comando WireGuard ("WG") de baixo nível que afeta apenas astype wireguard
configurações de uma interface (incluindo a definição de uma marca para o tráfego de envelope de saída) ewg-quick
que, além disso, configurará endereços, rotas e, às vezes, regras de roteamento, roteamento adicional tabelas e até regras nftables para unir tudo isso.esta resposta explicará como fazer isso funcionar
FwMark = 51820
marca o envelope de saída (não a carga útil).O comando adequado
wg
será executado quando este parâmetro for definido.Table =
informawg-quick
onde adicionar rotas.Quando não fornecido, o padrão é
Table = auto
. Ele se comporta comoTable = main
a menos que haja tambémAllowedIPs = 0.0.0.0/0
(ouAllowedIPs = ::/0
para IPv6) que muda completamente o comportamento com tabela de roteamento adicional, regras de roteamento, marcas e regras nftables (ou iptables se o nftables não estiver instalado). Esse comportamento alterado é o que permite que a configuração VPN de tunelamento completo (em vez de VPN dividida) funcione corretamente. Dou um exemplo mais tarde.Se
Table = off
entãowg-quick
não tocar nas rotas. Tudo isso terá que ser tratado pelo administrador (e possivelmente comPreUp/PostUp
regras).Outros casos úteis são escolher uma tabela arbitrária que será reutilizada posteriormente com regras de roteamento personalizadas. Esta resposta será usada
Table = 2468
no cliente.wg-quick
adicionará rotas a esta tabela de roteamento em vez damain
tabela de roteamento. Uma outra opção poderia ter sido usarTable = off
e adicionar qualquer rota relevante comPostUp
entradas.A
local
tabela de roteamento deve ser deixada sozinha. Ele é preenchido pelo kernel e trata de rotas locais relacionadas a endereços atribuídos no sistema para tráfego de entrada destinado a este sistema, incluindo transmissões.a
default
tabela de roteamento quase nunca é usada e fica vazia em uma configuração padrão. Provavelmente é usado em alguns daemons de roteamento. Só faria sentido ter entradas nela se não houvesse nenhuma rota padrão namain
tabela de roteamento, caso contrário esta tabela de roteamento nunca teria a chance de ser alcançada com as regras de roteamento padrão em vigor (main
a rota padrão de uma vez encontrada interromperia o olho para cima).A configuração abaixo pressupõe que o cliente esteja rodando Linux, tenha nftables instalado e sua interface principal (que será nomeada
eth0
) ou na verdade todas as suas interfaces tenham Strict Reverse Path Forwarding ("SRPF") habilitada (sysctlnet.conf.ipv4.all.rp_filter=1
). As regras nftables abaixo, inclusive nos casos de canto para o parágrafo do cliente, são usadas apenas para que o tráfego de entrada do envelope seja marcado adequadamente para ser visto como usando a rota correta e ter sucesso na verificação SRPF. Se nenhuma configuração estiver habilitada ou pelo menos a interface principal (eth0
) definida como Loose RPF (net.conf.ipv4.eth0.rp_filter=2
), todas as partes do nftables poderão ser ignoradas. Então não importa mais seos pacotes recebidos usaram o caminho errado: eles foram recebidos e serão usados pela pilha de roteamento em vez de serem descartados. Qualquer parte abaixo que lide com nftables assumirá que isso está em vigor no cliente:Há um caso já tratado
wg-quick
que também explicarp_filter=1
onde o endereço de carga deve ser diferenciado do endereço do envelope, que é um endereço remoto usando a rota padrão: ao usar a configuração padrãoTable = auto
eAllowedIPs = 0.0.0.0/0
, que é comum em uma implantação de cliente. Em seguida,wg-quick
usa uma marca de firewall e regras nftables adicionais para este caso. Apareceria assim:A marca de firewall definida pelo WG para o tráfego de saída permite distinguir o tráfego de envelope (de saída) do tráfego de carga útil (de saída) nas regras de roteamento.
A parte nftables é para lidar com o tráfego de resposta/entrada do envelope:
cronologicamente em primeiro lugar, ele atualiza no gancho pós-routing o fluxo conntrack para a marca definida pelo WG para tráfego de envelope de saída .
então, no gancho de pré-roteamento , esta marca é recuperada da entrada de fluxo salva do conntrack para marcar o tráfego de envelope de resposta de entrada
o gancho de pré-roteamento inicial (
preraw
) serve para evitar o recebimento de tráfego não-WG para o endereço definido na interface WG (não para roteamento, mas para segurança, não será retido abaixo)Essas regras nftables permitem, no final, que o tráfego de envelope de entrada seja visto como tráfego de envelope nas regras de roteamento. Ao longo de
src_valid_mark=1
todo esse esforço está para que o tráfego não falhe no SRPF.Como
wg-quick
o código bash de o aciona apenas paraTable = auto
+AllowedIPs = 0.0.0.0/0
, isso terá que ser adaptado e feito manualmente no cliente (e essas também são as regras de filtragem que fazem parte da*
observação no final da resposta de perguntas e respostas vinculadas do OP : a menos que você configure alguns regras sofisticadas de roteamento/filtragem de pacotes em seu cliente em vez de usar os padrões que o cliente WireGuard configura para você ).Configurações no cliente e no servidor
cliente
/etc/wireguard/wg0.nft
que será carregado dewg0.conf
:do cliente
/etc/wireguard/wg0.conf
(referenciando o arquivo anterior):Supondo que abaixo o endereço IP atual do cliente em sua interface principal
eth0
seja (NAT-ed...) 192.168.1.2/24 com um gateway 192.168.1.1, aqui está o que seria o resultado de várias decisões de roteamento:A configuração do servidor é muito mais simples porque seu próprio endpoint é uma configuração conhecida e o endereço de carga útil do cliente dentro do WG é um endereço não roteável pela Internet e não entra em conflito com o endereço do envelope do cliente. Nenhum nftables envolvido no servidor.
do servidor
/etc/wireguard/wg0.conf
:Se a interface principal deste servidor
eth0
tiver o endereço 1.2.3.4/24 e um gateway de 1.2.3.1/24 com um peer (cliente) WG remoto descoberto como 192.0.2.2:45678 quando atingiu o servidor, os vários casos de roteamento, todos simples, são:Nenhum endereço foi adicionado
wg0
para evitar a complicação usual de multi-homed UDP. Se este endereço tivesse sido adicionado, o endereço de origem para alcançar 10.0.0.2 teria sido escolhido como 10.0.0.1, desencadeando assim problemas para serviços UDP multi-homed inconscientes que respondem através do túnel: as respostas UDP às consultas feitas a 1.2.3.4 usariam 10.0.0.1 como fonte que seria rejeitada pela aplicação cliente (e mesmo antes disso, descartada por sua interface WG já que 10.0.0.1 não é permitido). Detalhes adicionais nestas perguntas/respostas onde respondi:A melhor maneira de nunca encontrar um problema de multi-homed UDP é não estar no caso multi-homed e não adicionar um endereço IP em
wg0
. O algoritmo de seleção de endereço de origem selecionará o endereço IP "principal" quando não puder selecionar um endereço dewg0
. Caso o servidor já seja multi-homed e de alguma forma o endereço de origem errado tenha sido selecionado, então é possível corrigir a rota adicionada comwg-quick
esta entrada adicional no servidorwg0.conf
:que irá sugerir ao algoritmo de seleção de endereço para usar 1.2.3.4 como fonte para chegar a 10.0.0.2. Isso também pode permitir ativar 10.0.0.1
wg0
mesmo que não seja usado e alterar esse tipo de rota para todo o /24, no caso de vários pares, por exemplo, com este em vez do acima:Esta mudança de rota não sobreviverá ou seguirá algo que afete o 1.2.3.4 real (por exemplo: interface principal configurada administrativamente e depois ativada). Na verdade, basta adicionar "novamente" 1.2.3.4 em
wg0
. Por exemplo, em vez do acima (certifique-se de que seja /32 para que não acione a criação de rotas adicionais que causem interrupção na rede):Isto é para o servidor como um nó final. Se ele estiver atuando como roteador e roteamento de tráfego (por exemplo: contêineres ou VMs) em vez de gerá-lo sozinho, não haverá problema de multi-homed UDP, mas é provável que as configurações para lidar com esse caso de roteador estejam faltando de qualquer maneira.
Casos de canto para o cliente
Se não estiver usando SRPF (
rp_filter=1
) no cliente, assim como todas as outras configurações do nftables , não será necessário aplicar as correções abaixo.Existem casos extremos no cliente ao ignorar o WG para chegar ao servidor com um aplicativo adequado capaz de usar
setsockopt(sockfd, SOL_SOCKET, SO_MARK, ...)
traceroute (--udp)
Precisa rastrear a rota em direção ao servidor através da Internet real para descobrir qual interrupção da rede está acontecendo?
Isso ainda atingirá o tempo limite antes de exibir o destino porque o tráfego de retorno esperado não é UDP, mas um erro ICMP relacionado: nenhuma marca definida e rejeitada pelo SRPF. Pode ser corrigido adicionando uma regra marcando o tráfego relacionado :
ping, outros traceroutes, socat com TCP...
Também marque e recupere sistematicamente a marca do fluxo conntrack, não apenas para UDP:
Isso faz com que os 3 comandos acima funcionem em vez de ter um tempo limite.