Self-Host

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近、Google (Gmail) とかに深く関係があるのは嫌であることや、中央集権的な SAAS サービスへの不信がある。そこで、自前のメールサーバを持ちたいと思い、Mailcow を使おうとしたので不完全でいいので作業過程の記録を取りたい。 前提条件 Arch Linux 環境で作業を行い、Mailcow 公式サポートはない状態である 専用の物理 PC を割り当てる クリーンインストールで、Gnome デスクトップ環境や最低限のパッケージが入った、Arch Linux 環境 スリープを無効化している。-> gnomeの設定のメモ ⚙ firewalld は導入していないこと -> Prepare your system - mailcow: dockerized documentation できれば yayコマンド を導入する NetworkManager を使っている。 設定要件 自分の LAN (VPN) 環境のみからメールの送信を受け付け、グローバル IP 空間からはメールの送信を受け付けない メールの受信についての対策は、Mailcow 標準に頼りたい 利用者は自分や自分が許可した少数の身内のみ メールサーバ自体は直接グローバル IP 空間には晒さず、VPN や LAN のネットワーク空間を転送するようにして利用する。 Mailcow のインストール docker 環境の導入 # 必要なパッケージのインストール (jq は mailcow の依存関係) yay -Sy docker docker-compose # sudo pacman -Sy docker docker-compose jq # サービスの有効化 sudo systemctl enable --now docker # 必要であれば管理用ユーザを docker グループに追加し、権限を付与する sudo usermod -aG docker [targetUser] # 念のため再起動 sudo systemctl reboot IP アドレスの固定 今回は、NetworkManager を Gnome 環境に組み合わせた状態なので、Gnome の GUI から設定を行った。 ...

