wireguard docs
1.0.0
Guia de referência de API para WireGuard incluindo instalação, configuração e uso, com exemplos.
Todo o crédito vai para o projeto WireGuard, zx2c4 e os contribuidores de código aberto do software original,
esta é minha tentativa não oficial de fornecer documentação, referências de API e exemplos mais abrangentes.
Fonte desses documentos, código de exemplo e rastreador de problemas: https://github.com/pirate/wireguard-docs Versão da página HTML mais agradável: https://docs.sweeting.me/s/wireguard
WireGuard é uma solução VPN de código aberto escrita em C por Jason Donenfeld e outros, com o objetivo de corrigir muitos dos problemas que têm atormentado outras ofertas modernas de VPN servidor a servidor, como IPSec/IKEv2, OpenVPN ou L2TP. Ele compartilha algumas semelhanças com outras ofertas de VPN modernas, como Tinc e MeshBird, ou seja, bons conjuntos de criptografia e configuração mínima. A partir de 2020-01, ele foi incorporado à versão 5.6 do kernel Linux, o que significa que será fornecido com a maioria dos sistemas Linux prontos para uso.
Links Oficiais
wg , wg-quickMetas do WireGuard
Consulte https://github.com/pirate/wireguard-docs para obter exemplo de código e fonte de documentação.
Seja morando atrás da Grande Muralha da China ou apenas tentando formar uma rede entre seus servidores, o WireGuard é uma ótima opção e serve como um “bloco de lego” para construção de redes (da mesma forma que o ZFS é um bloco de lego para construção de sistemas de arquivos ).
Coisas que o WireGuard não faz:
Mas você pode escrever suas próprias soluções para esses problemas usando o WireGuard nos bastidores (como Tailscale ou AltheaNet).
Estes são nomes de host de demonstração, nomes de domínio, endereços IP e intervalos usados na documentação e configurações de exemplo. Substitua-os pelos seus valores preferidos ao fazer sua própria configuração.
example-vpn.dev pode ser substituído por qualquer domínio acessível publicamente que você controlepublic-server1 , public-server2 , home-server , laptop , phone podem ser alterados para os nomes de host do seu dispositivo192.0.2.1/24 , 192.0.2.3 , 192.0.2.3/32 , 2001:DB8::/64 podem ser substituídos por suas sub-redes e endereços preferidos (por exemplo, 192.168.5.1/24 )Onde quer que você veja essas strings abaixo, elas estão sendo usadas apenas como valores de espaço reservado para ilustrar um exemplo e não têm nenhum significado especial.
Certifique-se de alterar os endereços IP em suas configurações! Os blocos usados nestes documentos são reservados para fins de exemplo pela IETF e nunca devem ser usados em configurações de rede reais.
192.0.2.0/24 (TEST-NET-1) intervalo de exemplo IPv4 RFC57372001:DB8::/32 intervalo de exemplo IPv6 RFC3849 Você pode usar qualquer intervalo privado que desejar para suas próprias configurações, por exemplo, 10.0.44.0/24 , apenas certifique-se de que eles não entrem em conflito com nenhum dos intervalos de sub-rede da LAN em que seus pares estão.
Um host que se conecta à VPN e registra um endereço de sub-rede VPN, como 192.0.2.3 para si mesmo. Opcionalmente, ele também pode rotear o tráfego para mais do que seu(s) próprio(s) endereço(s), especificando intervalos de sub-rede em notação CIDR separados por vírgula.
Um peer/nó acessível publicamente que serve como substituto para retransmitir o tráfego para outros peers VPN por trás de NATs. Um servidor de rejeição não é um tipo especial de servidor, é um peer normal como todos os outros, a única diferença é que ele tem um IP público e tem o encaminhamento de IP em nível de kernel ativado, o que permite devolver o tráfego de volta para a VPN para outros clientes.
Veja mais: https://tailscale.com/blog/how-nat-traversal-works/ (Tailscale usa Wireguard nos bastidores)
Um grupo de IPs separados da Internet pública, por exemplo, 192.0.2.1-255 ou 192.168.1.1/24. Geralmente atrás de um NAT fornecido por um roteador, por exemplo, na LAN de Internet do escritório ou em uma rede Wi-Fi doméstica.
Uma forma de definir uma sub-rede e seu tamanho com uma "máscara", uma máscara menor = mais bits de endereço utilizáveis pela sub-rede e mais IPs no intervalo. Mais comuns:
192.0.2.1/32 (um único endereço IP, 192.0.2.1 ) máscara de rede = 255.255.255.255192.0.2.1/24 (255 IPs de 192.0.2.0 - 192.0.2.255 ) máscara de rede = 255.255.255.0192.0.2.1/16 (65.536 IPs de 192.0.0.0 - 192.0.255.255 ) máscara de rede = 255.255.0.0192.0.2.1/8 (16.777.216 IPs de 192.0.0.0 - 192.255.255.255 ) máscara de rede = 255.0.0.00.0.0.1/0 (4.294.967.296 IPs de 0.0.0.0 - 255.255.255.255 ) máscara de rede = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Para quem está começando, 192.0.2.1/32 pode parecer uma maneira estranha e confusa de se referir a um único IP. Esse design é bom porque permite que os pares exponham vários IPs, se necessário, sem a necessidade de várias notações. Saiba que em qualquer lugar que você vir algo como 192.0.2.3/32 , na verdade significa apenas 192.0.2.3 .
Uma sub-rede com IPs privados fornecidos por um roteador na frente deles fazendo tradução de endereços de rede, nós individuais não são acessíveis publicamente pela Internet; em vez disso, o roteador rastreia as conexões de saída e encaminha as respostas para o IP interno correto (por exemplo, redes de escritório padrão , redes Wi-Fi domésticas, redes Wi-Fi públicas gratuitas, etc.)
O endereço:porta acessível publicamente para um nó, por exemplo, 123.124.125.126:1234 ou some.domain.tld:1234 (deve ser acessível através da Internet pública, geralmente não pode ser um IP privado como 192.0.2.1 ou 192.168.1.1 a menos que é diretamente acessível usando esse endereço por outros pares na mesma sub-rede).
Uma chave privada WireGuard para um único nó, gerada com: wg genkey > example.key (nunca sai do nó em que foi gerada)
Uma chave pública WireGuard para um único nó, gerada com: wg pubkey < example.key > example.key.pub (compartilhada com outros pares)
Servidor de nomes de domínio, usado para resolver nomes de host para IPs para clientes VPN, em vez de permitir que solicitações de DNS vazem para fora da VPN e revelem tráfego. Os vazamentos podem ser testados em http://dnsleak.com.
Os retransmissores públicos são apenas peers VPN normais que são capazes de atuar como um servidor de retransmissão intermediário entre qualquer cliente VPN atrás de NATs, eles podem encaminhar qualquer tráfego de sub-rede VPN que receberem para o peer correto no nível do sistema (o WireGuard não se importa como isso acontece , é tratado pelo kernel net.ipv4.ip_forward = 1 e pelas regras de roteamento iptables).
Se todos os peers estiverem acessíveis publicamente, você não precisa se preocupar com tratamento especial para tornar um deles um servidor de retransmissão; ele só será necessário se você tiver algum peer conectado por trás de um NAT.
Cada cliente só precisa definir os servidores/peers acessíveis publicamente em sua configuração, qualquer tráfego vinculado a outros peers atrás de NATs irá para a sub-rede VPN catchall (por exemplo, 192.0.2.1/24 ) na rota de retransmissões públicas AllowedIPs e será encaminhado de acordo assim que atingir o servidor de retransmissão.
Em resumo: apenas conexões diretas entre clientes devem ser configuradas, quaisquer conexões que precisem ser devolvidas não devem ser definidas como pares, pois devem primeiro ir para o servidor de rejeição e ser roteadas de lá de volta pela VPN para o cliente correto.
Topologias mais complexas são definitivamente possíveis, mas estes são os métodos básicos de roteamento usados em configurações típicas do WireGuard:
Endpoint codificados para que o WireGuard possa se conectar diretamente à porta aberta e rotear pacotes UDP sem saltos intermediários.public-server2 ), defina o nó acessível publicamente com um Endpoint codificado e o nó com NAT sem. A conexão será aberta do cliente NAT -> cliente público, então o tráfego será roteado diretamente entre eles em ambas as direções, desde que a conexão seja mantida ativa por pings PersistentKeepalive de saída do cliente NAT-ed.public-server1 e o tráfego será encaminhado através do servidor de rejeição intermediário, desde que as conexões são mantidos vivos. Rotas mais específicas (também geralmente mais diretas) fornecidas por outros pares terão precedência quando disponíveis, caso contrário, o tráfego retornará para a rota menos específica e usará o catchall 192.0.2.1/24 para encaminhar o tráfego para o servidor de rejeição, onde será por sua vez, será roteado pela tabela de roteamento do sistema do servidor de retransmissão ( net.ipv4.ip_forward = 1 ) de volta à VPN para o peer específico que está aceitando rotas para esse tráfego. O WireGuard não encontra automaticamente a rota mais rápida nem tenta formar conexões diretas entre pares se ainda não estiver definida, apenas vai da rota mais específica em [Peers] para a menos específica.
Você pode descobrir qual método de roteamento o WireGuard está usando para um determinado endereço medindo os tempos de ping para descobrir o comprimento exclusivo de cada salto e inspecionando a saída de:
wg show wg0O WireGuard usa pacotes UDP criptografados para todo o tráfego, não fornece garantias sobre a entrega ou pedido de pacotes, pois isso é tratado por conexões TCP dentro do túnel criptografado.
Leitura adicional:
O WireGuard afirma ter desempenho mais rápido do que a maioria das outras soluções VPN concorrentes, embora os números exatos às vezes sejam debatidos e possam depender se a aceleração em nível de hardware está disponível para determinadas cifras criptográficas.
Os ganhos de desempenho do WireGuard são alcançados ao lidar com o roteamento no nível do kernel e ao usar conjuntos de criptografia modernos executados em todos os núcleos para criptografar o tráfego. O WireGuard também ganha uma vantagem significativa ao usar UDP sem garantias de entrega/pedido (em comparação com VPNs que rodam sobre TCP ou implementam seus próprios mecanismos de entrega garantida).
Leitura adicional:
WireGuard usa os seguintes protocolos e primitivos para proteger o tráfego:
A criptografia do WireGuard é essencialmente uma instanciação da estrutura Noise de Trevor Perrin. É moderno e, novamente, simples. Todas as outras opções de VPN são uma confusão de negociações, apertos de mão e máquinas de estado complicadas. WireGuard é como o Signal/Axolotl das VPNs, exceto que é muito mais simples e fácil de raciocinar (criptograficamente, neste caso) do que protocolos de mensagens de catraca dupla. É basicamente o qmail do software VPN. E são cerca de 4.000 linhas de código. É várias ordens de magnitude menor que seus concorrentes.
https://news.ycombinator.com/item?id=14599834
Leitura adicional:
A autenticação em ambas as direções é obtida com um simples par de chaves pública/privada para cada ponto. Cada peer gera essas chaves durante a fase de configuração e compartilha apenas a chave pública com outros peers.
Nenhum outro certificado ou chave pré-compartilhada é necessário além das chaves públicas/privadas de cada nó.
A geração, distribuição e revogação de chaves podem ser tratadas em implantações maiores usando um serviço separado, como Ansible ou Kubernetes Secrets.
Alguns serviços que ajudam na distribuição e implantação de chaves:
Você também pode ler as chaves de um arquivo ou por meio de comando se não quiser codificá-las em wg0.conf , isso torna o gerenciamento de chaves por meio de serviços de terceiros muito mais fácil:
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)Tecnicamente, vários servidores podem compartilhar a mesma chave privada, desde que os clientes não estejam conectados a dois servidores com a mesma chave simultaneamente. Um exemplo de cenário em que essa configuração é razoável é se você estiver usando DNS round-robin para balancear a carga de conexões entre dois servidores que fingem ser um único servidor. Na maioria das vezes, entretanto, cada peer deve ter seu próprio par de chaves pública/privada para que os peers não possam ler o tráfego um do outro e possam ser revogados individualmente.
Visão geral do processo geral:
apt install wireguard ou pkg/brew install wireguard-tools em cada nówg genkey + wg pubkeywg0.conf WireGuard no servidor de retransmissão principal[Interface] Certifique-se de especificar um intervalo CIDR para toda a sub-rede VPN ao definir o endereço para o qual o servidor aceita rotas. Address = 192.0.2.1/24[Peer] Crie uma seção peer para cada cliente que ingressar na VPN, usando suas chaves públicas remotas correspondenteswg0.conf em cada nó cliente[Interface] Certifique-se de especificar apenas um único IP para pares de clientes que não retransmitem tráfego Address = 192.0.2.3/32 .[Peer] Crie uma seção de peer para cada peer público que não esteja atrás de um NAT, certifique-se de especificar um intervalo CIDR para toda a sub-rede VPN ao definir o peer remoto que atua como o servidor de rejeição AllowedIPs = 192.0.2.1/24 . Certifique-se de especificar IPs individuais para pares remotos que não retransmitem tráfego e atuam apenas como clientes simples AllowedIPs = 192.0.2.3/32 .wg-quick up /full/path/to/wg0.confwg-quick up /full/path/to/wg0.confping 192.0.2.3 verifica primeiro uma rota direta para um ponto com AllowedIPs = 192.0.2.3/32 e depois retorna para um servidor de retransmissão que está aceitando IPs em toda a sub-rede # install on Ubuntu
sudo add-apt-repository ppa:wireguard/wireguard
apt install wireguard
# install on macOS
brew install wireguard-tools
# install on FreeBSD
pkg install wireguard
# install on iOS/Android using Apple App Store/Google Play Store
# install on other systems using https://www.wireguard.com/install/#installation # to enable the kernel relaying/forwarding ability on bounce servers
echo " net.ipv4.ip_forward = 1 " | sudo tee -a /etc/sysctl.conf
echo " net.ipv4.conf.all.proxy_arp = 1 " | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
# to add iptables forwarding rules on bounce servers
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADEnano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems) # generate private key
wg genkey > example.key
# generate public key
wg pubkey < example.key > example.key.pubwg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Note: you must specify the absolute path to wg0.conf, relative paths won't work
# If wg0.conf is in /etc/wireguard you can use the simpler:
wg-quick up wg0 # start/stop VPN network interface
ip link set wg0 up
ip link set wg0 down
# register/unregister VPN network interface
ip link add dev wg0 type wireguard
ip link delete dev wg0
# register/unregister local VPN address
ip address add dev wg0 192.0.2.3/32
ip address delete dev wg0 192.0.2.3/32
# register/unregister VPN route
ip route add 192.0.2.3/32 dev wg0
ip route delete 192.0.2.3/32 dev wg0 # show system LAN and WAN network interfaces
ip address show
# or if ip is not available:
ifconfig
# show system VPN network interfaces
ip link show wg0
# or
ifconfig wg0
# show WireGuard VPN interfaces
wg show all
wg show wg0 # show public IP address
ip address show eth0
# or
ifconfig eth0
# or
dig -4 +short myip.opendns.com @resolver1.opendns.com
# show VPN IP address
ip address show wg0 # show WireGuard routing table and peer connections
wg show
wg show wg0 allowed-ips
# show system routing table
ip route show table main
ip route show table local
# show system route to specific address
ip route get 192.0.2.3Para ativar o registro adicional, execute:
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/controlPara seguir os registros:
dmesg -wHSistemas com kernel moderno e inicialização segura podem exigir a desativação da verificação de assinatura DKMS de inicialização segura para permitir acesso aos logs do kernel.
mokutil --disable-verification
reboot # check that the main relay server is accessible directly via public internet
ping public-server1.example-vpn.dev
# check that the main relay server is available via VPN
ping 192.0.2.1
# check that public peers are available via VPN
ping 192.0.2.2
# check that remote NAT-ed peers are available via VPN
ping 192.0.2.3
# check that NAT-ed peers in your local LAN are available via VPN
ping 192.0.2.4 # install iperf using your preferred package manager
apt/brew/pkg/opkg install iperf
# check bandwidth over public internet to relay server
iperf -s # on public relay server
iperf -c public-server1.example-vpn.dev # on local client
# check bandwidth over VPN to relay server
iperf -s # on public relay server
iperf -c 192.0.2.1 # on local client
# check bandwidth over VPN to remote public peer
iperf -s # on remote public peer
iperf -c 192.0.2.2 # on local client
# check bandwidth over VPN to remote NAT-ed peer
iperf -s # on remote NAT-ed peer
iperf -c 192.0.2.3 # on local client
# check bandwidth over VPN to local NAT-ed peer (on same LAN)
iperf -s # on local NAT-ed peer
iperf -c 192.0.2.4 # on local client Verifique se há vazamentos de DNS usando http://dnsleak.com ou verificando o resolvedor em uma pesquisa:
dig example.com A A configuração do WireGuard está na sintaxe INI, definida em um arquivo geralmente chamado wg0.conf . Ele pode ser colocado em qualquer lugar do sistema, mas geralmente é colocado em /etc/wireguard/wg0.conf .
O caminho de configuração é especificado como argumento ao executar qualquer comando wg-quick , por exemplo:
wg-quick up /etc/wireguard/wg0.conf (sempre especifique o caminho completo e absoluto)
O nome do arquivo de configuração deve estar no formato ${name of the new WireGuard interface}.conf . Os nomes de interface do WireGuard normalmente são prefixados com wg e numerados começando em 0 , mas você pode usar qualquer nome que corresponda à regex ^[a-zA-Z0-9_=+.-]{1,15}$ .
Os arquivos de configuração podem optar por usar o conjunto limitado de opções de configuração wg ou as opções wg-quick mais estendidas, dependendo de qual comando é preferido para iniciar o WireGuard. Esses documentos recomendam aderir ao wg-quick , pois fornece uma experiência de configuração mais poderosa e fácil de usar.
Vá para a definição:
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶ ListenPort = 51820
¶ PrivateKey = localPrivateKeyAbcAbcAbc=
¶ DNS = 1.1.1.1,8.8.8.8
¶ Table = 12345
¶ MTU = 1500
¶ PreUp = /bin/example arg1 arg2 %i
¶ PostUp = /bin/example arg1 arg2 %i
¶ PreDown = /bin/example arg1 arg2 %i
¶ PostDown = /bin/example arg1 arg2 %i
¶ [Peer]
¶ # Name = node2-node.example.tld
¶ AllowedIPs = 192.0.2.1/24
¶ Endpoint = node1.example.tld:51820
¶ PublicKey = remotePublicKeyAbcAbcAbc=
¶ PersistentKeepalive = 25
[Interface]Define as configurações de VPN para o nó local.
Exemplos
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev> [Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1# NameEste é apenas um comentário padrão na sintaxe INI usado para ajudar a controlar qual seção de configuração pertence a qual nó, é completamente ignorado pelo WireGuard e não tem efeito no comportamento da VPN.
NOTA: Todos os comentários, incluindo # Name , são removidos dos arquivos .conf por determinadas operações e aplicativos. Se você precisar identificar pares, considere usar um gerador de chaves personalizadas wireguard, como wireguard-vanity-keygen ou wireguard-vanity-address, que permitirá incluir o nome do host na chave pública do host. A geração da chave pode levar minutos (4 caracteres), horas (5 caracteres) ou mais, portanto considere usar uma abreviatura para hosts com nomes mais longos.
AddressDefine para qual intervalo de endereços o nó local deve rotear o tráfego. Dependendo se o nó é um simples cliente ingressando na sub-rede VPN ou um servidor de rejeição que retransmite o tráfego entre vários clientes, isso pode ser definido como um único IP do próprio nó (especificado com notação CIDR), por exemplo, 192.0.2.3/32 ) ou um intervalo de sub-redes IPv4/IPv6 para as quais o nó pode rotear o tráfego.
Exemplos
Node é um cliente que apenas roteia o tráfego para si mesmo
Address = 192.0.2.3/32
Node é um servidor de rejeição público que pode retransmitir tráfego para outros pares
Quando o nó está atuando como servidor de rejeição público, ele deve definir esta como toda a sub-rede que pode rotear o tráfego, e não apenas um único IP para si mesmo.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPortQuando o nó estiver atuando como um servidor de rejeição público, ele deverá codificar uma porta para escutar conexões VPN de entrada da Internet pública. Os clientes que não atuam como retransmissores não devem definir esse valor.
Exemplos
ListenPort = 51820ListenPort = 7000PrivateKeyEsta é a chave privada do nó local, nunca compartilhada com outros servidores. Todos os nós devem ter uma chave privada definida, independentemente de serem servidores públicos de retransmissão de tráfego ou simples clientes ingressando na VPN.
Esta chave pode ser gerada com wg genkey > example.key
Exemplos
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSO(s) servidor(es) DNS serão anunciados aos clientes VPN via DHCP. A maioria dos clientes usará esse servidor para solicitações DNS pela VPN, mas os clientes também podem substituir esse valor localmente em seus nós.
Exemplos
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8TableOpcionalmente, define qual tabela de roteamento usar para as rotas WireGuard, não é necessário configurar para a maioria das configurações.
Existem dois valores especiais: 'off' desativa totalmente a criação de rotas e 'auto' (o padrão) adiciona rotas à tabela padrão e permite o tratamento especial de rotas padrão.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Exemplos
Table = 1234MTUOpcionalmente, define a unidade máxima de transmissão (MTU, também conhecida como tamanho do pacote/quadro) a ser usada ao conectar-se ao par, não é necessário configurar para a maioria das configurações.
O MTU é determinado automaticamente a partir dos endereços dos terminais ou da rota padrão do sistema, o que geralmente é uma escolha sensata.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Exemplos
MTU = 1500PreUpOpcionalmente, execute um comando antes que a interface seja ativada. Esta opção pode ser especificada várias vezes, com comandos executados na ordem em que aparecem no arquivo.
Exemplos
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUpOpcionalmente, execute um comando depois que a interface for ativada. Esta opção pode aparecer várias vezes, como acontece com PreUp
Exemplos
Ler um valor de configuração de um arquivo ou saída de algum comando
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
Registrar uma linha em um arquivo
PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
Acesse um webhook em outro servidor
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
Adicione uma rota à tabela de roteamento do sistema
PostUp = ip rule add ipproto tcp dport 22 table 1234
Adicione uma regra iptables para habilitar o encaminhamento de pacotes na interface WireGuard
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Forçar o WireGuard a resolver novamente o endereço IP para o domínio peer
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDownOpcionalmente, execute um comando antes que a interface seja desativada. Esta opção pode aparecer várias vezes, como acontece com PreUp
Exemplos
Registrar uma linha em um arquivo
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
Acesse um webhook em outro servidor
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDownOpcionalmente, execute um comando depois que a interface for desativada. Esta opção pode aparecer várias vezes, como acontece com PreUp
Exemplos
Registrar uma linha em um arquivo
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
Acesse um webhook em outro servidor
PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
Remova a regra iptables que encaminha pacotes na interface WireGuard
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]Define as configurações de VPN para um peer remoto capaz de rotear o tráfego para um ou mais endereços (ele mesmo e/ou outros peers). Os pares podem ser um servidor de rejeição público que retransmite o tráfego para outros pares ou um cliente acessível diretamente via LAN/internet que não está atrás de um NAT e apenas roteia o tráfego para si mesmo.
Todos os clientes devem ser definidos como pares no servidor de devolução público. Clientes simples que roteiam o tráfego apenas para si próprios, precisam apenas definir pares para o retransmissor público e quaisquer outros nós diretamente acessíveis. Os nós que estão atrás de NATs separados não devem ser definidos como pares fora da configuração do servidor público, pois nenhuma rota direta está disponível entre NATs separados. Em vez disso, os nós por trás dos NATs devem definir apenas os servidores de retransmissão públicos e outros clientes públicos como seus pares e devem especificar AllowedIPs = 192.0.2.1/24 no servidor público que aceita rotas e devolve o tráfego da sub-rede VPN para o NAT remoto. pares.
Em resumo, todos os nós devem ser definidos no servidor de rejeição principal. Em servidores clientes, apenas os pares que são diretamente acessíveis a partir de um nó devem ser definidos como pares desse nó; quaisquer pares que devam ser retransmitidos por um servidor de rejeição devem ser deixados de fora e serão tratados pela rota catchall do servidor de retransmissão.
Na configuração descrita nos documentos abaixo, um único servidor public-server1 atua como o servidor de retransmissão de rejeição para uma combinação de clientes publicamente acessíveis e com NAT, e os pares são configurados em cada nó de acordo:
em public-server1 wg0.conf (servidor de rejeição)
lista [peer] : public-server2 , home-server , laptop , phone
em public-server2 wg0.conf (cliente público simples)
lista [peer] : public-server1
no home-server wg0.conf (cliente simples atrás de NAT)
lista [peer] : public-server1 , public-server2
no laptop wg0.conf (cliente simples atrás de NAT)
lista [peer] : public-server1 , public-server2
no phone wg0.conf (cliente simples atrás de NAT)
lista [peer] : public-server1 , public-server2
Exemplos
[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32 [Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32 [Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# routes traffic to itself and entire subnet of peers as bounce server
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25# NameEste é apenas um comentário padrão na sintaxe INI usado para ajudar a controlar qual seção de configuração pertence a qual nó, é completamente ignorado pelo WireGuard e não tem efeito no comportamento da VPN.
Endpoint Define o endereço publicamente acessível para um ponto remoto. Isso deve ser deixado de fora para pares atrás de um NAT ou pares que não possuem um par IP:PORT estável publicamente acessível. Normalmente, isso só precisa ser definido no servidor de rejeição principal, mas também pode ser definido em outros nós públicos com IPs estáveis, como public-server2 no exemplo de configuração abaixo.
Exemplos
Endpoint = 123.124.125.126:51820 (IPv6 também é compatível)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs Isso define os intervalos de IP para os quais um peer roteará o tráfego. Em clientes simples, geralmente é um endereço único (o endereço VPN do próprio cliente simples). Para servidores de rejeição, este será um intervalo de IPs ou sub-redes para os quais o servidor de retransmissão é capaz de rotear o tráfego. Vários IPs e sub-redes podem ser especificados usando a notação CIDR IPv4 ou IPv6 separada por vírgula (de um único endereço /32 ou /128, até 0.0.0.0/0 e ::/0 para indicar uma rota padrão para enviar todos tráfego de Internet e VPN através desse ponto). Esta opção pode ser especificada várias vezes.
Ao decidir como rotear um pacote, o sistema escolhe primeiro a rota mais específica e recorre a rotas mais amplas. Portanto, para um pacote destinado a 192.0.2.3 , o sistema procuraria primeiro uma publicidade de pares 192.0.2.3/32 especificamente e voltaria para uma publicidade de pares 192.0.2.1/24 ou um intervalo maior como 0.0.0.0/0 como um último recurso.
Exemplos
peer é um cliente simples que só aceita tráfego de/para si mesmo
AllowedIPs = 192.0.2.3/32
peer é um servidor de retransmissão que pode devolver o tráfego VPN para todos os outros peers
AllowedIPs = 192.0.2.1/24
peer é um servidor de retransmissão que desvia todo o tráfego de Internet e VPN (como um proxy), incluindo IPv6
AllowedIPs = 0.0.0.0/0,::/0
peer é um servidor de retransmissão que roteia para si mesmo e apenas para outro peer
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
peer é um servidor de retransmissão que roteia para si mesmo e para todos os nós em sua LAN local
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKeyEsta é a chave pública do nó remoto, compartilhável com todos os pares. Todos os nós devem ter uma chave pública definida, independentemente de serem servidores públicos de retransmissão de tráfego ou simples clientes ingressando na VPN.
Esta chave pode ser gerada com wg pubkey < example.key > example.key.pub . (veja acima como gerar a chave privada example.key )
Exemplos
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepaliveSe a conexão estiver indo de um peer com NAT para um peer público, o nó por trás do NAT deverá enviar regularmente um ping de saída para manter a conexão bidirecional ativa na tabela de conexões do roteador NAT.
Exemplos
nó público local para nó público remoto
Este valor deve ser deixado indefinido, pois não são necessários pings persistentes.
nó público local para nó remoto com NAT
Este valor deve ser deixado indefinido, pois é responsabilidade do cliente manter a conexão ativa porque o servidor não pode reabrir uma conexão inoperante com o cliente se ela atingir o tempo limite.
nó NAT local para nó público remoto
PersistentKeepalive = 25 enviará um ping a cada 25 segundos mantendo a conexão aberta na tabela de conexão do roteador NAT local.
Os exemplos nesses documentos usam principalmente o IPv4, mas o Wireguard suporta nativamente a notação IPv6 CIDR e os endereços em todos os lugares que ele suporta IPv4, basta adicioná -los como você faria com qualquer outro alcance ou endereço de sub -rede.
Exemplo
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 Se você deseja encaminhar todo o tráfego da Internet através da VPN, e não apenas usá-lo como uma sub-rede servidor para servidor, você pode adicionar 0.0.0.0/0, ::/0 à definição AllowedIPs do par que você deseja tubar seu tráfego.
Certifique -se de especificar também um IPv6 Catchall, mesmo ao encaminhar apenas o tráfego IPv4 para evitar vazamentos de pacotes IPv6 fora da VPN, consulte:
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to/
Exemplo
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>
[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0Às vezes, o Wireguard pode fazer conexões de maneira nativamente entre dois clientes atrás do NATS sem a necessidade de um servidor de retransmissão pública, mas na maioria dos casos isso não é possível. As conexões NAT-NAT só são possíveis se pelo menos um host tiver um endereço IP estável e acessível ao público: par de portas que pode ser codificado com antecedência, seja usando um FQDN atualizado com DNS dinâmico ou um IP público estático com IP com Uma porta NAT não randomizada foi aberta por pacotes de saída, tudo funciona, desde que todos os colegas possam comunicá-la com antecedência e não mudar quando a conexão for iniciada.
Uma porta e endereço conhecidos precisam ser configurados com antecedência, porque o Wireguard não possui uma camada de sinalização ou servidores de atordoamento público que podem ser usados para procurar outros hosts dinamicamente. O WebRTC é um exemplo de um protocolo que pode configurar dinamicamente uma conexão entre dois NATs, mas faz isso usando um servidor de sinalização fora da banda para detectar a combinação IP: Porta de cada host. O Wireguard não tem isso, por isso funciona apenas com um Endpoint codificado + ListenPort (e PersistentKeepalive para que não caia após a inatividade).
Saiba mais com a Bíblia de Nat Traversal da TailScale: https://tailscale.com/blog/how-nat-traversal-works/
Endpoint codificado e acessível diretamente. Se eles estão atrás do NATS sem endereços IP estáveis, você precisará usar DNS dinâmico ou outra solução para ter um domínio/IP estável e acessivelmente acessível para pelo menos um parListenPort de codificado definido, e o roteador NAT não deve fazer randomização da porta de origem UDP; caso contrário, os pacotes de retorno serão enviados para o ListenPort codificado e que foi retirado pelo roteador, em vez de usar a porta aleatória atribuída pelo Nat no pacote de saídaPersistentKeepalive em todos os outros colegas, para que eles enviem continuamente pings para manter as conexões persistidas na tabela de roteamento de seu NAT Esse processo de envio de um pacote inicial que é rejeitado e, em seguida, usando o fato de que o roteador criou agora uma regra de encaminhamento para aceitar respostas é chamada de "UDP Hole-toque".
Quando você envia um pacote UDP, o roteador (geralmente) cria uma regra temporária que mapeia seu endereço de origem e porta para o endereço e a porta de destino e vice -versa. Os pacotes UDP retornando do endereço de destino e da porta (e nenhum outro) são passados para o endereço e a porta originais da fonte (e nenhum outro). É assim que a maioria dos aplicativos UDP funciona atrás do NATS (por exemplo, BitTorrent, Skype, etc.). Essa regra vai tempo limite após alguns minutos de inatividade; portanto, o cliente por trás do NAT deve enviar pacotes de saída regulares para mantê -lo aberto (consulte PersistentKeepalive ).
Fazer isso funcionar quando os dois pontos finais estão atrás de Nats ou Firewalls exige que ambos os pontos finais enviem pacotes para um outro no mesmo tempo. Isso significa que ambos os lados precisam conhecer os endereços IP públicos de cada um dos outros e os números das portas antes do tempo, no caso de Wireguard, isso é alcançado por portas predefinidas com codificação rígida para ambos os lados no wg0.conf .
A partir de 2019, muitos dos antigos métodos de perfuração usados que costumavam trabalhar não são mais eficazes. Um exemplo foi um novo método pioneiro da PWNAT que falsificou um tempo do ICMP excedeu a resposta de fora do NAT para recuperar um pacote a um colega de natal, vazando assim sua própria porta de origem. Portas UDP de codificação e IPs públicos para ambos os lados de uma conexão Nat para Nat (como descrito acima) ainda funciona em uma pequena porcentagem de redes. Geralmente, quanto mais "empreendimento" é uma rede, menor a probabilidade de você poder dar um soco nas portas UDP públicas (os dados públicos de Wi-Fi e celular comerciais geralmente não funcionam, por exemplo).
As conexões NAT-NAT não são possíveis se todos os pontos de extremidade estiverem atrás de Nats com randomização estrita de porta de origem UDP (por exemplo, a maioria das redes de dados celulares). Como nenhum dos lados é capaz de codificar um ListenPort e garantir que o NAT aceite o tráfego nessa porta após o ping de saída, você não pode coordenar uma porta para o soco inicial entre pares e conexões falhará. Por esse motivo, você geralmente não pode fazer conexões de telefone a telefone nas redes LTE/3G, mas pode fazer telefone ou telefone para casa, onde o escritório ou a casa tem um IP público estável e não A randomização da porta de origem.
As conexões Nat para NAT por trás do NATS com randomização rígida de porta de origem é possível, você só precisa de um servidor de sinalização para informar a cada lado o IP: a tupla da porta. Aqui estão algumas implementações que conseguem isso com o Wireguard:
Muitos usuários relatam ter que reiniciar o Wireguard sempre que um IP dinâmico muda, pois resolve apenas nomes de host na inicialização. Para forçar o Wireguard a solucionar novamente os nomes dinâmicos de Endpoint dinâmicos do DNS, com mais frequência, você pode usar um gancho PostUp para reiniciar o Wireguard a cada poucos minutos ou horas.
Você pode ver se uma configuração de perfuração de orifícios é viável usando o NetCat no cliente e servidor para ver quais portas e pedidos de conexão funcionam para obter uma conexão bidirecional aberta: execute nc -v -u -p 51820 <address of peer2> 51820 ( no Peer1) e nc -v -u -l 0.0.0.0 51820 (no Peer2) e digite o Windows para ver se consegue o tráfego bidirecional. Se não funcionar, independentemente de qual ponto envie o pacote inicial, o Wireguard não será incapaz de trabalhar entre os pares sem um servidor de retransmissão pública.
As conexões NAT-NAT geralmente são mais instáveis e têm outras limitações, e é por isso que ter um servidor de revezamento público de fallback ainda é recomendado.
Exemplo
Peer1:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25Peer2:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25 NOTA: Esta seção é sobre IPs de pares dinâmicos dentro da sub -rede VPN, não endereços Endpoint pública dinâmica .
A alocação dinâmica de IPs de pares (em vez de ter apenas colegas fixos) está sendo desenvolvida, a implementação do WIP está disponível aqui: https://github.com/wireguard/wg-dynamic
Você também pode criar um sistema de alocação dinâmica lendo em valores de IP a partir de arquivos no tempo de execução usando PostUp (veja abaixo).
Exemplo
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) https://git.zx2c4.com/wireguard-go/about/
Uma implementação compatível com Wireguard de Userland escrita em Go.
https://git.zx2c4.com/wireguard-rs/about/
Uma implementação incompleta e insegura do espaço de usuários do Wireguard escrito em Rust (não pronto para o público).
https://git.zx2c4.com/wireguard-hs/about/
Uma implementação incompleta e insegura do espaço de usuários do Wireguard escrito em Haskell (não está pronto para o público).
https://github.com/cloudflare/boringtun
Uma implementação de Wireguard independente e não compatível, escrita em Rust (um garfo separado escrito por Cloudflare). Consulte https://blog.cloudflare.com/boringtun-userspace-wireguard--rust/
Aplicativos Wireguard específicos da plataforma
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-android/about/
https://git.zx2c4.com/wireguard-windows/about/
Todas as implementações do espaço dos usuários são mais lentas que a versão C nativa que é executada na terra do kernel, mas oferece outros benefícios executando na terra do usuário (por exemplo, contêinerização mais fácil, compatibilidade etc.).
Estas são algumas ferramentas de GUI e CLI que envolvem o Wireguard para ajudar com configuração, implantação, gerenciamento de chaves e conexão.
O crédito por esses atalhos vai para: https://www.ericlight.com/new-things-i-didnt-know-about-wireguard.html
Wireguard ignorará um colega cuja chave pública corresponde à chave privada da interface. Assim, você pode distribuir uma única lista de pares em todos os lugares e definir apenas a [Interface] separadamente em cada servidor.
Veja: https://lists.zx2c4.com/pipermail/wireguard/2018-dcember/003703.html
Você pode combinar isso com wg addconf como este:
Cada par possui seu próprio arquivo /etc/wireguard/wg0.conf , que contém apenas sua seção [Interface] .
Cada par também possui um arquivo compartilhado /etc/wireguard/peers.conf , que contém todos os pares.
O arquivo wg0.conf também possui um gancho PostUp : PostUp = wg addconf /etc/wireguard/peers.conf .
Cabe a você decidir como deseja compartilhar os peers.conf , seja por meio de uma plataforma de orquestração adequada, algo muito mais pedestre como o Dropbox ou algo meio selvagem como Ceph. Não sei, mas é ótimo que você possa simplesmente arremessar uma seção de pares, sem se preocupar se é o mesmo que a interface.
Você pode definir valores de configuração de comandos arbitrários ou lendo em valores a partir de arquivos, isso facilita muito o gerenciamento e a implantação das chaves, pois você pode ler em chaves no tempo de execução de um serviço de terceiros como segredos Kubernetes ou AWS KMS.
Veja: https://lists.zx2c4.com/pipermail/wireguard/2018-dcember/003702.html
Exemplo
Você pode ler em um arquivo como o PrivateKey fazendo algo como:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
O Wireguard pode ser executado no Docker com graus variados de facilidade. No caso mais simples, --privileged e --cap-add=all os argumentos podem ser adicionados aos comandos do docker para ativar o carregamento do módulo do kernel.
As configurações podem ficar um pouco complexas e são altamente dependentes do que você está tentando alcançar. Você pode executar o próprio Wireguard em um contêiner e expor uma interface de rede ao host, ou pode fazer com que o Wireguard funcionando no host expondo uma interface a contêineres específicos.
Veja abaixo um exemplo de um Docker Container vpn_test roteando todo o seu tráfego através de um servidor de retransmissão Wireguard.
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
ports :
- 51820:51820/udp
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro wg0.conf :
[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/ UVb7BRqCwad2YMReQgH5tlxz8YmI =
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/ 2Gg =
AllowedIPs = 192.0.2.2/32 Neste exemplo, todo o tráfego de dentro do contêiner speedtest passará pelo Wireguard VPN. Para rotear apenas um pouco de tráfego, substitua 0.0.0.0/0 em wg0.conf abaixo pelas faixas de sub -rede que você deseja rotear via VPN.
docker-compose.yml :
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
vpn_test :
image : curlimages/curl
entrypoint : curl -s http://whatismyip.akamai.com/
network_mode : ' service:wireguard ' wg0.conf :
[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/ sgk8 =
DNS = 1.1.1.1,8.8.8.8
[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+ 2um0c0B1s =
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21Para mais detalhes, consulte a leitura adicional: seção do docker abaixo.
Para obter instruções mais detalhadas, consulte o Guia do Quickstart e a referência da API acima. Você também pode baixar o exemplo completo de configuração aqui: https://github.com/pirate/wireguard-example.
Sugestão alterações: https://github.com/pirate/wireguard-docs/issues
