はじめに あまり使わないが、たまに使うとき忘れるのでメモ。 ip rule チートシート 概要 ip rule コマンドは、Linux のポリシーベースルーティング (PBR) を管理するためのツール。 ポリシーベースルーティングとは ポリシールーティング（Policy-Based Routing, PBR）は、 通常のルーティングテーブル（main）とは異なるルールを適用し、 パケットの送信先や経路を柔軟に制御する仕組み。 通常のルーティング（デスティネーションベースのルーティング）は 「宛先 IP アドレス」に基づいてルートを決定するが、ポリシールーティングでは 送信元 IP や特定のプロトコル、インターフェース、ポートなどに基づいて異なるルートを適用可能。 基本的な仕組み IPパケットを送信したいと思う PBRで、利用するルーティングテーブル決定 利用するルーティングテーブルにルーティング情報があれば利用。なければPBRの走査を再開。 なお、数字が小さいほうが優先度が高いことに注意。 感想 いままで考えることもなくip routeの出力を見ていた。 しかし、ip routeで出力されるのはmainテーブルで、そのmainテーブルがip ruleで利用されるように設定されていたから、 ip routeで確認するので良かったのだった。 なお、manにある通り、0, 32766, 32767の3つのruleは最初から設定されている。 ルールの表示 現在のルーティングルールを表示する。オプションはないし、ルーティングテーブルのようにテーブルはない。 ip rule show 出力例 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 10000: to 100.64.0.0/10 lookup 100 気づくこと まずlocalテーブルが確認され、その後にmainテーブルが確認される。 mainテーブルは普段見るとおりだが、localテーブルには何が入っているのだろうか。 Dockerのubuntu:jammyで確認してみる。 ...

はじめに よく忘れるのでメモ。 ip route チートシート 概要 ip route コマンドは、Linux のルーティングテーブルを管理・表示するためのツール。 ルーティングテーブルの表示 現在のmainルーティングテーブルを表示する。 ip route show show のエイリアスとして、ルートを一覧表示する。 ip route list 全てのテーブルの行を表示するには、table allで全てのテーブルを指定する。 ip route show table all どの送信パケットに対して、どのテーブルを使うのかは、ip ruleで取り扱うルールで決まる。 詳細は、ip ruleを参照。 テーブルについて テーブルは、数値のIDで管理され、エイリアス名をつけることもできる。 エイリアスの有無による挙動の差はない。 テーブルの一覧を得るコマンドはない。 テーブルIDの番号が小さいほうが優先度が高いなどはない。 エイリアス名を設定するには、/etc/iproute2/rt_tablesに書き込む。 ID=200のテーブルにmytableという名前をつける例。 echo "200 mytable" | sudo tee -a /etc/iproute2/rt_tables テーブルには、行があるないとは別にテーブルが存在するしないという状態もあるらしい。 実験したところ、一回でも行が存在したテーブルは、存在することになるらしい。 行を足す前(上記コマンドでrt_tablesにID=200のmytableを追加したのみ) コマンド ip route show table 200 結果 RTNETLINK answers: Operation not permitted 行を足して消した後 コマンド ip route show table 200 結果 # エラーなし 多くのディストリビューションでは、下記のような設定がデフォルトでされている。 コマンド ...