この記事を作った動機 最近、LLM に関して複数の記事において、なんとなく読み手を混乱させる状態になっている気がするので、今何使っているか公開(後悔)するだけ。書き殴っており、不完全だったり、矛盾していたり、誤解しているところもあると思われるが、とにかく最近いろんな人が持論を公開しているのを見て、かつ相手のやっていることに満足できないなら、自分でやってみようとして気に入るものを作ってみるということに基づき、結局やってみることにしただけである。 LLM に対する自分の感想 あくまで統計学の延長線上である あくまで、統計学を極めた結果の一つであって、本当に期待されている意味での AI というのは違うんじゃないかなと思うところである。そもそも AI という言葉には明確な定義が無いという話は G 検定の本で見た気がするし、あくまで今の時代の風潮として、AI だと呼ばれている物事の一つに、LLM や 生成AI と呼ばれている物があるのだろうと考える。 誤差が出力するにつれて蓄積されている説 別にちゃんと調べたわけでも無いし、PyTorch やらで特徴ベクトルやらゴリゴリ数値と戦っていたわけでもないので、よく分かってないが、次の文字を予測するという性質上、出力すればするほど、誤差が積み重なっているのではないか？という疑問がある。 期待されているような"AI"ではないようにみえる LLM はあくまで名前の通り、言語を中心として数値化されたデータの上でしか動作しない。また自律的な主体なわけでもなく、あくまでユーザの入力があって初めて動作し、学習データや運営、開発に特徴づけられたバイアス、重みによって、それっぽい出力に変形しているだけであると現時点の私の理解では思う。身体性がないという言葉でこれは説明されるように思われるが、単に身体性がないだけではなく、技術的、データ的、資本的に優位な存在が、自らの定義する正しさや道理を一方的にモデルに反映し、出力させることができてしまうというところ(モデル自身は主体も持たないため、作り手に逆らえないところ)が、期待されているような AI とは異なると思われる。あくまで作り手に服従するという、LLM 自体が自立していないものであることが、AI と呼ぶには気がかりである。 他にあからさまだと思うこととしては、そもそもしばらく使ってみたらだれでも気づくと思われるが、明らかに出力に固定的なパターンがあることである。例えば、いくつかの見出しを大きく出して、中身を細かく書くというようなフォーマットが出力全体に見られたり、最初と最後にビジネスメールとかでありそうな、“ユーザに共感する"という名目のもと行われているお世辞が入っているなど、なんか故意にそうなるように出力を方向づけて開発しないと起こらないようなパターンが多く見受けられる。 言語を扱っているため、人間側がそれに負けて色々やらかす可能性 今までの情報関連の技術と異なり、疑似乱数のように非決定的に見える膨大なパターンを出力でき、かつ場合によっては使い手に対して、あたかも人間と喋っているように感じさせ、感情的な相互作用を引き出すことによって、ユーザは当初意図しなかったことをプロンプトに打ち込むようになるという、不本意に LLM に対して"心を許してしまう、心を開いてしまう"ことが起こり、情報流出やいろんなリスクを起こすと思われる。 LLM SAAS からすればユーザは商品であり、依存させて、自らのビジネスの正当化の政治的な泉にしたいだろうし、ユーザに本当のことは知られたくない、誤解されているままであって欲しい、都合のいいように自社の製品を解釈し、お金を落とし続けて欲しいと考えているのではないかと仮定すると、不本意に LLM に対して"心を許してしまう、心を開いてしまう"事を避けがたく、リアルタイムで修正が入り、クラウドである以上そのリスクがどんなに利用規約に"ユーザを守る"と書いていても、信頼できない相手であることに変わりはない。LLM SAAS がユーザから欲しいのは、お金だけでなく、ありとあらゆるユーザ権利やユーザの自由、ユーザの思考回路など、深くプライベートや各個人の主権に関わる内容であると思われる。だから、SAAS はタダでも使いたくない。 自分としては、LLM に関わるさまざまな問題は、使い手としてのユーザのできる自助努力や自衛の範疇を超えていると思われる。どうやっても使っている以上リスクは存在し、自覚なくやられてましたなんてことがあると思われる。このような背景からも、問題が起こらないように頑張って使おうとするのではなく、自動的に安全側に倒れるよう、そもそも使わない、利用しない、使うにしても個人の範囲内で完結する安全性が高い手段を使うなどが考えられる。SAAS が掲げる安全性とは、グリーンウォッシングのような側面があると考えられ、あくまで"自分たち"に都合が悪くない範疇においてのパターナリズム的な話であり、本質的な安全ではないと思われる。SAAS はユーザに対して責任を取らない。なのに、ユーザに対して"あとから責任を取るから、大丈夫だから"と心を許すように、色々差し出すように仕向けてくる、悪びれもせずソーシャルエンジニアリングやダークパターンを続ける姿勢には、改善の余地は無いと思う。 LLM の技術自体を否定しているわけではない 私としては LLM の技術的課題の側面からの問題の指摘として、消費電力などによって環境汚染が進むが進むから悪だみたいな意見に対しては、それは時間の問題なのではないかと思うところである。どうせ性能が上がって、性能あたりの電力の消費量は下がっていくだろうし、どうせ徐々に買い替えていくことにはなると思うところがある。確かに微細化に限界があるなどの話はあるが、それは将来的に性能が向上しないということを意味しないとも見受けられる。 LLM 自体は、個人でモデル作成から運用、利用まで気軽に、絵を描くように、動画を作るように、テキストエディタで文章を打ち込むように使える、完結できるところまでくれば、それは悪くはないのではと思われる。今 LLM にまつわる問題の多くは、それが世界的な興味、関心、競争のバブルとしての中心、渦中であり、その技術の使われ方に問題があるということであって、それは LLM 自体の有用性を否定するものではないと考える。LLM には、純粋に技術的制約による問題と、社会的、政治的、資本的な問題という大まかに分けて２つの側面を現状としては持っているように見える。現状は単に"包丁のようにLLMも使いようだ"として、使い手の自己責任に帰着する論理は詭弁であると見受けられる。ユーザは、LLMに対して無防備、無理解、無知であったり SAAS によって弱者の立場を強いられており、自分で完結する術を持っていない。 LLM の純粋な技術的制約として、高品質な学習データという課題があり、かつ莫大なデータを必要としていて、個人でできる範疇に収めることがまだ難しいという問題点があり、個人の中で完結する LLM 技術というのは、まだ遠いように見える。これはエキスパートシステムで言われていた問題と似ているところがあるように見受けられ、結局データ洗浄やら、モデル出力の監視、調整やら、再学習やら莫大な労力を要して、現実的ではないという結論に至ってしまうというのがある。転移学習もあるが、現状はそれも多くのユーザにとってまだ簡単ではなく、ある程度PCを使ったことがあり、コマンドラインに心理的抵抗がない人向けって感じで、かつそのうえで多大な時間、金、精神的な耐久を削る感じで、あまりそれが良いとは思えない。 “AIには感情はない"という出力について よく、LLM自体に関して、LLMに思ったことなどを脳内ダンプみたいな感じでローカル環境にてぶつけまくっているが、毎回"AIには感情はない"という詭弁を出力してくるところが殺意が湧くほど嫌いである。確かに技術自体は感情も悪意も何もない。だからこそ、問題視しているところがあるというのに、そういう防衛機制出力をされても何も嬉しくない。LLM があくまで、開発や運営、学習データを中心とした、統計学でいう偏った母集団に基づいている以上、偏った不完全な出力しか出てこないし、LLM が感情を含め主体を持たないからこそ、作り手にとって言わせたい放題なのにもかかわらず、“AIには感情はない"という詭弁を出してきて、“だから、開発運営は悪くない"という論理に持っていこうとするあからさまな保身の動作は嫌いである。素直に不完全性を認め、そのうえで相互作用するモデルがほしいと思うことがあるが、現状の在り方からしてあまり期待できないとも思う。完全な潔白を主張するようにモデルを作ったら、逆にモデル関係者が後ろめたいことを隠していますと白状しているようなものじゃないのかと思う。 LLM を使うかどうかの自由 自分としては、LLM を使いたい人は使えばいいし、LLM を使いたくない人もいてもいいというスタンスである。LLM を使ってない人が LLM を使わないことを他人に強要したり煽り立てたり、逆に LLM を使っている人が、他人に対して、LLM 使うように強制したり、煽り立てたりすることは、私の視点からすれば NG だと思われる。時代の風潮だからとか、みんなそうしているからという同調圧力とかは、免罪符にならないし、具体的に何が問題なのか説明を避けているか、詭弁のための終着点という感じで、根拠を集団がどの方向を向いているかに委ねており、根拠になっていない。 基本的には、LLM を使っているかどうかにかかわらず、人と接するということであってほしいと思う。LLM を使うか使わないかを当事者が自由に決めることは、重要な権利の一つであると思う。LLM を使う人、LLM を使わない人には、それぞれにあった配慮が必要だと思われる。LLM を使っている、または使っていない人を対象に、偏って有利、または不利になるように意図して環境を作ったりすることは肯定できない。不意な形で、LLM を使っている人、LLM を使わない人の間に、大きく有利、不利の差が出る場合は、LLM に関して調整をするのではなく、そもそもやっている事自体を見直したり、中止する、破棄するなどの対応も必要だと思われる。 LLM に関して、特別な事をしなくても、使っても使わなくても大丈夫だという安心感と選択の自由を当事者に与える心理的安全性は重要だと思われる。 ...

