ネットワーク on えやみぐさ

Dockerコンテナ内の名前解決をプライベートIPアドレスにする

Sat, 09 Dec 2023 16:50:00 +0900

Docker Engine 24.0
Docker Compose 2.21

プライベートDNSを運用しているネットワークで、 Dockerコンテナからネットワーク内の別のホストに通信したいとき、デフォルトではGoogle Public DNS8.8.8.8でホスト名がグローバルIPアドレスに解決されるため、 ISPやCloudflare Tunnelなどの外部を経由して通信することになり、非効率で危険な通信経路になります。

また、IPアドレスによるアクセス制限を設けている場合、プライベートIPアドレスがソースとなる通信になるように通信経路を制御したい場合があります。

以下の設定により、コンテナ内でexample.comが192.168.0.50に解決されるようになります。

Docker

sudo docker run --rm --add-host "example.com:192.168.0.50" hello-world

Managing /etc/hosts - Docker run reference | Docker Docs

Docker Compose

services:
  app:
    image: hello-world
    extra_hosts:
      - "example.com:192.168.0.50"

extra_hosts - Services top-level element | Docker Docs

Ubuntu ネットワーク帯域を制限する（Wondershaper）

Wed, 28 Jun 2023 19:15:00 +0900

sudo apt install wondershaper

# 上下300kbpsに制限
sudo wondershaper eno1 300 300
sudo wondershaper enp0s31f6 300 300

# 下り1000kbps、上り300kbpsに制限
sudo wondershaper eno1 1000 300
sudo wondershaper enp0s31f6 1000 300

# 帯域制限を解除
sudo wondershaper clear eno1
sudo wondershaper clear enp0s31f6

https://askubuntu.com/questions/20872/how-do-i-limit-internet-bandwidth

rootユーザで/bin/shによるコマンド実行をスケジュール（atコマンド）

echo "wondershaper eno1 300 300" | sudo at 18:00 2023-06-29
echo "wondershaper clear eno1" | sudo at 2:00 2023-06-29

Ubuntu ネットワーク通信量をターミナルからグラフで見る（Speedometer）

Fri, 19 May 2023 09:30:00 +0900

Ubuntu Server 22.04

sudo apt install speedometer

通信量を見たいネットワークデバイスの名前を調べる（eno1、enp0s31f6、enp3s0、eth0、wlan0など）。

ip addr

eno1を目的のデバイスの名前に置き換えて、以下のコマンドを実行する。

speedometer -l -r eno1 -t eno1 -m $(( 1024 * 1024 * 3 / 2 ))

# other examples
speedometer -l -r enp0s31f6 -t enp0s31f6 -m $(( 1024 * 1024 * 3 / 2 ))

speedometer -l -r enp3s0 -t enp3s0 -m $(( 1024 * 1024 * 3 / 2 ))

speedometer -l -r eth0 -t eth0 -m $(( 1024 * 1024 * 3 / 2 ))

speedometer -l -r wlan0 -t wlan0 -m $(( 1024 * 1024 * 3 / 2 ))

参考

networking - How to display network traffic in the terminal? - Ask Ubuntu

自宅サーバのDocker NetworkのIPアドレスプールが枯渇した

Thu, 26 Jan 2023 04:00:00 +0900

https://twitter.com/aoirint/status/1617993934625722368

弊自宅サーバでは、サーバソフトウェアや定期実行プログラムのデプロイに、基本的にDocker Composeを使用しています。

先日、新しいソフトウェアをDocker Composeでデプロイしようとして、以下のエラーが発生しました。

Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

Docker Networkが使用するIPアドレスプールが枯渇し、新しいIPアドレスブロックを確保できなかったという内容のエラーです。

環境

Ubuntu 20.04

$ docker -v
Docker version 20.10.23, build 7155243

$ docker compose version
Docker Compose version v2.15.1

原因

このエラーは、30個程度のDocker Networkを作成すると発生するようです。

Docker Composeでは通常、プロジェクト1つあたり、1つのDocker Networkが作成されます（複雑なプロジェクトでは、2つ以上使用することがあるかもしれません）。手元の環境では、Docker Composeのプロジェクトが27個稼働しており、28個目のプロジェクトを起動したときにエラーが発生しました。

Docker Networkの一覧は、以下のコマンドで確認できます。

