Hospedagem de site que permite apenas a rede privada do WireGuard

8 min

language: ja bn en es hi pt ru zh-cn zh-tw

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

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.

Related Posts