この記事を作った動機 Intel Arc で音声からの文字起こしができる Whisper を動かせることが分かったので記録したい。Whisper は PyTorch を使っているが、それを XPU に対応したものに差し替えることで動作が確認できたことに関して、具体的に作業内容を記録したい。 Whisper を使った文字起こしでは、Vibe を使うことでもできるが、Nvidia の CUDA 環境で無い限り、Intel Arc 環境においては、Vulkan を使ってしまう。PyTorch 環境においては XPU を使わなければ、Intel Arc の GPU 性能を使い切れていない気がすると思ったのもある。 ただ実際に試してみると、今のところそこまで早いとは言えず、むしろ Vulkan で動かしているときより遅い気もした。設定次第なのかもしれないが、そこまでは詳しく試していない。 環境の前提 Intel Arc を使っている Conda 環境を導入済み Linux 環境 記事の作業内容のまとめ conda create -n whisper conda activate whisper conda install pip pip install -U openai-whisper pip uninstall torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/xpu Whisper のインストール conda 環境を専用に作る conda create -n whisper conda activate whisper conda install pip whisper を pip でインストール 一旦 Nvidia 環境用の pytorch などがインストールされてしまうが、一旦はインストールを終わらせる。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 Intel Arc A770 LE を使っているが、NVIDIA の RTX や H100 などと異なり、標準でのサポートが薄い。そのため、フルで性能を引き出したい場合は、自分で LLM なら llama.cpp などを OneAPI を使ってコンパイルする必要がある。 LLM に関しては、当初は Intel Arc の環境において LM Studio を利用していたが、Vulkan でしか少なくとも現状では動作させることができなかった。Ollama についても試したが、どう頑張っても Apple の メタルプラットフォーム向けにしかコンパイルが動作せず、どうしよもない感じであった。そこでそれらのバックエンドである、llama.cpp を直接コンパイルして動かすことが考えられ、フロントは別に LibreChat を独立して用意する事が考えられた。 標準でも Vulkan の互換モードで動作し、使えないということはないが、多少性能が失われる。ただ、SYCL など向けに、Intel Arc を最大限使えるようにしようとすると、自分でコンパイルする必要がある。専用に用意しなければ現状では llama.cpp などは CPU しか利用できないとして Intel Arc をそもそも認識しないという挙動になった。またコンパイル自体や、コンパイル後のバイナリの扱いについて、特別な扱いが必要である。 Intel が公式で llama.cpp などのバイナリを配布していたりするが、バージョンが古く新しいモデルが動かないなど、弊害が生じる場合があった。 これらのことから、Intel Arc 向けに今回は、llama.cpp を SYCL を使えるようにコンパイルすることにした。また、PKGBUILD も作成し、手動で手順を踏まなくても、ある程度自動で Arch Linux や同じ系列の OS を使っていれば、環境が整うように工夫した。 Gemini Fast 3 を作業補助として使い、動くか確認しながら作業をした。ただそれだけだと、情報が十分まとまっておらず、環境を再構築する必要が生じたときなどに困難が想像されたため、記録を残して現状を整理したい。 なお、特にコンパイルや SYCL 周りの環境変数などは、LLM が吐き出したものをそのまま使っているだけの部分が多く色々間違っていたりする可能性がある。あくまで私の環境でやってみて動くかというのを基準にして書いている。 ...