はじめに 最近知ったコマンドだが、大切そうなので調べたことをメモ。 ホストのsocketに関する情報を取得するコマンドらしい。 ssの名前の由来: socket statistics ssコマンドをオプションなしで実行すると、ESTABLISHED状態のソケットを表示する。 ss コマンド チートシート 基本構文 ss [オプション] オプションなしの場合、 一般的なオプション オプション 説明 -t TCP ソケットのみ表示 -u UDP ソケットのみ表示 -l LISTEN 状態のソケットのみ表示 -a すべてのソケットを表示 -p プロセス情報を表示 -n 数値表記（ホスト名解決をしない） -r ホスト名を解決して表示 -s ソケットの統計情報を表示 よく使うコマンド すべてのソケットを表示 ss -a TCP のみを表示 ss -t UDP のみを表示 ss -u LISTEN しているポートを確認 ss -tuln 接続中の TCP ソケットを表示 ss -t LISTEN しているプロセスを表示 ss -tlp ポート 80 で LISTEN しているプロセスを確認 ss -tlp | grep :80 プロセス ID（PID）付きでソケット情報を取得 ss -tap 統計情報を表示 ss -s 特定のポートを使用しているソケットを表示（例: 443） ss -at | grep :443 フィルタリングオプション オプション 説明 -4 IPv4 のみ表示 -6 IPv6 のみ表示 state ESTABLISHED 確立された接続のみ表示 state LISTEN LISTEN 状態の接続のみ表示 src <IP> 指定した送信元 IP の接続を表示 dst <IP> 指定した宛先 IP の接続を表示 高度な使用例 すべての TCP ソケットの詳細を表示 ss -tpla すべての UDP ソケットの詳細を表示 ss -upla ある IP からの接続をフィルタリング（例: 192.168.1.1） ss -at src 192.168.1.1 あるポートへの接続をフィルタリング（例: 22） ss -at dst :22 プロセス ID（PID）とともにリスニングしているすべてのポートを表示 ss -ltpn まとめ ss は netstat の代替として推奨される。 カーネル空間から直接データを取得するため高速。 -tuln で LISTEN 中の TCP/UDP ポートを確認できる。 -p でプロセス情報を取得できる。 -s でソケットの統計情報を取得できる。 ss コマンドの歴史 1990年代: net-tools の時代 (netstat) Linux の初期ネットワークツールとして net-tools パッケージが広く使われていた。netstat コマンドが含まれており、ネットワークソケットの状態を確認する手段として普及した。しかし、netstat は古い Berkeley Sockets API に依存しており、カーネルのネットワークスタックの更新に追従しにくくなっていた。 ...

はじめに いつも忘れるのでメモ。 ip link の基本的な出力例 ip link 出力例 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff この出力の場合における、lo,eth0について見ていく。 loについて 1行目: インターフェース情報 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 1: インターフェースのID=1。（loは1番目のインターフェース） lo: インターフェース名 (lo はループバックインターフェース) <LOOPBACK,UP,LOWER_UP>: インターフェースのフラグ LOOPBACK: ループバックデバイスである UP: インターフェースが有効（ifconfig lo up と同じ） LOWER_UP: 物理層または仮想層でリンクが確立している mtu 65536: MTU（Maximum Transmission Unit、最大転送単位）=65536。デフォルトで 65536（ループバック） qdisc noqueue: Queueing discipline=nonqueue（パケットスケジューリング） state UNKNOWN: インターフェースの状態=UNKNOWN（UNKNOWN, UP, DOWN など） mode DEFAULT: 動作モード=DEFAULT（通常は DEFAULT） group default: グループ=default（通常は default） qlen 1000: キューの長さ=1000（パケットをバッファリングできる数） 2行目: MACアドレス情報 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 link/loopback: インターフェースの種類（loopback, ether, etc.） 00:00:00:00:00:00: MACアドレス=00:00:00:00:00:00（ループバックはゼロ） brd 00:00:00:00:00:00: ブロードキャストアドレス=00:00:00:00:00:00 ...

