Хостинг веб-сайта, разрешенный только для приватной сети WireGuard

8 min

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

Здравствуйте, я некомпетентен.
Не очень хорошо, когда админ-страница общедоступна, но в моем случае в настоящее время я разрешаю доступ к админ-странице только с приватных IP-адресов WireGuard. Вот как это настроить.

Настройки WireGuard

То есть, я использую несколько клиентов.

На стороне клиента

В этом случае, для wg0, поскольку AllowedIPs = 0.0.0.0/0, ::/0, весь трафик проходит через сеть WireGuard.
Однако в этом случае необходимо указать правило на стороне сервера, чтобы 10.1.0.22 проходил через NAT сервера. Это потому, что в противном случае этот IP-адрес не сможет выйти из приватной сети WireGuard.
Вкратце это выглядит так:

  • wg0
    • Проходит через все сети
    • Запрашивает внутренний DNS
    • Не сможет выйти, если на сервере WireGuard не указано правило для прохождения через NAT
  • wg1
    • Маршрутизирует только приватные IP-адреса WireGuard
      • Проходит только в пределах диапазона значений CIDR 10.1.0.0/24
    • Запрашивает внутренний DNS

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

На стороне сервера

[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

Вот так.

Правила NAT на стороне сервера WireGuard

Это особенность систем на базе BSD, но правила NAT записываются с помощью pf.

# Определение переменных
wireguard_clients="{ 10.1.0.4, 10.1.0.22 }"
wanint="vtnet0"
wg_ports="{51820}"

# Трафик, исходящий от $wireguard_clients, переписывается на IP-адрес WAN-интерфейса ($wanint) и отправляется в интернет.
# Настройка NAPT
nat on $wanint inet from $wireguard_clients to any -> $wanint

# Разрешить подключения WireGuard (UDP 51820), приходящие извне на сторону WAN
pass in on $wanint proto udp from any to $wanint port $wg_ports

Таким образом, приватные IP-адреса WireGuard смогут проходить через NAT на стороне сервера WireGuard.

Настройки Nginx

a.soulminingrig.com — это настройки самой админ-страницы LumeCMS для этого сайта.
С помощью allow 10.1.0.0/16; разрешается только сеть WireGuard, а все остальное 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
}

Почему можно применять IP-ограничения, не распознаваясь как публичный IP-адрес сервера WireGuard, несмотря на наличие правил NAT?

Возможно, возникнет такой вопрос. (Я сам его придумал)

В правилах NAT указано следующее:

nat on $wanint inet from $wireguard_clients to any -> $wanint

То есть, on $wanint означает, что NAT применяется только к пакетам, проходящим через WAN-интерфейс.
Это немного запутанно, но давайте посмотрим 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>

Да, WireGuard — это виртуальный сетевой адаптер, поэтому интерфейс в случае WireGuard — это wg0.
В этом случае, поскольку трафик проходит через wg0, если proxy_pass указывает на 10.1.0.20:3001, пакеты будут проходить через этот виртуальный сетевой адаптер.

10.1.0.22 -> соответствует правилу allow 10.1.0.0/16 (10.1.0.0 ~ 10.1.255.255) -> proxy_pass Nginx указывает на 10.1.0.20, поэтому все завершается внутри приватной сети.
В течение этого времени, поскольку все завершается внутри виртуального сетевого адаптера на wg0, эта приватная связь становится возможной.

В заключение

Итак, что вы думаете?
На самом деле, я лично не люблю записывать правила в GNU/Linux, поэтому pf в системах BSD в этом смысле очень прост...
До новых встреч. Всего наилучшего.

Related Posts