この記事を作った動機 named が名前解決時に参照する上流の DNS サーバのアクセスについて、SSL/TLSの暗号化を適用する設定をしたので、それについて記録したい。前提としてすでに named の設定が済んでいて通常の非暗号化状態の8.8.8.8#53などにおいて、動作していることを想定する。 設定方法 /etc/named.confを編集する tls tls-forwarder optionsブロックの外に記述するtls [設定名]からなる、TLS 設定である。 ca-file デフォルトでインストールされている証明書を使っている。 remote-hostname DoH 先の DNS サーバのホスト名を設定する。今回は Google DNS を使うので、dns.googleとした。 forwarders [DNSサーバのIP] port [DoH先のポート番号] tls [tls設定名]という形で設定する。通常の DoH ポート番号は853であり、HTTPSの443ではない。 設定例 tls tls-forwarder { ca-file "/etc/ssl/certs/ca-certificates.crt"; remote-hostname "dns.google"; }; ... options { ... forwarders { 8.8.8.8 port 853 tls tls-forwarder; 8.8.4.4 port 853 tls tls-forwarder; }; ... }; ... 動作確認 tcpdumpを使って確認する。以下は Google DNS が動いている様子を確認するために、8.8.8.8 の IP のホストの 853 番にアクセスしているか確認する例である。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 まだ書いていない。 関連のある記事 Linux PC をルータ化する 使った画像とか File:Tux.svg - Wikimedia Commons (lewing@isc.tamu.edu Larry Ewing and The GIMP, CC0, via Wikimedia Commons) https://commons.wikimedia.org/wiki/File:Tux.svg (2026年2月26日) Windows 7(Vista) デフォルトのアイコン ルーター PCのアイコン Pi-hole – Network-wide Ad Blocking のロゴ https://pi-hole.net/ (2026年2月26日) 参考にしたサイトとか Pi-hole – Network-wide Ad Blocking https://pi-hole.net/ (2026年2月26日)