はじめに systemd-resolvedは、DNS名前解決まわりに関するsystemdのservice。 個人的には普段使わないが、使う機会があったので見返すようにメモ。 なお、フロントエンドのコマンドはresolvectl。 digとの違い digは直接DNSのURLに問い合わせる resolvectlはsystemd-resolvedに問い合わせる(systemd-resolvedが設定されたURLに問い合わせる) また、digの方が詳細なクエリができる。あくまでresolvectlはsystemd-resolvedのフロントエンドという性質が強いみたい。 1. 基本情報の確認 1-1. systemd-resolved のステータスと DNS 設定を表示 resolvectl status 1-2. インターフェースごとの DNS サーバーを表示 resolvectl dns 1-3. インターフェースごとのドメイン検索リストを表示 resolvectl domain 1-4. DNS クエリ統計情報を表示 これだけsudoが必要だった。 sudo resolvectl statistics 2. 特定のドメインの解決 2-1. example.com の DNS 解決結果を表示 resolvectl query example.com 2-2. 簡潔な出力（テーブル形式なし） resolvectl query example.com --legend=no 2-3. MX レコードを取得 resolvectl query example.com --type=MX 2-4. IPv6 アドレスを取得 resolvectl query example.com --type=AAAA 3. 特定のインターフェースを使用した解決 3-1. wlan0 インターフェースを使って example.com を解決 resolvectl query example.com --interface=wlan0 3-2. SRV レコードを取得 resolvectl query example.com --service 4. DNS キャッシュの管理 4-1. DNS キャッシュをクリア resolvectl flush-caches 4-2. キャッシュヒット数などの統計を表示 resolvectl statistics 5. DNS 設定の変更 5-1. eth0 の DNS サーバーを 8.8.8.8 と 1.1.1.1 に設定 resolvectl dns eth0 8.8.8.8 1.1.1.1 5-2. eth0 に example.com を検索ドメインとして設定 resolvectl domain eth0 example.com 5-3. eth0 のデフォルトルートを有効化 resolvectl default-route eth0 yes 6. mDNS、LLMNR、DNSOverTLS の設定 6-1. eth0 で mDNS を有効化 resolvectl mdns eth0 yes 6-2. eth0 で LLMNR を有効化 resolvectl llmnr eth0 yes 6-3. DNSSEC を有効化 resolvectl dnssec yes 6-4. DNS-over-TLS を有効化（サポートされている場合） resolvectl dnsovertls yes 7. systemd-resolved の管理 7-1. systemd-resolved のステータス確認 systemctl status systemd-resolved 7-2. systemd-resolved を再起動 systemctl restart systemd-resolved 7-3. systemd-resolved を停止 systemctl stop systemd-resolved 7-4. systemd-resolved を無効化 systemctl disable systemd-resolved 8. トラブルシューティング 8-1. /etc/resolv.conf の内容を確認 systemd-resolved が管理している場合は 127.0.0.53 が設定されている ...

はじめに いつも忘れるのでメモ。 tar コマンド チートシート 基本構文 tar [OPTION]... [ARCHIVE] [FILE]... なお、オプションの付け方としては、下記の3種類が主にあるよう。 tar x(古い) tar -x(POSIX) tar –extract(GNU) 他のオプションをサポートしているtarの実装も多いが、--extractはPOSIXではなくGNUの独自実装の側面があるので、-xが無難らしい。 (GNUはPOSIXの拡張のようなものだと思うので、確かに-xが良さそう。個人的には、--extract,-xどちらもPOSIXであって欲しかった) 他には、dd、ps、ls、findなどがこのような状況らしい。 基本的な使い方 1. ファイルやディレクトリをアーカイブする tar -cvf archive.tar file1 file2 directory/ 2. アーカイブを展開する tar -xvf archive.tar 3. 圧縮したアーカイブを作成する（gzip） tar -czvf archive.tar.gz file1 file2 directory/ 4. 圧縮したアーカイブを展開する（gzip） tar -xzvf archive.tar.gz 5. 圧縮したアーカイブを作成する（bzip2） tar -cjvf archive.tar.bz2 file1 file2 directory/ 6. 圧縮したアーカイブを展開する（bzip2） tar -xjvf archive.tar.bz2 7. 指定ディレクトリに展開する tar -xvf archive.tar -C /path/to/destination 8. アーカイブ内のファイル一覧を表示する tar -tvf archive.tar オプション一覧 オプション 説明 -c 新規アーカイブを作成する -x アーカイブを展開する -v 処理中のファイルを表示する -f アーカイブのファイル名を指定する -z gzip で圧縮する -j bzip2 で圧縮する -C 指定したディレクトリへ展開する -t アーカイブの内容を一覧表示する 応用例 1. 特定のファイルをアーカイブから取り出す tar -xvf archive.tar file1 2. 指定したファイルをアーカイブから削除する tar --delete -f archive.tar file1 3. 複数のファイルを追加する tar -rvf archive.tar newfile1 newfile2 4. 圧縮されたアーカイブの内容を確認する tar -tzvf archive.tar.gz 5. find コマンドと組み合わせてアーカイブする find . -name "*.log" | tar -czvf logs.tar.gz -T - 6. SSH 経由でリモートにアーカイブを送る tar -czvf - directory/ | ssh user@remote "cat > remote.tar.gz" まとめ tar コマンドは、ファイルのアーカイブや圧縮に便利なツールである。-c で作成、-x で展開、-z で gzip 圧縮、-j で bzip2 圧縮を行う。オプションを適切に組み合わせることで、効率的にファイル管理ができる。 ...