docker network ls

Docker NetworkのIPアドレスには、いわゆるプライベートIPアドレスの範囲が使用されます。

プライベートIPアドレスの範囲は、以下のようになります（CIDR表記）。

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

作成されたDocker Networkに割り当てられたIPレンジはdocker network inspectコマンドで確認できます。以下の記事で紹介されているコマンドが便利です。

自宅ネットワークのbind9をdocker composeに移行した

Wed, 25 Jan 2023 03:40:00 +0900

自宅ネットワークのbind9をdocker compose化したので記録。
これまでホストで直接動かしていたけれど、OOM Killerか何かに3,4日に1度くらいでキルされていたので不便だった
これでdocker composeのrestart機構で再起動がかかるようになる
- systemdのrestart機構ワカラナイ
Dockerイメージ: https://hub.docker.com/r/ubuntu/bind9

コード

docker-compose.yml

services:
  bind9:
    image: ubuntu/bind9:9.18-22.04_beta
    restart: always
    ports:
      - "0.0.0.0:53:53/udp"
    volumes:
      - "./volumes/bind_etc/named.conf.local:/etc/bind/named.conf.local:ro"
      - "./volumes/bind_etc/named.conf.options:/etc/bind/named.conf.options:ro"
      - "./volumes/bind_var_cache:/var/cache/bind:rw"
      - "./volumes/bind_var_lib:/var/lib/bind:rw"
    environment:
      - "TZ=Asia/Tokyo"
      - "BIND9_USER=bind" # UID=101

volumes/bind_etc/named.conf.options

acl my-network {
  10.0.0.0/8;
  172.16.0.0/12;
  192.168.0.0/16;
  localhost;
};

options {
  directory "/var/cache/bind";
  response-policy { zone "rpz"; };

  allow-query { any; };
  allow-recursion { my-network; };
  allow-query-cache { my-network; };

  dnssec-validation auto;

  forward only;
  forwarders {
    # ISP DNS1;
    # ISP DNS2;
    8.8.8.8;
    8.8.4.4;
    1.1.1.1;
  };
}

volumes/bind_etc/named.conf.local

zone "example.com" IN {
  type master;
  file "example.com.zone";
};

zone "rpz" {
  type master;
  file "rpz.zone";
  allow-query { none; };
};

volumes/bind_var_cache/example.com.zone

$ORIGIN example.com.
$TTL    3600
@      IN     SOA   ns.example.com.   root.example.com (
    2023012500      ; Serial
    3600            ; Refresh
    900             ; Retry
    604800          ; Expire
    86400           ; Minimum
)

      IN     NS    ns.example.com.
ns     IN     A     127.0.0.1

@      IN     A     127.0.0.1
sub    IN     CNAME example.com.

volumes/bind_var_cache/rpz.zone

$TTL    3600
@       IN     SOA   localhost. root.localhost. (
    2023012500      ; Serial
    3600            ; Refresh
    900             ; Retry
    604800          ; Expire
    86400           ; Minimum
)

        IN     NS    localhost.

; block malicious domains
malicious.example.com A 0.0.0.0

既知の問題

libvirt dnsmasqが53/udpを先に取ると動かなくなりそう？

ホストのbind9をアンインストール

sudo apt purge bind9
sudo rm -rf /var/cache/bind/

OpenVPNとnginxをOpenVPNのPort Share機能で共存させる

Wed, 19 Oct 2022 00:50:00 +0900

TCP 443番ポートは、一般にHTTPSの通信に使われ、ファイアウォールやプロキシによる制限の強いネットワークでも通過できることが多い。一方、WebサーバをホストしたいIPアドレスと、443番ポートでVPNをホストしたいIPアドレスが同一の場合、443番ポートの取り合い（ポート番号の重複）が起きてしまう。

OpenVPNには、OpenVPNが待ち受けるポートへの通信が、 VPNのパケットか、VPN以外のパケット（例えばnginxへのHTTPS通信）かを自動で判別して、 VPN以外のパケットを中継してくれるPort Share機能がある。

つまり、OpenVPNが443番（0.0.0.0:443）で待ち受け、 nginxは他の適当なポート（例えば127.0.0.1:4443）で待ち受けるようにして、 Port Share機能の転送先をnginxに設定すれば、443番で待ち受けるOpenVPNと、本来443番で待ち受けたいnginxとが共存できる。