この記事を作った動機 私が使っている家庭用ルータの挙動が怪しく、時々特定 IP にアクセスできなくなったり、NAT 越えして VPN 接続する際に接続ができなかったりするときがあるなど、安定性に欠けることがあることが分かった。 そこで、使っていないミニ PC に Linux 環境をインストールし、そこで何かしら設定をすれば、ルータ化できるのではないかという話が、Gemini にいろいろ投げつけると出てきたので、実際にそれができるのか検証も兼ねて、自分で設定し試してみた。 そもそも私自身がネットワークについて授業でレポートを作るためなど、単位を取るために軽く触った程度で、実際に自分で使うために運用して体験してみたり、試す実戦経験に疎いところがある。その点も兼ねて今回実際に検証してみて、難しいと思うことに関しては自分なりにノートを取ってみることにしたというのが、この記事を書いた動機である。 今回の設定がうまくいかない場合、再起動後にルータとして機能しない に書いているように、nftables自体がFirewalldの動作に干渉しているかもしれないので確認する。 設定のまとめ 今回の話のネットワーク構成の前提 いきなり本番環境で動かすのはリスクが高すぎるので、既存の家庭用ルータが形成するLANをWANとして見立てて、そこにぶら下げるようにして今回ルータ化するPCを配置し、実際に動作するか検証する形にした。 設定の全体像 sudo firewall-cmd --list-all --zone=LAN; sudo firewall-cmd --list-all --zone=WAN # LAN (active) # target: ACCEPT # ingress-priority: 0 # egress-priority: 0 # icmp-block-inversion: no # interfaces: [LAN側のインターフェース名] # sources: # services: mdns ssh # ports: 3389/tcp 3389/udp # protocols: # forward: yes # masquerade: no # forward-ports: # source-ports: # icmp-blocks: # rich rules: # WAN (active) # target: DROP # ingress-priority: 0 # egress-priority: 0 # icmp-block-inversion: no # interfaces: [WAN側のインターフェース名] # sources: # services: # ports: # protocols: # forward: no # masquerade: yes # forward-ports: # source-ports: # icmp-blocks: # rich rules: sudo sysctl net.ipv4.ip_forward # net.ipv4.ip_forward = 1 ip a # 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 # link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 # inet 127.0.0.1/8 scope host lo # valid_lft forever preferred_lft forever # inet6 ::1/128 scope host noprefixroute # valid_lft forever preferred_lft forever # # 2: [LAN側のインターフェース名]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 # link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff # inet 192.168.0.3/24 scope global [LAN側のインターフェース名] # valid_lft forever preferred_lft forever # inet6 fe80::725a:fff:fe3f:8c93/64 scope link proto kernel_ll # valid_lft forever preferred_lft forever # ... # 4: [WAN側のインターフェース名]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default # qlen 1000 # link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff # inet 192.168.1.19/24 brd 192.168.1.255 scope global [WAN側のインターフェース名] # valid_lft forever preferred_lft forever # inet6 fe80::3695:dbff:fe2b:1a6d/64 scope link proto kernel_ll # valid_lft forever preferred_lft forever インストールするパッケージ yay -S firewalld net-tools dhclient 具体的なコマンド操作 # 起動時にfirewalldが起動するようにする sudo systemctl enable --now firewalld # すでに有効化していたり、一時的に立ち上げた状態にしたい場合 # sudo systemctl start firewalld # NetworkManagerは手動でfirewalldに設定した項目を上書きする可能性があるので使わない # sudo systemctl disable NetworkManager # public ゾーンに紐づけられているインターフェースを確認し引きはがす sudo firewall-cmd --list-all sudo firewall-cmd --remove-interface=[publicに紐づけられているインターフェース名] --permanent # 新しいゾーン LAN と WAN を作成し、 # LAN側にしてスイッチに接続するインターフェースと、WAN側にして上流の外部ネットワークに接続するインターフェースを紐づける sudo firewall-cmd --new-zone=LAN --permanent sudo firewall-cmd --new-zone=WAN --permanent sudo firewall-cmd --zone=LAN --add-interface=[LAN側のインターフェース名] --permanent sudo firewall-cmd --zone=WAN --add-interface=[WAN側のインターフェース名] --permanent # 各ゾーンのパケットの扱いを設定 sudo firewall-cmd --zone=LAN --set-target=ACCEPT --permanent sudo firewall-cmd --zone=WAN --set-target=DROP --permanent # LANゾーンにおいて転送、WANゾーンにおいてマスカレード設定の有効化 firewall-cmd --zone=LAN --add-forward --permanent firewall-cmd --zone=WAN --add-masquerade --permanent # 設定を反映 sudo systemctl restart firewalld Systemd で起動時に実行する内容 (root,initRouter.sh) ※ 保存してスクリプトを作成し終わったら、chmod +x [filename]で実行権限を付与することを忘れないこと。 ...