はじめに tailscaleのことを徐々にメモしていく。 用語 exit node tailscaleは通常、最初にSaasのtailscaleサーバと通信してピアノードの情報を得たら、あとはP2PでVPN通信を行う。 また、各ノードはピアとのVPN通信以外の通信においては通常、tailscaleがないのと同じように通信を行う。 逆に通常のVPNは、クライアントサーバモデルになっており、クライアントは物理LANを除く全ての通信をVPNサーバを経由することで行う。VPNサーバがデフォルトゲートウェイのように振る舞う。 exit nodeは、tailscaleを通常のVPNのように、VPN参加のノードが1つのサーバから外部へリクエストできるようになる。ただし、この1つのサーバはtailscaleノードである必要があり、これをexit nodeという。また、ピアノードへの通信はあくまで今までどおりP2Pで行えるらしい。 ref: https://tailscale.com/kb/1103/exit-nodes

dpkg コマンド チートシート 1. パッケージのインストール dpkg -i package.deb # `.deb` パッケージをインストール 2. パッケージの削除 dpkg -r package-name # 設定ファイルを残してパッケージを削除 dpkg -P package-name # 設定ファイルも含めて完全に削除 3. インストール済みパッケージの確認 dpkg -l # インストール済みパッケージ一覧を表示 dpkg -l | grep package-name # 指定パッケージの情報を検索 4. パッケージの詳細情報を確認 dpkg -s package-name # 指定パッケージの情報を表示（ステータスなど） dpkg -p package-name # まだインストールされていないパッケージの情報を表示 5. パッケージに含まれるファイル一覧を表示 dpkg -L package-name # インストール済みのパッケージが持つファイル一覧 dpkg -c package.deb # `.deb` パッケージ内のファイル一覧を確認 6. 特定のファイルがどのパッケージに属しているか調べる dpkg -S /path/to/file # 指定したファイルを含むパッケージを検索 7. パッケージの再インストール dpkg --configure -a # 設定が未完了のパッケージを再設定 dpkg -i package.deb # `.deb` パッケージを再インストール 8. パッケージの強制インストール・削除 dpkg --force-all -i package.deb # 依存関係を無視してインストール dpkg --force-all -r package-name # 依存関係を無視して削除 9. パッケージの依存関係エラーを修正 apt-get install -f # 破損した依存関係を修復 10. .deb パッケージを展開 dpkg-deb -x package.deb /path/to/extract # `.deb` の内容を展開 dpkg-deb --info package.deb # `.deb` のパッケージ情報を表示 dpkg-deb --control package.deb ./control # `DEBIAN/control` ファイルを抽出 dpkg だけでは依存関係を解決できない？ dpkg はパッケージのインストール・削除はできるが、依存関係の解決は行わない 依存関係を解決するためには apt や apt-get を利用するのが一般的 apt install ./package.deb # `.deb` パッケージを依存関係も含めてインストール よくあるトラブルと対処法 ✅ dpkg: error: dpkg frontend is locked by another process sudo rm /var/lib/dpkg/lock sudo rm /var/lib/dpkg/lock-frontend sudo dpkg --configure -a 別のプロセスが dpkg を使用中の場合、ロックファイルを削除して修正 ...

