Network

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

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 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

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化したので記録。 これまでホストで直接動かしていたけれど、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/

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宛て）が正常に動作することを確認する。

これまで自宅サーバへの外部からの接続には、 数年前から自宅のグローバル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にアップデートしてから、ネットワーク設定の変更時（接続のON/OFFなど）にSystem policy prevents control of network connectionsと表示され、認証を要求されるようになりました。 ここまではまだいいのですが、認証が表示されるたびに数秒間デスクトップがハングする状態になっていて、ストレスでした。 Keyringのロックを解除するときも数秒間ハングするので、似た原因がありそうです。 ひとまず、設定変更時の認証を要求されないようにして、ハングを防ぐことを試みました。結果として試みは成功し、ハングを回避できるようになりました。 https://unix.stackexchange.com/questions/534469/system-policy-prevents-control-of-network-connections https://code.luasoftware.com/tutorials/linux/ubuntu-prompt-system-policy-prevents-modification-of-network-settings-for-all-users/ /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

https://github.com/aoirint/webdav-docker https://hub.docker.com/r/aoirint/webdav 以下のリポジトリを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

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