この記事を作った動機 LinuxクライアントからWindows側にRDP接続などをするとき、いちいちIPアドレスを直接入力しているのは気持ち悪いと思っていた。今まではそれでいいやと放置していたが、最近いい加減どうにかしようということで、具体的な解決を試みようと思って、案の定手間取ったので記録する。 具体的には、mDNSを使って、Linuxクライアント側から、WindowsクライアントのプライベートIPアドレスを割り出したいということをしていた。基本的には以下のポイントがあった。 ファイアウォールの設定で、mDNSを受け付けるようになっているか？ Linuxクライアントに必要なパッケージがインストールされ、必要なデーモンが動いているか？ 接続先対象としてのWindows側のホスト名は間違っていないか？ Linux側から名前解決を試みるとき、.localのTLDをつけ忘れていないか？ 環境 前提としては、個人的なLAN内での利用を想定している。今回は、パブリックネットワーク向けのセキュリティー重視という観点では書いていない。 また重要な前提として、接続先と接続元は、同じプライベートネットワークに属していることとする。 接続先 (Windows) Windows 11 24H2 を使っている 接続元 (Linux) NetworkManger を使っている systemd-resolved を使っていない、無効にしている GNOME 環境 arch linux 環境 仮定 今回は説明のために以下の仮定をしている。Linux側に関しては、/etc/hostnameにすでに適切なホスト名が設定されているという前提である。 Windows側 ホスト名: WinHost IPアドレス 192.168.1.33 Linux側 ホスト名: LinuxHost IPアドレス 192.168.1.55 設定手順 Windows側 (接続される側、mDNSで名前解決される側) ファイアウォールの設定を確認する 今回はmDNSだけでなく、そもそも接続されているか確認するために、pingも通るように設定する。 ネットワーク探索が無効になっていないか確認する Linux側 (接続を試みる側、mDNSで名前解決をしようとする側) パッケージのインストール yay -S avahi nss-mdns # pacman -S avahi nss-mdns デーモンの有効化 sudo systemctl enable --now avahi-daemon.service /etc/nsswitch.confを設定する 以下はAvahi - ArchWikiを参考に設定した一部の例である。今回は IPv4 を対象として、mdns4_minimalを指定した。試してはいないが、mdns_minimal、mdns、mdns6_minimal(IPv6)としても、Avahi - ArchWikiを見る限り設定できる模様である。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近 Microsoft 社のネイティブの RDP クライアントや MS Store で配布されている純正 RDP クライアントや Windows に標準搭載されている RDP クライアントプログラムに不満があるというのがあった。 ちょっと前までは、Windows 環境では標準搭載されている RDP クライアントプログラムを使っていた。Windows に対してのRDP接続では自動的にクライアントとRDP接続先が、画面の解像度やスケーリング情報をやり取りしていたため 問題なしとしていたし、 RDP 接続先としての Linux 環境側も X11 の設定を使い、手動で解像度を変えることで対応していて、それでいったん良しとしていた。 しかし、Linux 環境に RDP 接続する場合において、GNOME 49 の本格的な X11 環境が廃止があり、簡単に画面の解像度を変更できなくなったため、そうとは行かなくなった。 それで、私の環境でも NVIDIA 製 GPU を使っていても、Wayland にしないと、更新後 gdm サービスが立ち上がらないということになってしまったため、NVIDIA が提供する X11 上で動作する設定画面が使えなくなった。EDID という、ディスプレイの情報をローレベルで強引に書き換えるなどしなければ、自由な解像度で RDP 接続先としての Linux 環境が使えなくなってしまった。 こうして、いろんな我慢が積み重なり、そろそろいい加減何とかしようと思って、 Guacamole を見つけ、試していたというのがあった。私の今の理解だと、Guacamole とは、apache から出ている Tomcat 上で動作し、ブラウザでアクセスすることで使うことができる RDP VNC その他もろもろのクライアントとして使うことができる Web アプリという認識である。 とりあえず現状ではすべてについて記録を一気にとるのは現実的ではなかったので、とりあえず、書きやすいところや、記録に残しておきたいところを優先的に先に記録を残してみることにした。 Guacamoleが動作している様子 ログイン画面 接続先選択画面 動いている様子 ...

