Hospedagem de site que permite apenas a rede privada do WireGuard
Olá, sou um inútil.
Não é muito bom ter a página de administração exposta publicamente, mas no meu caso, atualmente, permito apenas IPs privados do WireGuard para a página de administração. Esta é a forma de configurar isso.
Configurações do lado do WireGuard
Em outras palavras, estou usando vários clientes.
Lado do Cliente
Neste caso, para wg0, como AllowedIPs = 0.0.0.0/0, ::/0, todo o tráfego passa pela rede WireGuard.
No entanto, neste caso, é necessário especificar uma regra no lado do servidor para que este 10.1.0.22 passe pelo NAT do servidor. Isso ocorre porque, caso contrário, este IP não conseguiria sair da rede privada do WireGuard.
Em resumo, é assim:
- wg0
- Passa por todas as redes
- Consulta o DNS interno
- Não consegue sair sem uma regra NAT no lado do servidor WireGuard
- wg1
- Encaminha apenas IPs privados do WireGuard
- Permite apenas o intervalo de valores CIDR de 10.1.0.0/24
- Consulta o DNS interno
- Encaminha apenas IPs privados do WireGuard
wg0.conf :
[Interface]
PrivateKey = Client Private Key
Address = 10.1.0.22/24
DNS = 10.1.0.1
[Peer]
PublicKey = Server PubKey
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = WireGuard Server Endpoint:51820
PreSharedKey = PreSharedKey
wg1.conf :
[Interface]
PrivateKey = Client Private Key
Address = 10.1.0.21/24
DNS = 10.1.0.1
[Peer]
PublicKey = Server PubKey
AllowedIPs = 10.1.0.0/24
Endpoint = WireGuard Server Endpoint:51820
PreSharedKey = PreSharedKey
Lado do Servidor
[Interface]
ListenPort = 51820
Address = 10.1.0.1/24
PrivateKey = Server PrivKey
~~~
[Peer]
PublicKey = Client PubKey
PreSharedKey = PreSharedKey
AllowedIPs = 10.1.0.21/32
PersistentKeepalive = 25
[Peer]
PublicKey = Client PubKey
PreSharedKey = PreSharedKey
AllowedIPs = 10.1.0.22/32
PersistentKeepalive = 25
Fica assim.
Regras NAT do lado do servidor WireGuard
Este é um privilégio dos sistemas BSD, mas as regras NAT são escritas com pf.
# Definição de variáveis
wireguard_clients="{ 10.1.0.4, 10.1.0.22 }"
wanint="vtnet0"
wg_ports="{51820}"
# Reescreve o tráfego que sai de $wireguard_clients para o IP da interface WAN ($wanint) e o envia para a internet
# Configuração NAPT
nat on $wanint inet from $wireguard_clients to any -> $wanint
# Permite conexões WireGuard (UDP 51820) vindas do lado WAN
pass in on $wanint proto udp from any to $wanint port $wg_ports
Isso permite que o próprio IP privado do WireGuard passe pelo NAT do lado do servidor WireGuard.
Configurações do Nginx
a.soulminingrig.com é a configuração da própria página de administração do LumeCMS deste site.
Com allow 10.1.0.0/16;, apenas a rede WireGuard é permitida, e todo o resto é deny all;.
server {
listen 80;
server_name a.soulminingrig.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name a.soulminingrig.com;
client_max_body_size 500M;
location / {
allow 10.1.0.0/16;
deny all;
proxy_pass http://10.1.0.20:3001/;
include proxy_headers.conf;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504 http_403 http_404;
proxy_connect_timeout 3s;
proxy_read_timeout 15s;
}
include common_error_pages.conf;
include ssl_common.conf;
ssl_certificate /usr/local/etc/letsencrypt/live/a.soulminingrig.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /usr/local/etc/letsencrypt/live/a.soulminingrig.com/privkey.pem; # managed by Certbot
}
Por que é possível aplicar restrição de IP sem ser reconhecido como o IP público do servidor WireGuard, mesmo com regras NAT?
Pode haver uma pergunta como essa.
(Eu mesmo criei)
As regras NAT são escritas assim:
nat on $wanint inet from $wireguard_clients to any -> $wanint
Ou seja, on $wanint significa que o NAT é aplicado apenas aos pacotes que passam pela interface WAN.
É um pouco complicado, mas para facilitar a compreensão, vamos usar ifconfig.
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4c079b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,TXCSUM_IPV6>
ether aa
inet aa netmask 0xfffffe00 broadcast aa
inet6 aa prefixlen 64 scopeid 0x1
inet6 aa prefixlen 64
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=0 metric 0 mtu 33152
options=0
groups: pflog
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 10.1.0.1 netmask 0xffffff00
groups: wg
nd6 options=109<PERFORMNUD,IFDISABLED,NO_DAD>
Sim, o WireGuard é apenas uma NIC virtual, então a interface no caso do WireGuard é wg0.
Neste caso, como ele passa por wg0, se for 10.1.0.20:3001 em proxy_pass, os pacotes passarão por esta NIC virtual.
10.1.0.22 -> Corresponde à regra allow 10.1.0.0/16 (10.1.0.0 a 10.1.255.255) -> O proxy_pass do Nginx é 10.1.0.20, então ele é concluído dentro da rede privada.
Durante este processo, como tudo é concluído dentro da NIC virtual em wg0, esta comunicação privada é possível.
Conclusão
Então, o que você achou?
Na verdade, eu pessoalmente não gosto de escrever regras no GNU/Linux, então o pf dos sistemas BSD é incrivelmente fácil neste sentido...
Até a próxima. Agradeço a sua atenção.