UbuntuサーバへのOpenVPNの導入は、以下のDigitalOceanの記事が有用なので、参照されたい。

OpenVPNで使用するサーバー証明書・クライアント証明書を発行するCAサーバをセットアップする記事: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-a-certificate-authority-ca-on-ubuntu-20-04
OpenVPNをセットアップする記事: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-an-openvpn-server-on-ubuntu-20-04-ja

OpenVPNのインストールにあたっての重要な点として、 ステップ7 — OpenVPNの設定の（オプション）DNSの変更をプッシュして、VPNを介してすべてのトラフィックをリダイレクトするを実行した上で、 ステップ9 — ファイアウォールの設定を手順通り実行することがある。 NAT下にあるなどの理由でufwの設定をしていなかったサーバーでも、新たにufwの設定をすることで、トラブルなくOpenVPNのインストールができる。このステップを行わないと、VPN外へのパケットの転送が動作せず、VPN接続中のクライアントがインターネットに接続できない状況に陥る。

また、（オプション）ポートとプロトコルの調整で、待ち受けポートを443番、プロトコルをTCPにしておく。 OpenVPNの起動の際には、nginxとポート番号を取り合って起動に失敗しないように、nginxをあらかじめ停止し、ポート番号を書き換えておく。

nginx 設定ファイル

/etc/nginx/sites-enabled/などにあるnginxの設定ファイルを書き換え、 4443番で待ち受けるようにする。

server {
  listen 4443 http2 ssl;
}

大量にサイトをホストしている場合、コマンドやVSCodeなどでまとめて書き換えるとよい。

/etc/openvpn/server/server.conf

OpenVPNのサーバー設定ファイルにport-shareを追記する。

port 443
port-share 127.0.0.1 4443

proto tcp

OpenVPNからnginxへのパケット転送の許可（ufw）

ufw allow from 10.8.0.0/24 to any port 4443

nginx, OpenVPNの再起動

nginxおよびOpenVPNを再起動し、443番ポート宛てのHTTPS通信（nginx宛て）、443番ポート宛てのVPN接続（OpenVPN宛て）が正常に動作することを確認する。

自宅サーバのWebサービスをVPSで中継するようにした

Thu, 07 Apr 2022 11:00:00 +0900

これまで自宅サーバへの外部からの接続には、数年前から自宅のグローバルIPアドレスにフリーのドメインを紐づけて使っていたのですが、 3月末に更新を忘れてこのドメインを失効させてしまいました。

自宅サーバでは、主に個人用のWebサービスや身内用のゲームサーバが動いています。

同じドメインを再取得するには追加の料金がかかりますし、（若干用途が規約的に怪しいこともあり）新しくドメインを取り直す気にもなれなかったので、以前から契約していたVPSをTCP/UDPプロキシとして使ってみることにしました。

この記事では、nginx.confのhttpディレクティブとstreamディレクティブそれぞれについて、拡張子でincludeを切り分けるようにする構成にしています。基本的には、nginx.confに以下のように記述するイメージです。