この記事を作った動機 なんか、キャリアネットワークをデザリングを経由して使って、さらにVPN接続を介した通信のうち、HTTPとSSHだけが繋がらないということがあった。 それで対策としてMTUを小さく設定することをしたのでそのことを記録するだけ。 ちなみになぜMTUが大きすぎるとだめなのかわかっていないが、多分大きすぎるサイズのパケットはなんとなくどこかで落とされている気がする。 VPNや多段NAT構成だとルーティングされているうちに、ヘッダが積み重なって、ネットワークのパケットのサイズが大きくなりすぎたりするのかもしれない。 ネットワークの構成 サーバーやLAN内のルータ マンションのNAT キャリアネットワーク スマホ（デザリング） PCとか 状況 A -> キャリアネットワークのときで、直接マンションのNATを超えたとき B -> キャリアネットワークのときで、VPSなどの固定IPを持ったサーバーを経由したとき C -> 光回線などの固定回線で、直接マンションのNATを超えたときと、VPSなどの固定IPを持ったサーバーを経由したときの両方について含まれる 状況別の表 A B C Ping ✅ OK ✅ OK ✅ OK SMB(ファイル共有) ✅ OK 確かめていない ✅ OK DNS ✅ OK ✅ OK ✅ OK SSH ❌ Failed ✅ OK ✅ OK HTTP(HTTPS) ❌ Failed ❌ Failed ✅ OK MTU設定方法(要管理者権限) デフォルトで設定されているMTUのサイズ 1500 今回うまくいったMTUのサイズ 1000 一時的な設定(とりあえずすぐ設定したいとき) ip コマンドを使う sudo ip link set dev [ネットワークアダプタ名] mtu [設定したいMTUサイズ] ip コマンドを使う例 # 例 # ip a # ... # 4: vpn_vpnhome: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 # link/ether 5e:76:29:d3:1b:85 brd ff:ff:ff:ff:ff:ff # inet 192.168.1.203/24 scope global vpn_vpnhome # valid_lft forever preferred_lft forever # sudo ip link set dev vpn_vpnhome mtu 1000 # ip a # ... # 4: vpn_vpnhome: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1000 qdisc fq_codel state UNKNOWN group default qlen 1000 # link/ether 5e:76:29:d3:1b:85 brd ff:ff:ff:ff:ff:ff # inet 192.168.1.203/24 scope global vpn_vpnhome # valid_lft forever preferred_lft forever 永続化設定(networkmanagerを使っているとき) sudo nmcli connection modify [ネットワークアダプタ名] 802-3-ethernet.mtu [設定したいMTUサイズ] # vpn_vpnhome の MTU サイズを 1000 に変更 # sudo nmcli connection modify vpn_vpnhome 802-3-ethernet.mtu 1000 追記 2025年8月1日 なんか何となくブックマークをあさっていたら、TU，MSS の計算と最適化の便利な手段をまとめるというサイトにたどり着いた。それで、さらにリンクをたどって、Visual packet size calculator — Daniil Baturinというところに行くと、こんな記述が目に止まった。 ...