はじめに .debファイルは、debian系のOSで使われる、アプリケーションをインストールするための情報が全て入ったファイル。 今回は、VSCodeのdebパッケージを眺めてみる。 題材 最新のVSCodeパッケージ。(2025/2/21現在だと、code_1.97.2-1739406807_amd64.deb) 環境 OS: Ubuntu 24.04.2 LTS CPU: x86_64 構成要素 公式サイトからダウンロードして実際に調べてみる。 ダウンロード後にまず、archiveファイルなので、ar xで展開する。 通常は、専用のコマンドであるdpkg-debコマンドで展開するとよいらしいが、今回は学習目的なので手動で展開して見ていく。 (展開せずにarchiveファイルに含まれたファイルを見るだけなら、ar t stableで見られる) # wget https://update.code.visualstudio.com/1.97.2/linux-deb-x64/stable ar x stable 下記の4つが出てくる。 1. debian-binary 2. control.tar.xz 3. data.tar.xz 4. _gpgorigin 1. debian-binary パッケージフォーマットのバージョンを記述したテキストファイル。通常、内容は 2.0（Debianパッケージフォーマットのバージョン）。 実際、今回も2.0と書かれていた。 cat debian-binary 2.0 2. data.tar.xz tar -xvf data.tar.xz 2947ファイルも生成された。 tar -xvf data.tar.xz | wc -l 2947 一部抜粋。 ./usr/share/code/resources/app/node_modules.asar.unpacked/vsda/build/Release/ ./usr/share/code/resources/app/node_modules.asar.unpacked/vsda/build/Release/vsda.node ./usr/share/code/resources/app/node_modules.asar.unpacked/vsda/rust/ ./usr/share/code/resources/app/node_modules.asar.unpacked/vsda/rust/web/ ./usr/share/code/resources/app/node_modules.asar.unpacked/vsda/rust/web/vsda_bg.wasm ./usr/share/code/resources/app/out/ ./usr/share/code/resources/app/out/bootstrap-fork.js ./usr/share/code/resources/app/out/cli.js ./usr/share/code/resources/app/out/main.js ./usr/share/code/resources/app/out/media/ ... 上記のようにすべて、./usr/shareの中に作られていた。 debパッケージのdata.tarは基本的にインストールするシステムのルートディレクトリに展開されると考えてよいらしい。 そして、一般に/usr/shareにはアーキテクチャ非依存のファイルが置かれるらしい(つまり、jsやwasm、pngファイルなどが置かれるものらしい)。 それならば、x86のELFバイナリなどはなさそうだが調べてみたら、たくさん(といっても下記の27ファイル程度)ありそうだった。 理由を調べてみたいが、今回は一旦ここで終了。 ...

xargs コマンド チートシート xargs は、標準入力やパイプで渡されたデータをコマンドの引数として扱うための便利なユーティリティ。 基本的な使い方 echo "file1 file2 file3" | xargs rm rm file1 file2 file3 と同じ動作をする。 ls | xargs -I {} echo "Processing {}" 各ファイル名を {} に展開して echo する。 -I を使用した変数の展開 echo "apple orange banana" | xargs -I {} echo "Fruit: {}" Fruit: apple、Fruit: orange、Fruit: banana と出力される。 -n を使って指定個数ごとに処理 echo "1 2 3 4 5 6" | xargs -n 2 echo echo に2つずつ渡す。 1 2 3 4 5 6 -P を使って並列処理 echo "1 2 3 4" | xargs -n 1 -P 2 echo 2つのプロセスを並列実行。 -0 を使ってヌル文字区切りの入力を処理 find . -type f -print0 | xargs -0 rm -print0 でヌル文字区切りにし、-0 で適切に処理。 -d を使ってカスタム区切り文字を設定 echo "a:b:c" | xargs -d ":" echo : で区切り、echo a b c と実行。 -t を使って実行されるコマンドを表示 echo "file1 file2" | xargs -t rm 実際に実行される rm file1 file2 を表示。 -p を使って確認しながら実行 echo "file1 file2" | xargs -p rm 実行前に rm file1 file2 ?... と確認を求める。 -L を使って1行ずつ処理 echo -e "one\ntwo\nthree" | xargs -L 1 echo "Line:" 各行を echo に渡す。 ...