http {
        include /etc/nginx/conf.d/*.http;
}

stream {
        include /etc/nginx/conf.d/*.stream;
}

関連ツイート
- https://twitter.com/aoirint/status/1510309731642257408
- https://twitter.com/aoirint/status/1511896279731040261

また、この記事の内容には関係ありませんが、envsubstでconfigファイルに環境変数を注入する、nginxのDocker Hub公式Dockerイメージのtemplate機能を使用しているため、 nginx設定ファイルの拡張子がtemplateになっています。

上のツイートに関連して、certbot --nginxで自動生成される/etc/letsencrypt/options-ssl-nginx.confを手動でnginx.confに統合しているので、以下の設定ではコメントアウトされているincludeがあります。

構成

自宅サーバ側：systemd + autosshによる自動SSH接続＆リモートポート転送
VPS側：nginxによるHTTPリバースプロキシ・UDPプロキシ

自宅サーバ側

~/.ssh/config

Host vps*
    HostName VPS_IPADDR
    Port VPS_SSH_PORT
    ServerAliveInterval 10
    ServerAliveCountMax 5
    TCPKeepAlive yes
    IdentitiesOnly yes
    IdentityFile ~/.ssh/vps

Host vps-forwarding-homeserver
    # SERVICE1
    RemoteForward 127.0.0.1:VPS_SERVICE1_PORT 127.0.0.1:LOCAL_SERVICE1_PORT

    # SERVICE2
    RemoteForward 127.0.0.1:VPS_SERVICE2_PORT 127.0.0.1:LOCAL_SERVICE2_PORT

/etc/systemd/system/autossh-vps.service

[Unit]
Description=AutoSSH VPS

[Service]
Type=simple
Restart=always
User=user
Group=user
WorkingDirectory=/home/user
ExecStart=/usr/bin/autossh -N vps-forwarding-homeserver

[Install]
WantedBy=multi-user.target

VPS側

HTTPリバースプロキシ（SSHポート転送使用）: myservice.http.template

server {
    server_name myservice.example.com;

    client_max_body_size 500M;

    add_header Strict-Transport-Security 'max-age=15552000; includeSubDomains; preload';

    location / {
        #auth_basic "Auth required";
        #auth_basic_user_file /secrets/myservice.htpasswd;

        proxy_pass http://127.0.0.1:VPS_MYSERVICE_PORT;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        send_timeout 3600s;
        proxy_connect_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_read_timeout 3600s;
        #proxy_max_temp_file_size 2048m;
    }

    location /.well-known/acme-challenge/ {
        root /letsencrypt-webroot;
    }

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/myservice.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myservice.example.com/privkey.pem;
    # include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

server {
    if ($host = myservice.example.com) {
        return 301 https://$host$request_uri;
    }

    server_name myservice.example.com;
    listen 80;
    return 404;
}

UDPポート転送（SSHポート転送不使用）: myserviceudp.stream.template

server {
        listen VPS_SERVICEUDP_PORT udp reuseport;

        proxy_pass HOME_IPADDR:HOME_SERVICEUDP_PORT;
        proxy_connect_timeout 3600s;
        proxy_timeout 3600s;
        #proxy_max_temp_file_size 2048m;
}

Ubuntu 20.04, ネットワーク設定変更時の認証を回避する

Mon, 29 Nov 2021 20:30:00 +0900

Ubuntu 20.04にアップデートしてから、ネットワーク設定の変更時（接続のON/OFFなど）にSystem policy prevents control of network connectionsと表示され、認証を要求されるようになりました。

ここまではまだいいのですが、認証が表示されるたびに数秒間デスクトップがハングする状態になっていて、ストレスでした。 Keyringのロックを解除するときも数秒間ハングするので、似た原因がありそうです。

ひとまず、設定変更時の認証を要求されないようにして、ハングを防ぐことを試みました。結果として試みは成功し、ハングを回避できるようになりました。

/etc/polkit-1/localauthority/50-local.d/50-allow-network-manager.pkla

[Allow Network Manager all Users]
Identity=unix-user:*
Action=org.freedesktop.NetworkManager.settings.modify.system;org.freedesktop.NetworkManager.network-control
ResultAny=no
ResultInactive=no
ResultActive=yes

systemctl restart network-manager.service

WebDAV in Docker

Sun, 22 Aug 2021 11:15:00 +0900

以下のリポジトリをforkし、Windows 10のExplorerクライアントに対応させたDockerイメージ。 Apache Web ServerのDAV機能でWebDAVサーバを立てる。

https://github.com/BytemarkHosting/docker-webdav

docker-compose.yml

version: '3.9'
services:
  webdav:
    image: aoirint/webdav:2.4-20210822c
    restart: always
    ports:
      - '${DAV_PORT:-127.0.0.1:8000}:80'
    environment:
      LOCATION: /webdav
      ANONYMOUS_METHODS: OPTIONS
      AUTH_TYPE: Basic
      USERNAME: ${DAV_USERNAME:-user}
      PASSWORD: ${DAV_PASSWORD:-password}
      # SKIP_CHOWN: 1
    volumes:
      - ./dav:/var/lib/dav

以上の設定で、dav://127.0.0.1:8000/webdavにWebDAVサーバが立つ。

データは./dav/dataに格納される。

Optional: /etc/fstab

シンボリックリンクは動作しないので、bindfsを使う。

sudo apt install bindfs fuse-utils

/src/path /dest/dav/data/path fuse.bindfs rw,user,uid=YOURUSER 0 0

https://www.netfort.gr.jp/~tosihisa/notebook/doku.php/bindfs

SmokePing in Docker

Sun, 22 Aug 2021 09:45:00 +0900

https://hub.docker.com/r/dperson/smokeping

Copy Configs

docker run --name smokeping --rm -d dperson/smokeping:latest
docker cp smokeping:/etc/smokeping ./config
docker rm -f smokeping

docker-compose.yml

version: '3.9'
services:
  smokeping:
    image: dperson/smokeping:latest
    restart: always
    ports:
      - '{SMOKEPING_PORT:-127.0.0.1:8000}:80'
    volumes:
      - './config:/etc/smokeping:ro'
      - './data:/var/lib/smokeping'
    environment:
      TZ: Asia/Tokyo

config/config.d/Targets

*** Targets ***

probe = FPing

menu = Top
title = Network Latency Grapher
remark = Welcome to the SmokePing website of xxx Company. \
         Here you will learn all about the latency of our network.

+ Home

menu = Home
title = Home Network
#parents = owner:/Test/James location:/

++ Router

menu = Router (192.168.0.1)
title = Router (192.168.0.1)
host = 192.168.0.1

++ MyServer

menu = MyServer (192.168.0.2)
title = MyServer (192.168.0.2)
host = 192.168.0.2
#alerts = someloss

透過プロキシ（macOS, go-transproxy）

Mon, 21 Jun 2021 18:40:00 +0900

環境変数

シェル起動時にネットワーク設定からプロキシ設定を環境変数に読み出すようにしている場合、GUIで設定すればOK。

export HTTP_PROXY=http://proxy.example.com:8080/
export HTTPS_PROXY=http://proxy.example.com:8080/
export NO_PROXY=localhost,127.0.0.0/8,::1

NO_PROXYには必ずlocalhost/ローカルループバックアドレスを設定しておくこと（無限ループする）。

ビルド

https://github.com/wadahiro/go-transproxy

git clone https://github.com/wadahiro/go-transproxy.git
cd go-transproxy/
make

ls go-transproxy/bin/transproxy

# check network device name
ifconfig

~/transproxy/pf.conf

MacBookの無線LANカード：en0

Mac miniなどの場合はNIC名が異なる場合があるので注意。

Packets = "proto tcp from en0 to {!192.168.0.0/16}"
rdr pass log on lo0 $Packets port 80 -> 127.0.0.1 port 3129
rdr pass log on lo0 $Packets port 443 -> 127.0.0.1 port 3130
pass out on en0 route-to lo0 inet $Packets port {80, 443} keep state

有効化

sudo pfctl -ef ~/transproxy/pf.conf
transproxy -disable-iptables

無効化

# stop transproxy process (Ctrl+C)

# reset pf configs
sudo pfctl -df /etc/pf.conf

Macでプロキシとの戦いに疲れたので、透過型プロキシを導入してみた - Qiita

透過プロキシ（Ubuntu, go-transproxy）

Mon, 21 Jun 2021 18:10:00 +0900

/etc/sudoers

Defaults        env_keep+="HTTP_PROXY"
Defaults        env_keep+="HTTPS_PROXY"
Defaults        env_keep+="NO_PROXY"

環境変数

export HTTP_PROXY=http://proxy.example.com:8080/
export HTTPS_PROXY=http://proxy.example.com:8080/
export NO_PROXY=localhost,127.0.0.0/8,::1

NO_PROXYには必ずlocalhost/ローカルループバックアドレスを設定しておくこと（無限ループする）。

デスクトップの場合はGUI設定でOK。

/usr/local/bin/transproxy

https://github.com/wadahiro/go-transproxy

/usr/local/bin/transproxy-start

#!/bin/bash

set -eu

# iptables -t nat -I OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 3131
# iptables -t nat -I OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 3131
iptables -t nat -I OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3129
iptables -t nat -I OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 3130

transproxy -disable-iptables # -dns-over-https-enabled

/usr/local/bin/transproxy-stop

#!/bin/bash

set -eu

# iptables -t nat -D OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 3131
# iptables -t nat -D OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 3131
iptables -t nat -D OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 3130
iptables -t nat -D OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3129

iptablesのルールを書き換えるため、実行時にはroot権限が必要。

bind9

Wed, 09 Jun 2021 01:30:00 +0900

server$ sudo apt install bind9

使用中のDNSサーバの確認

クライアントに設定されているDNSサーバはnmcliコマンドで確認できる。

$ nmcli device show | grep DNS
IP4.DNS[1]:                             8.8.8.8
IP4.DNS[2]:                             8.8.4.4
IP4.DNS[3]:                             1.1.1.1

Command-line to list DNS servers used by my system - Ask Ubuntu

用語

BIND DNSサーバー構築 | CentOSサーバー構築入門

コンテンツサーバ（権威サーバ）

あるゾーン（DNSにおける名前の管理単位）に関する名前解決要求（非再帰問い合わせ）を受け取り、自身が管理するゾーンならば名前解決結果を、委任情報を持つゾーンならば委任先の権威サーバ情報を応答する。

ルートゾーン（FQDN: .）を管理するルートサーバは、TLD（例えば jp.）の権威サーバへの委任情報を持つ。

ゾーン情報において、NSレコードにより指定される。

キャッシュサーバ（フルサービスリゾルバ）

クライアントから名前解決要求（再帰問い合わせ）を受け取り、コンテンツサーバへ反復的に名前解決要求（反復問い合わせ）を送ることで任意のドメイン名の名前解決を行う。

JPRS用語辞典｜フルサービスリゾルバー（キャッシュDNSサーバー）

例えばhoge.example.jp.というドメインの名前解決要求を受け取ったとき、ルートサーバ.への非再帰問い合わせによりjp.権威サーバへの委任情報を取得する。 jp.権威サーバへの非再帰問い合わせによりexample.jp.権威サーバへの委任情報を取得する。 example.jp.権威サーバへの非再帰問い合わせによりhoge.example.jp.のIPアドレスを取得する、のような流れで反復的に問い合わせを行うことでhoge.example.jp.の名前解決を行う。

ISPの提供するDNSサーバや会社などの組織内DNSサーバ、GoogleやCloudflareなどが提供するパブリックDNSがある。

ASCII.jp：DNSによる名前解決の仕組みを理解しよう (1/2)

回送

プロキシのように、受け取った名前解決要求を他のDNSサーバに送り、応答を返す。

/etc/bind/named.conf.options

自身が管理していない情報（ゾーン、委任情報）に関する問い合わせについて、他のDNSサーバ（フルサービスリゾルバ）に問い合わせを回送するように設定する。

デフォルト設定ファイル

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

変更点

forwarders {
        8.8.8.8;
        8.8.4.4;
        1.1.1.1;
};

初歩から解説！BINDでシンプルDNSサーバー構築【構築編】｜開発者ブログ｜株式会社アイソルート

確認

server$ systemctl restart bind9.service

client$ dig @192.168.x.x aoirint.com
...
;; ANSWER SECTION:
aoirint.com.  3600 IN A 185.199.108.153
aoirint.com.  3600 IN A 185.199.111.153
aoirint.com.  3600 IN A 185.199.109.153
aoirint.com.  3600 IN A 185.199.110.153
...

digコマンドの使い方 - Qiita

/etc/bind/named.conf.local

DNSサーバの管理するゾーンの名前と対応する設定ファイル（ゾーンファイル）を設定する。

SSH Port Forwardingを使ってNAT間で通信するPort Proxy Server in Docker

Sun, 21 Mar 2021 03:32:29 +0900

SSHポートフォワーディング：踏み台による中継接続

SSHポートフォワーディングには、ローカルポートフォワーディング、リモートポートフォワーディングの2種類があります。

sshポートフォワーディング - Qiita

ローカルポートフォワーディングでは、 SSHサーバ側から見えるネットワークポートを SSHクライアント側に転送することができます。例えば、ファイアウォール（NAT）に守られたネットワーク（ネットワークA）内にあるWebサーバ（ホストX）に外部ネットワーク（ネットワークB）にあるクライアント（ホストY）から接続したいとき、踏み台となる、ネットワークBから接続可能なSSHサーバ（ホストZ）がネットワークA内にあれば、ホストYがホストZにSSH接続することで、ホストXのWebサーバのネットワークポートに、ホストYの指定したポートから接続できるようになります（「ホスト」は「各ネットワークに接続した、NICに割り当てられたIPアドレス」に対応）。

user@hostY.networkB.example: $ ssh user@hostZ.networkA.example -L "127.0.0.1:10080:hostX.networkA.example:80"

user@hostY.networkB.example: $ wget http://127.0.0.1:10080/index.html
I am "hostX.networkA.example:80".

リモートポートフォワーディングでは、 SSHクライアント側から見えるネットワークポートを SSHサーバ側に転送することができます。先の例でいうと、ホストXがネットワークBに接続していて、ファイアウォール（NAT）によってネットワークAにあるホストZから接続できないとき、ホストYがホストZにSSH接続することで、ホストZからホストXに接続できるようになります。

user@hostY.networkB.example: $ ssh user@hostZ.networkA.example -R "127.0.0.1:10080:hostX.networkB.example:80"

user@hostZ.networkA.example: $ wget http://127.0.0.1:10080/index.html
I am "hostX.networkB.example:80".

この方法は、ネットワーク内のあるホストにSSH接続ができる環境さえあれば、 VPNや他のTCPプロキシをセットアップするより簡単に隠されたネットワークにアクセスすることができるように思います。

ポートプロキシサーバ：2種類のSSHポートフォワーディングの組み合わせ

ここで、別の構成のネットワークについても考えてみます。新しくネットワークCを導入して、ホストXはNAT内のネットワークC（hostX.networkC.example）、ホストYはNAT内のネットワークB（hostY.networkB.example）、ホストZはネットワークB、Cからともに接続可能なネットワークA（hostZ.networkA.example）という構成を考えてみます。

この構成で、ホストYからホストXに接続可能な環境を作るには、次のような手順が考えられます。

ホストXからホストZにSSH接続し、リモートポートフォワーディングによってホストZ上の"ポートQ"をホストX上の"ポートP"に転送する
ホストYからホストZにSSH接続し、ローカルポートフォワーディングによってホストY上の"ポートR"をホストZ上の"ポートQ"に転送する

これにより、ホストYは、自身のポートRを使って、ホストXのポートPに接続することができます。もしホストXに物理的にアクセスできない環境でも、あらかじめホストXをホストZに常時接続するように設定しておけば、その接続（ポートQからポートPへの転送）が生きている限り、好きなタイミングでホストYからホストXに接続（ポートRからポートQへの転送、すなわちポートRからポートPへの転送）することができます。

SSH Port Forwardingを使ったPort Proxy Server in Docker

前項のポートプロキシサーバの問題として、次の3つを考えました。

Ubuntu プロキシ設定

Fri, 02 Oct 2020 15:40:00 +0900

User (Desktop): Settings > Network > Network Proxy

Settings > Network > Network Proxy > Manualに設定する。自動的に環境変数HTTP_PROXY, HTTPS_PROXYにスキームが追加された状態で設定される。

HTTP Proxy: proxy port
HTTPS Proxy: proxy port
Ignore Hosts: localhost, 127.0.0.0/8, ::1（プライベートネットワーク・組織内ネットワークのIPアドレス範囲またはドメインも追加する）

curlやwget、pipなど主要コマンドは注意点として、別ユーザとしてコマンドを実行すると環境変数が引き継がれない。例えばsudo curlしたときにプロキシに接続しにいかない。

/etc/sudoers

sudoでコマンドを実行したとき、実行時シェルに設定されている環境変数を引き継ぐようにする。 sudoersは書き込み禁止になっているためvisudoで編集する。

# run as root
visudo -f /etc/sudoers

Defaults env_keep+="HTTP_PROXY"
Defaults env_keep+="HTTPS_PROXY"
Defaults env_keep+="NO_PROXY"
Defaults env_keep+="EDITOR"

/etc/environment

システム全体の環境変数として設定される。影響範囲が大きいので注意。デスクトップユーザではSettings側の設定（Disabledなら設定されない）が優先されるようだった。

HTTP_PROXY=http://proxy:port
HTTPS_PROXY=http://proxy:port
NO_PROXY=localhost, 127.0.0.0/8, ::1

apt: /etc/apt/apt.conf

Acquire::http::proxy "http://proxy:port";                             
Acquire::https::proxy "http://proxy:port";

Snap: systemctl edit snapd.service

/etc/systemd/system/snapd.service.d/override.confにsystemdの設定ファイルを作成する。