Network

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

自宅ネットワークの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宛て）が正常に動作することを確認する。

https://remotedesktop.google.com/access https://qiita.com/ninose14/items/473369d76814174dd58f インストール https://remotedesktop.google.com/headless rm -f ~/.chrome-remote-desktop-session スクリプトの改変 cd /opt/google/chrome-remote-desktop cp chrome-remote-desktop chrome-remote-desktop.bak /opt/google/chrome-remote-desktop/chrome-remote-desktop chrome-remote-desktop 106.0.5249.37 #FIRST_X_DISPLAY_NUMBER = 20 FIRST_X_DISPLAY_NUMBER = 0 ※ 0の部分には、デスクトップ環境でターミナルを開き、echo $DISPLAYで表示される値を入れる。 def launch_session(self, server_args, backoff_time): """Launches process required for session and records the backoff time for inhibitors so that process restarts are not attempted again until that time has passed.""" logging.info("Setting up and launching session") self._init_child_env() self.setup_audio() self._setup_gnubby() #self._launch_server(server_args) #if not self._launch_pre_session(): # # If there was no pre-session script, launch the session immediately. # self.launch_desktop_session() display = self.get_unused_display_number() self.child_env['DISPLAY'] = f':{display}' self.server_inhibitor.record_started(MINIMUM_PROCESS_LIFETIME, backoff_time) self.session_inhibitor.record_started(MINIMUM_PROCESS_LIFETIME, backoff_time) sudo systemctl restart chrome-remote-desktop@${USER}.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

環境変数 シェル起動時にネットワーク設定からプロキシ設定を環境変数に読み出すようにしている場合、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

/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権限が必要。 ...

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用語辞典｜ルートゾーン JPRS用語辞典｜権威サーバー（権威DNSサーバー） JPRS用語辞典｜ネームサーバー（DNSサーバー） キャッシュサーバ（フルサービスリゾルバ） クライアントから名前解決要求（再帰問い合わせ）を受け取り、 コンテンツサーバへ反復的に名前解決要求（反復問い合わせ）を送ることで任意のドメイン名の名前解決を行う。 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サーバ（フルサービスリゾルバ）に問い合わせを回送するように設定する。 「再帰問い合わせ」と「非再帰問い合わせ」の違いを教えてください：DNS Tips - ＠IT BIND DNSサーバー構築 | CentOSサーバー構築入門 フォワード（回送） : お父さんのための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ポートフォワーディング：踏み台による中継接続 SSHポートフォワーディングには、 ローカルポートフォワーディング、 リモートポートフォワーディングの2種類があります。 sshポートフォワーディング - Qiita ローカルポートフォワーディングでは、 SSHサーバ側から見えるネットワークポートを SSHクライアント側に転送することができます。 例えば、ファイアウォール（NAT）に守られたネットワーク（ネットワークA）内にあるWebサーバ（ホストX）に 外部ネットワーク（ネットワークB）にあるクライアント（ホストY）から接続したいとき、 踏み台となる、ネットワークBから接続可能なSSHサーバ（ホストZ）がネットワークA内にあれば、 ホストYがホストZにSSH接続することで、 ホストXのWebサーバのネットワークポートに、 ホストYの指定したポートから接続できるようになります （「ホスト」は「各ネットワークに接続した、NICに割り当てられたIPアドレス」に対応）。 [email protected]: $ ssh [email protected] -L "127.0.0.1:10080:hostX.networkA.example:80" [email protected]: $ 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に接続できるようになります。 [email protected]: $ ssh [email protected] -R "127.0.0.1:10080:hostX.networkB.example:80" [email protected]: $ 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つを考えました。 ...