「WSL2」の記事 - Crieit

【Ubuntu】apt updateでKey is stored in legacy trusted.gpg keyringと注意されたので対応する

2023-05-07T08:47:15+09:00

こんにちは、しきゆらです。
今回は公式のドキュメントを見ながら対応したのに、apt updateで怒られるようになったので
なぜなのか調べつつ、対応方法を見つけて対応したのでメモしておきます。

何が起きているのか

apt-keyはなぜ廃止予定となったのか
 Fully deprecate apt-key, schedule removal for Q2/2022 (ee284d59) · Commits · APT Developers / apt · GitLab

apt-keyコマンドがだいぶ前の2020年8月ころから廃止予定で、2022年Q2に廃止となっていたようです。
手元の環境はWSL2上のUbuntu 22.10でしたが、まだ残っているようでした。
今後はなくなるんでしょう。

セキュリティ上の懸念点からくるもので、簡単にまとめると次の2点が理由です。

apt-key addは単一ファイル（/etc/apt/trusted.gpg）に鍵を追加していくため、複数のリスクの異なるリポジトリの鍵を同じ権限で管理しなくてはならない。

リポジトリ鍵として追加した鍵は、すべてのリポジトリに対して適用される。

引用元: https://gihyo.jp/admin/serial/01/ubuntu-recipe/0675

ということで、リポジトリごとにリスクが異なるカギを全体で使うのよくいないよね、ということでこれをやめた、という感じなのかなと。
やめたはいいが、この記事時点では代替となるものが用意されていないようです。今後は、各リポジトリで利用するカギを/usr/share/keyrings/配下に設置して個別に指定する運用が良いだろう、として締めています。

対応方法

大きく分けると以下の通り。

既存のカギを削除する
別途カギを取得し設定しなおす
リポジトリとカギを紐づける

1. 既存のカギを削除する

$ apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg.d/apt.postgresql.org.gpg # <= これを削除する
---------------------------------------------
pub   rsa4096 2011-10-13 [SC]
      B97B 0AFC AA1A 47F0 44F2  44A0 7FCC 7D46 ACCC 4CF8
uid           [ unknown] PostgreSQL Debian Repository
...

# 鍵の削除はfinger printの最後の8文字のようです
$ sudo apt-key del ACCC4CF8
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

# 消えたことを確認
$ apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
...

2. 別途カギを取得し設定しなおす

カギについては、ここに記載されているので取得して入れなおします。

PostgreSQL: Linux downloads (Ubuntu)

# カギの取得
$ wget 

# カギをgpgコマンドを使って変換
$ gpg --no-default-keyring -o postgresql-keyring.gpg --dearmor ACCC4CF8.asc

# カギを確認
$ file postgres-keyring.gpg
postgres-keyring.gpg: GPG keybox database version 1 ...

# 変換したカギを/usr/share/keyrings/へ設置する
# 手元ではフォルダがなかったので手動で作成
$ sudo mkdir -p /usr/share/keyrings
$ sudo cp postgres-keyring.gpg /usr/local/share/keyrings

3. リポジトリとカギを紐づける

リポジトリは/etc/apt/sources.list.d/pgdg.listに作成しているので、このファイルを以下のように変更。

# deb [signed-by=/path/to/gpg_key] URLの形式でカギの場所を記載
deb [signed-by=/usr/local/share/keyrings/postgresql-keyring.gpg]  kinetic-pgdg main

これにて対応完了です。
Warningが出ないことを確認しましょう。

# warningが出ないことを確認
$ sudo apt update
...
Hit:7  kinetic-pgdg InRelease

まとめ

今回は、apt-keyコマンドが廃止となっているために、ドキュメント通りに対応してもWarningが出てしまっていたので、諸々調べつつ対応してみました。そもそもの廃止から知らなかったので勉強になりました。

なお、DockerやGithub CLIでは /etc/apt/keyrings 配下に設置しているようです。
Install Docker Engine on Ubuntu | Docker Documentation
Linux installation instructions recommend storing GPG keyring in the wrong location · Issue #5122 · cli/cli · GitHub

管理をユーザ側でやる、という形であれば1か所にまとめたほうが良いのでどこか1か所を決めて、リポジトリ追加時にそこへ追加していく方法をとったほうが良いかもしれません。
DebianのWikiにも /etc/apt/keyrings 配下に設置しよう、となっているのでこっちに合わせたほうが良いかもしれません。
DebianRepository/UseThirdParty - Debian Wiki

今回はここまで。
おわり

【WSL2】systemdがサポートされたようなので試してみた

2022-11-19T08:32:00+09:00

ここ数年はWindowsの環境をクリーンインストールするたびにWSL2の環境を作り直し、その度にgenieを使ってsystemdをPID 1 にするための方法をメモしてきました。
【WSL2】systemctlが動かない問題をきちんと解決する
 【WSL2】Ubuntu20.04でPID1をSystemdにする
 【WSL2/Ubuntu】systemdをPID1で動かす 2021年3月版

しかし、気が付いたらWSL自体がsystemdをサポートしたようなので、WSLだけでsystemdをPID 1にしてみたのでメモしておきます。

詳しいことは公式ブログを参照ください。
Systemd support is now available in WSL!

設定手順

公式ブログによると、WSLのバージョンが0.67.6以上で使えるとのこと。
なお、手元のWSLのバージョンを確認するとすでに1.0になっていたのでだいぶ前から使えたんだなぁともっと早く気づきたかった気持ちでいっぱいです。
確認するためのコマンドは以下の通り。

powershell > wsl --version
WSL バージョン: 1.0.0.0
カーネル バージョン: 5.15.74.2
WSLg バージョン: 1.0.47
MSRDC バージョン: 1.2.3575
Direct3D バージョン: 1.606.4
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windowsバージョン: 10.0.22621.819

なお、WSLの更新もwslコマンドでできるようになったようなので、バージョンが古い場合は以下のコマンドで更新すればよい。

powershell > wsl --update

次に、WSL環境にwsl.confというファイルを作成し、以下を書き込む。

wsl(Ubuntu) > sudo emacs /etc/wsl.conf
# 以下を追記
[boot]
systemd=true

書き込んだらWSL環境を再起動。
これにて準備完了です。

powershell > wsl --shutdown

この後、WSL環境に入りsystemctlを動かしてみます。
以下のようにエラーが起きずにつらつら表示されたらOK。

wsl(Ubuntu) > systemctl
UNIT                                                                                                                                                                      LOAD   ACTIVE SUB       DESCRIPTION                                            >
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-0fd20160\x2d7ac7\x2d4158\x2d9e38\x2d8685d280c3a6-net-eth0.device                                                 loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:>
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-ba31a026\x2d5b46\x2d4a8d\x2da6dc\x2df00324cf1e90-pci5b46:00-5b46:00:00.0-virtio0-virtio\x2dports-vport0p0.device loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:>
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:0-block-sda.device                      loaded active plugged   Virtual_Disk
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:1-block-sdb.device                      loaded active plugged   Virtual_Disk
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:2-block-sdc.device                      loaded active plugged   Virtual_Disk
sys-devices-platform-serial8250-tty-ttyS0.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS0
sys-devices-platform-serial8250-tty-ttyS1.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS1
sys-devices-platform-serial8250-tty-ttyS2.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS2
sys-devices-platform-serial8250-tty-ttyS3.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS3
  ...

まとめ

今回は、WSLがsystemdをサポートしたということで設定してみました。
今後はgenieを入れずともWSLだけでsystemdを使えるので、より手軽に環境を使えるようになりました。

今回は、ここまで。

おわり

【WSL2/clasp】WSL2上からclasp pushするとError: Looks like you are offline.と怒られる問題を回避する

2022-06-12T20:06:21+09:00

こんにちは、しきゆらです。
今回は、タイトルの通りWSL2からclaspを使おうとするとofflineと怒られる問題が起こったのでこれを回避する方法をメモしておきます。

気が付くとWSL2からclasp pushをしようとすると、以下のようなエラーが出てしまってプッシュできない状態になっていました。
よくわからないですが、たまにプッシュできたりするので何が悪いのかよくわかりません。
WSLをインストールしなおしたりしても解決しませんでした。
また、調べてもそれっぽい記事が出てこないので「おま環」ぽい気がしています。

さて、これではWSL内で書いたGASをプッシュできません。
これを回避する方法をメモしておきます。

回避方法は単純で、Docker上からclasp pushをするだけ。
調べてみると、結構DockerでGASを管理したい人がいるようで、情報がそこそこありました。
ということで、プロジェクト諸々をDocker上にマウントしてコマンド実行できるようにしていきます。
なお、ここではGASをTypeScriptで書いたのちWebpackでビルドしたものをclaspコマンドでプッシュする流れです。
参考: https://qiita.com/rei-ta/items/61b3fde6a069b77d335d

Dockerの準備

まずは、Dockerの準備をしましょう。
Dockerのインストールは、WSLのホストであるWindows側に行えば良いようです。
Dockerfileを以下のように作成します。

FROM node:slim
RUN npm install @google/clasp -g

claspを実行する環境が必要なので、イメージとしてnodeを使います。
サイズが小さいほうが何かと便利なのでnode:slimを使っていますが、nodeが動けばなんでもよいかと思います。
また、claspを使えるようにインストールしておきます。

続いて、docker-compose.ymlを作成します。

version: "3"
services:
  clasp:
    build: .
    tty: true
    stdin_open: true
    volumes:
      - "/home/:/usr/src"
    working_dir: /usr/src/${user}

clasp loginしたのち、認証情報がhome直下にできるため/home/${user}をマウントしています。
これで準備は完了。

offlineと怒られる問題を回避する

Dockerを立ち上げていきます。
docker-compose run --rm -u ${id -u $usr} clasp /bin/bash
シェルが立ち上がったら以下のコマンドでログインします。
clasp login --no-localhost
これにて準備は完了です。
あとは、コードを書いてWebapckでビルドしたものをclasp pushしましょう。

node@ded2ca180394:$ clasp push
└─ /usr/src/path/to/project/appsscript.json
└─ /usr/src/path/to/project/bundle.js
Pushed 2 files.

問題なくプッシュできていますね。
これにて回避完了です。

まとめ

手元の環境では、これにてofflineと怒られる問題を回避できました。
ちょっと手間ですが、ひとまずは回避できました。
同じような問題が起こっている場合は試して見てください。

今回は、ここまで。
おしまい

WSL2（Arch）でsystemctlを使用できるようにするために行ったこと

2022-03-13T18:31:26+09:00

環境：
WSL＝WSL2
ディストリビューション＝Arch

TeraTarmでSSH接続をしたかったけれど、デフォルトではsystemctlが実行できないようだったので、設定を行った。

【使用したもの】
Distrod

【設定方法】
動いていたArchに入れたので、下記のページのOption2を実行
Option 2: Make your Current Distro Run Systemd

★実行内容
手順１：記載されている通りに実施
手順２：下記のほうを実行
/opt/distrod/bin/distrod enable
手順3は実行してもエラーとなっただけだった。

【実行後】
systemctl が利用できるようになっていて、daemonの再起動などもできるようになった。
便利。

VSCode＋WSL(ssh接続)＋CMake＋GoogleTestでC++プログラミング環境を構築

2021-04-10T00:26:58+09:00

以前の記事
VSCode＋WSL＋CMake＋GoogleTestでC++プログラミング環境を構築
で作った環境、なーーんかスマートじゃないなーと思ってたんですが
WSLにssh接続で入るようにしたらしっくりきたので、改めて記事を書きました。
①以外は以前の記事とほぼ同じですが、この記事だけ読んでできるようにしたかったので、ご了承ください。
Windows10のVersionは1803以降でお願いします。それより前だと、WSLのウインドウを開いておいてsshデーモンも起動して・・・とか毎回やらないとssh接続できないらしいです。

①VSCode＆WSLでC/C++を使えるようにする

①-1 WSLを使えるようにする

画面左下の窓アイコンを右クリック→Windows Powershell (管理者)を選択。
出てきたウインドウに以下を打ち込んでしばし待ち、指示が出たらPC再起動します。

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

①-2 ubuntuをインストール

Microsoft Storeを開いてubuntuと入力し出てきたUbuntu 18.04 LTSをインストール＆起動します。

①-3 ubuntu初期設定、gcc、opensshインストール

インストール完了したら、ユーザー名パスワードを設定後、以下のコマンドで最新に更新、

$ sudo apt update
$ sudo apt upgrade

次にgccなどをインストール、

sudo apt install build-essential

最後にopensshを入れなおします。

sudo apt-get purge openssh-server
sudo apt-get install openssh-server

入れなおす事で、パスワード入力を不要にしたりとかRSA鍵を作ったりとか勝手にやってくれるっぽいです。

①-4 WindowsのVSCodeインストール

vscodeでググった一番上のリンクから「今すぐダウンロード」してインストールしてください。

①-5 VSCodeに拡張機能をインストールしてWSLに接続

「Remote Development」で検索して出てきたやつをインストール

すると左側にモニタみたいなアイコンが出るのでクリック

表示されたubuntu18.04を選択して右のウインドウに+がついたようなアイコンをクリックでWSLに接続し、VSCode(WSL側)のウインドウがもう一つ表示されます。以降はVSCode起動後この2ポチでWSL環境が開きます。前より簡単ですね。

①-6 VSCode(WSL側)に拡張機能をインストール

①-5の最後で開いたWSL側のVSCodeに以下の拡張機能をインストール
・C/C++
・他日本語などお好みで
ここまでやればC/C++のコーディングとビルドはできるようになります。

②cmakeのインストール

以降の操作は①-3で使ってたウインドウでもできますが、VSCode(WSL側)のターミナル(bash)でも行えます。コピペとかしやすいので後者をおすすめします。

sudo apt-get install cmake

おわり

③GoogleTestのインストール

インストール方法をググると、tar.gzダウンロードしてきてせこせこ解凍したり、makeしたあと生成物をなぜか手動でコピーしてたりと色んなインストール方法が出てきますが、苦労なくできるのは以下です。

cd
git clone https://github.com/google/googletest.git
cd googletest
mkdir build
cd build
cmake ..
sudo make
sudo make install

④C++のコード書く

書いてください。

⑤GoogleTest使ってみたソースのCMakeLists.txt

cmake_minimum_required(VERSION 3.0)
project("hello_gtest")
add_executable(hello_gtest main.cpp)
target_link_libraries(hello_gtest
  PRIVATE
    gtest
    gmock
    pthread)

①②③あたりを上に書いた通りにやっておけば、includepathの指定とか特に何も書かないでも、上のような内容でビルド＆実行できると思います。
お疲れさまでした。次の⑥は読まなくていいです。

⑥■■■■■■■■■■

前の記事で作った環境、正直なんか使いにくくてその後二度と自宅でC/C++打たなかったんですが、バチが当たってHDDがぶっ壊れたので、SSDに換装後、今回環境を作り直すにあたって、もっと楽にできるようにしてみました。

VPN に繋ぐと WSL2 や Hyper-V VM でネットワークに繋がらなくなる問題を解消する

2021-01-27T09:33:58+09:00

OpenVPN や Cisco AnyConnect, GlobalProtect 等といった VPN に接続した際、 Hyper-V 仮想マシン内からや、 WSL2 のディストリビューション内、 Windows Sandbox 内、 WSL2 ベースの Docker コンテナ内等々、 Hyper-V 系の技術を使った仮想環境から、 PC 外のネットワークにアクセスしようとすると、以下のようなエラーが発生して失敗する。

$ # curl 利用時の例
curl: (6) Could not resolve host: example.com
curl: (5) Could not resolve proxy: proxy.example.com

$ # apt で更新しようとした場合の例
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'proxy.example.com'

エラーの内容からわかるとおり、アクセス先やプロキシーのドメイン名を DNS で解決できなくなっている。

このような問題が発生することは以前から知っていたのだが、このご時世で VPN 使うことが増えてきて、いい加減鬱陶しくなってきたので、なんとかしようと思う。

解決方法

とりあえず、まずは解決方法から。

以前は AnyConnect でもこの方法が使えたはずなのだが、どうやら対策されて打つ手なしになってしまった模様。
今のところ、以下の方法で回避の確認が取れているのは、 GlobalProtect のみだ。

WSL2 の場合は何らかの WSL2 を使ったディストリビューションを立ち上げる。
- WSL 2 based engine が有効になった Docker Desktop を起動するだけでも OK。
- WSL2 を使っていないなら、何もする必要はない。
VPN を接続状態にする。
管理者権限で Windows PowerShell を立ち上げ、以下のコードを実行する。 (GlobalProtect の例)
```
$targetIfName = 'PANGP Virtual Ethernet Adapter';
# define function
function Get-NetworkAddress {
    param([Parameter(Mandatory, ValueFromPipelineByPropertyName)][string]$IPAddress, [Parameter(Mandatory, ValueFromPipelineByPropertyName)][int]$PrefixLength);
    process {
        $bitNwAddr = [ipaddress]::Parse($IPAddress).Address -band [uint64][BitConverter]::ToUInt32([System.Linq.Enumerable]::Reverse([BitConverter]::GetBytes([uint32](0xFFFFFFFFL -shl (32 - $PrefixLength) -band 0xFFFFFFFFL))), 0);
        [pscustomobject]@{
            Addr = $IPAddress;
            Prfx = $PrefixLength;
            NwAddr = [ipaddress]::new($bitNwAddr).IPAddressToString + '/' + $PrefixLength;
        };
    }
}
# extend route metric
$targetAddresses = Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -Match 'Hyper-V Virtual Ethernet Adapter' | Get-NetIPAddress -AddressFamily IPv4 | Get-NetworkAddress;
$targetIfs = Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -Match $targetIfName;
$targetIfs | Set-NetIPInterface -InterfaceMetric 2;
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $_.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $_.Prfx).NwAddr } } | Set-NetRoute -RouteMetric 6000;
```
- GlobalProtect 以外の場合は、上記コード一行目の 'PANGP Virtual Ethernet Adapter' のところを VPN ソリューションのネットワーク接続アダプタ名に書き換える。
  具体的には、 Win+R で ncpa.cpl を実行して「ネットワーク接続」を開き、該当する VPN の接続のプロパティを開いて、 "接続の方法" のところに書かれた名前 (の一部) を指定する。
  - OpenVPN なら TAP-Windows Adapter とか、 AnyConnect なら Cisco AnyConnect とか。環境によっても違うかも。
- 管理者権限の PowerShell は、スタートボタンを右クリックで簡単に立ち上げられる。
- 1回の実行で成功しない場合、 上記コードの最後の行 を、ルートメトリックが書き換わるまで何度もしつこく実行する。
  - ルートメトリックが書き換わっていない状態の例:
    
```text/plain
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $.Prfx).NwAddr } }

ifIndex DestinationPrefix NextHop RouteMetric ifMetric
------- ----------------- ------- ----------- --------
36 172.30.175.255/32 0.0.0.0 0 0
36 172.30.160.1/32 0.0.0.0 0 0
36 172.30.160.0/20 0.0.0.0 0 0
20 172.18.31.255/32 0.0.0.0 0 0
20 172.18.16.1/32 0.0.0.0 0 0
20 172.18.16.0/20 0.0.0.0 0 0
```
  - ルートメトリックの書き換えに成功した例:
    
```text/plain
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $.Prfx).NwAddr } }

ifIndex DestinationPrefix NextHop RouteMetric ifMetric
------- ----------------- ------- ----------- --------
36 172.30.175.255/32 0.0.0.0 6000 0
36 172.30.160.1/32 0.0.0.0 6000 0
36 172.30.160.0/20 0.0.0.0 6000 0
20 172.18.31.255/32 0.0.0.0 6000 0
20 172.18.16.1/32 0.0.0.0 6000 0
20 172.18.16.0/20 0.0.0.0 6000 0
```
上記を、 PC を再起動したり、 VPN を接続しなおす度に、毎回実行する。

解説

上記のコードは、 VPN プロバイダがホスト PC に作成しているルーティングの設定のうち、 Hyper-V や WSL に関係する宛先ものだけ、ルーティングのメトリックをめっちゃ長くしている。

Hyper-V や WSL のネットワークの仕組みに簡単に触れながら、もう少し細かく説明していこう。

Hyper-V と WSL2 の NAT

まずそもそもの前提として、 ホストPC と WSL2 の仮想環境で異なる IPアドレスを持っている。
利便性のため、 WSL2 の localhost のリッスンが、ホスト PC の localhost へ転送されているなど、 IPアドレスが異なることをあまり意識せずすむような仕組みにはなっているけれども。

そしてその WSL2 や、 Hyper-V の VM では、 PC の外と通信する際に NAT を経由して通信を行う仕組みがメインとなる。

このとき、 Hyper-V や WSL2 のバックエンドとなる Hyper-V ハイパーバイザーは、ホスト PC 上に仮想 NIC を作成する。
そしてその仮想 NIC に、 WinNAT と呼ばれる機能を割り当て、更に WSL2 向けには DNS の機能も割り当てて、ホスト PC の外との通信の中継を担わせるようになっている。

これら、仮想 NIC や、 WSL2 に自動で割り当てられる IP アドレスは、ホスト PC と被らない適当なプライベート IP アドレスが割り当てられる。

なお、 やっかいなことに、この割り当てられた IP アドレスは、起動する度に毎回異なる。

VPN 側の動作

一方のソフトウェア VPN では、 VPN の有効化と同時に、ホスト PC のルーティングを片っ端から書き換えている。

具体的には、 VPN の仮想 NIC に対して短いメトリックとなるよう、ルーティングを書き加える。
それによって、全ての通信が VPN トンネルを通るようになっているのだ。

そして悲劇が起こる

その結果、どうなるか。

ホスト PC からゲスト VM (あるいは WSL ディストロ) のプライベート IPアドレスへ通信しようとすると、 VPN のトンネリング側にルーティングされてしまう。

例えば、 WSL2 からホストPC へ DNS の問い合わせ (クエリ) を受けると、そのレスポンスが明後日の方向にルーティングされてしまう。
これが、 ゲスト側で DNS による名前解決ができなくなる原因だ。

この問題を回避するため、前述のスクリプトでは、ルーティングテーブルを書き換えて、ゲスト VM のアドレスに対して、 VPN の仮想NIC のメトリックを長くすることで、 VPN にルーティングされないようにしているわけだ。

本当は、 VPN へのルーティングを消してしまいたいところなのだが、ルーティングを消しても、 VPN クライアントが即座にルーティングを復活させてしまうため、メトリックを長くするだけにとどめている。

なお、 GlobalProtect でも、書き換えたメトリックを戻される対策がされたようだが、インターフェースメトリックを書き換えたり、短期間に何度も書き換え直したりすると、メトリックを戻すことを諦めてくれる。
このため、上記のようなコードになっている。

WSL2 , problem with network connection when VPN used (PulseSecure) · Issue #5068 · microsoft/WSL | GitHub
ちなみに、上記の Issue ではもっと単純に、 WSL2 へのメトリックは 1 にして、全ての VPN 関係のルーティングのメトリックを 4000 くらいに延ばすワークアラウンドが紹介されている。
しかしそれだと、本来 VPN 経由にしなくてはならない通信までもが VPN 通らなくなったりする場合があって、 VPN を使わせるポリシー上マズい。
このため、上述のように、必要なネットワークアドレスだけに絞ってメトリックを書き換えている。

別解

Microsoft Docs 上の WSL のトラブルシューティングでは、 WSL の /etc/resolv.conf の DNS を、ホストPC の WinNAT ではなく VPN のトンネリング先のネットワークの DNS に書き換える方法も掲載されている。

……が、これを行うと、ゲスト側の DNS の名前解決こそできるようになるものの、依然ホストPC からゲストOS へのパケットが届かない問題は解消されない。
このため、ゲストで立てたサーバーに、ブラウザでアクセスしたり、 ssh 等でログインしたりと言ったことはできないままだ。

更に、イントラネット内で別途 DNS を運用していた場合、イントラネット内の名前解決ができなくなる問題もある。

このため、この DNS を書き換える方法は、望ましい解決方法とは言えない。

改訂履歴

2023-02-22:
- コードの一部でエラーが発生していた部分を修正。
2023-02-14:
- 各社のメトリック書き換え対策に対し、 GlobalProtect 向けにコードを変更し、 AnyConnect 向けには打つ手なしとなったことを追記。
2021-04-04:
- Windows Sandbox などでも問題となる旨追記
- いくつかの VPN ソフトについての設定例を追記
- Microsoft Docs 記載の改善方法について追記
2021-01-28:
- 仮想ネットワーク上に DHCP は存在しないのに、 DHCP の存在がすると誤記があったので修正。
- スクリプトで Hyper-V の仮想スイッチをさかす際に、 NIC 名ではなくて、ネットワークアダプタの接続名で探すように変更。

VSCode＋WSL＋CMake＋GoogleTestでC++プログラミング環境を構築

2020-11-26T18:56:31+09:00

2021/4/9追記
WSLにssh接続で入った方が色々変な事気にしないでいいんじゃない？
ということで、アップデートした記事を書きました。
こちらになります。
VSCode＋WSL(ssh接続)＋CMake＋GoogleTestでC++プログラミング環境を構築

以下はアップデート前の記事です。

Windows10で掲題の環境を作成したのでメモ
サクッとやりたかった
次の機会にはサクッとできるはず

①まずは↓を見ながらVSCode＆WSLでC/C++を使えるようにする

WSL+VSCODEで競技プログラミング環境構築

途中、

拡張機能がインストールできたら上部のメニューから「ファイル」->「フォルダーを開く」
から好きなフォルダーを開いてください。

と書かれているが、自分は好きなフォルダーじゃなくて、
WSLのrootfsディレクトリ以下を指定した
具体的にはUbuntu18.04なら以下

C:\Users\[ユーザー名]\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs

本当にマイドキュメントとか好きなフォルダにしたら、
gtest.hをincludeするときとかの補完機能がなんかアレとか、CMakelists.txtを書く時に全然アレとか、
とにかく無用な苦労をしたので・・・（だから「競技プログラミング」って書いてあったのかな）

②cmakeのインストール

sudo apt-get install cmake

おわり

③GoogleTestのインストール

cd
git clone https://github.com/google/googletest.git
cd googletest
mkdir build
cd build
cmake ..
sudo make install

ググると色んなインストール方法が出てくるが、自分が苦労なくできたのはこれだけだった
他はヒューマンのエラーが入る余地がありすぎる
特に最後のmake installはmakeだけやって手作業で.aとか.hをコピーしてる記事が多くてなんで？？　ってなった

④C++のコード書く

さすがに省略

⑤GoogleTest使ってみたソースのCMakeLists.txt

cmake_minimum_required(VERSION 3.0)
project("hello_gtest")
add_executable(hello_gtest main.cpp)
target_link_libraries(hello_gtest
  PRIVATE
    gtest
    gmock
    pthread)

①②③あたりを上に書いた通りにやっておけば、includepathの指定とか特に何も書かないで
上の内容でビルド＆実行できると思う
お疲れさまでした。次の⑥は読まなくていいです

⑥■■■■■■■■■■

仕事でどうしてもわかんないとこがあったが職場にいられる時間があまりなく、
しかたない、家でC++環境構築してやってみるか・・男の子なら自宅WindowsPCで
CやC++のコンパイル環境があるべきだよな・・・
と思ってとりかかったら、上記の環境設定だけで終わってしまった

何も考えず仮想PCにlinux入れてssh接続でやる方法ならむしろ確実だったが
「めんどい＆重い＆時間かかる」
というのはわかっていたので、他に軽い方法ないかとググったらMinGWを使う方法がいっぱいでてきた
このMinGWが無駄にした時間のほぼ全て
最初のapt-getに相当する部分でpacmanとか打ち込まされる時点で嫌な予感がして、
騙されたかなと思ってそれでもやってみたら騙された
MinGWってなんで今も存在してるんだろう・・・

WSLはすごい楽でした
ありがとうMicroSoft

Windows WSLのUbuntuにGoogleChromeをインストールする

2020-09-20T19:59:37+09:00

Railsで開発をしていてRspecでChromeDriverでのテストを利用しているためChromeが必要になったのでインストール

sudo apt-get update
# 必要なライブラリのインストール
sudo apt-get install libappindicator1 libappindicator3-1 fonts-liberation

# 最新安定版のDL、インストール
curl -O https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb

# ここでパッケージの依存関係で怒られたので依存関係の解消
sudo apt --fix-broken install

# 再度インストールを試した
sudo dpkg -i google-chrome-stable_current_amd64.deb

# インストールされていることの確認
google-chrome --version

参考

WSL 2 と Desktop Docker の開発環境を整えてみた

2020-08-31T17:17:10+09:00

本来自分はゲーム作りたい系の人なのですが、人生の大河の流れに身を委ねていたらWeb開発に貢献する必要が出たので、某Webシステムの開発に貢献するために、開発環境を整えたいと思います。本記事は、そのための開発環境を整える記録ただの日記です。

Web開発自体は、けっこうしばらくぶりなので（仕事でやっていたのが5年くらい前）、色々わかってないので調べながらになります。

最終的な目標となる環境は Node.js、Express、MongoDB の環境を整えることですが、今回は、とりあえず Docker が使える状態になるところまでやってみます。

自宅メインPCを最近新調していて、開発まわりの環境はほぼ整えていない状態で、ほぼ最初からやっていく感じです。メインPCの OS は Windows 10 Home です。

Windows Subsystem for Linux 2 (WSL 2) を利用するために Windows 10 をバージョンアップ

巷ちまたでは、Web開発する際はローカルの仮想環境上で環境を整えて、その上でWebバックエンドのシステムを動かして動作確認して開発するのが主流のスタイルだと思うので、それに倣ならいたいと思います。

で、Webバックエンド開発をする際、CUI（コマンドラインインターフェース）をよく使いますが、世に多くある技術情報は、Linux 環境が前提であるものが大多数です。Windows のコマンドプロンプトや PowerShell での開発情報は少ないので、できれば Linux 環境で開発したいです。

Windows 10 で使える（いつのバージョンからかは分からないけど）Windows Subsystem for Linux (略して WSL）という機能を用いれば、Windows 環境上に Linux 環境を作ることができるので、これを使います。
で、WSL にはバージョン1とバージョン2があり、どうやらバージョン2から、仮想環境を作る上での利点があるようなので、WSL 2 にしてみたいと思います。

「windows10 wsl2 インストール」でGoogle検索したら、Microsoft の公式の解説ページがあったので、これを見ながら試してみます。

➢ Windows Subsystem for Linux (WSL) を Windows 10 にインストールする | Microsoft Docs

解説ページにある「WSL 2 に更新する」の項目で、以下のような記述がありました。

WSL 2 に更新するには、次の条件を満たす必要があります。

バージョン 2004、ビルド 19041 以上に更新された Windows 10 を実行している。

Windows のバージョンを確認するには Windows ロゴキー + R キーを押します。次に「winver」と入力し、 [OK] を選択します (または、Windows コマンドプロンプトで ver コマンドを入力します)。お使いのビルドが 19041 より前の場合は、最新の Windows バージョンに更新してください。 Windows 更新アシスタントを入手する。

メインPCにインストールされている Windows のバージョンを確認してみたところ、バージョン2004未満だったので、更新しようと思い、「最新の Windows バージョンに更新してください」という文からリンクされている Windows の設定（[設定]→[更新とセキュリティ]→[Windows Update]）から、更新をしてみたけど、バージョン2004まで上がりませんでした。

調べてみると、「Download Windows 10」という Microsoft 公式ページから更新用プログラムをダウンロードしてインストールする必要があるようでした。

➢ Windows10 バージョン2004 ビルド19041に上げてみた - Qiita

このページを参考にして、Windows 10 のバージョンを上げてみたところ、うまくバージョンアップできました。

WSL 2の環境を整える

引き続き、Microsoft の公式ドキュメントに従ってWSL2の環境を整えます。

➢ Windows Subsystem for Linux (WSL) を Windows 10 にインストールする | Microsoft Docs

ドキュメントの「WSL 2 を既定のバージョンとして設定する」の項目にある、wsl --set-default-version 2コマンドを PowerShell で実行しようとしたところ、以下のようなエラーが発生しました。

> wsl --set-default-version 2
エラー: 0x1bc
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

「wsl "set-default-version" "0x1bc"」でGoogle検索してみたら、それっぽいページが見つかりました。

➢ Error 0x1bc when setting wsl default version · Issue #5651 · microsoft/WSL

Github の Microsoft 公式のWSLのリポジトリの issue です。（英語の読解スキルがまだまだ貧弱なので）Google翻訳して読んでいくと、カーネルエラーがどうのこうのって書いてありました。

公式ドキュメントにも、以下のような注意書きがありました。

このメッセージは、コマンド WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel を実行した後に表示されることがあります。リンク (https://aka.ms/wsl2kernel) に従って、WSL 2 で使用する Linux カーネルをコンピューターにインストールするためのドキュメントのこのページから MSI をインストールしてください。カーネルをインストールしたら、コマンドを再度実行すると、メッセージが表示されることなく正常に完了します。

ここで説明されているメッセージが出たわけではないのですが、カーネルがどうのって書いてあって関係しそうなので、ここにあるリンクに従って何かをインストールしてみます。

リンク先はここでした。

➢ WSL 2 Linux カーネルの更新 | Microsoft Docs

カーネル更新のインストールのようです。ここにある「x64 マシン用の最新の WSL2 Linux カーネル更新プログラムパッケージ」をダウンロードしてインストールしてみます。（使用しているメインPCは 64ビット環境です）

「wsl_update_x64.msi」というファイルがダウンロードされたので、インストーラーを実行します。

インストールはすぐに終わりました。

インストールが終わってすぐに、もう1回、PowerShell でwsl --set-default-version 2を実行してみます。

> wsl --set-default-version 2
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

エラーが表示されなくなりました。ふう……😓💦

Ubuntu をインストール

Microsoft 公式ドキュメントの流れに従い、Microsoft Store から Linux ディストリビューションをインストールします。開発に貢献する某システムの環境は Ubuntu で動作しているので、それに合わせて Ubuntu をインストールします。

Windows のアプリ一覧から Ubuntu を起動させ、初期セットアップを行います。

新しい Linxu ディストリビューションのユーザーアカウントの作成とパスワードの設定を行いました。

PoewrShell からwsl --list --verboseを実行して、Linux ディストリビューションに割り当てられている WSL のバージョンを確認します。

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Running         2

WSL 2で動いています。

Windows Terminal にも、Ubuntu が認識されました。

Docker のインストール

5年くらい前に私が仕事でWeb開発をやっていたときに使用していた仮想環境のためのツールが Vagrant だった記憶があります。しかし、昨今の流行は Docker というツールのようなので、それを使ってみたいと思います。（流行情報の追跡だけはちまちましている）

「wsl2 docker」でGoogle検索して、以下のQiitaの記事が出てきたので、これを参考にして作業してみたいと思います。

➢ Windows 10 Home で WSL 2 + Docker を使う - Qiita

タスクマネージャーから確認※できる CPU の Virtualization が Enable になっていないといけない、ということなんですが、今の自分の環境で確認してみたら「仮想化」という様に日本語になっていました。そして、この項目は「有効」となっていたので問題なさそうです。

※タスクマネージャーの起動は Ctrl + Shift + Esc というショートカットキーを使うと便利です

参考記事には WSL 2 の設定についても書かれていますが、これはもう完了しているので、Docker のインストールからの部分を参考にします。

今や Docker は GUI で操作できるようなので、Docker Desktop for Windows を導入します。2020年8月7日時点での Stable 版（安定版）のインストーラーをダウンロードしてインストールします。インストーラーのウィンドウのタイトルバーに「Installing Desktop Docker 2.3.0.4 (46911)」と書いてあり、ここで初めてバージョンを確認できました。

インストーラーの Configuration で Enable WSL 2 Windows Features にチェックがついているのを確認して [OK] ボタンを押すと、インストールが開始されました。インストールが完了すると「Installation succeeded」と表示され、「Close and log out」ボタンを押すと、Windows から強制的にログアウトしました。

Windows の再ログインすると、Docker の GUI が起動しました。

チュートリアルをしてくれるみたいなんですが、一旦スキップします。

Desktop Docker の設定（ギアのアイコン）の General で「Use the WSL 2 based engine (Windows Home can only run the WSL 2 backend)」にチェックが入っているのを確認します。確認すると、すでにチェックが入っていましたが、項目全体が薄灰色になっていて、チェックが外せないようでした。英語のカッコ書きで「Windows Home は WSL 2 バックエンドだけで動作する」って書いてあるので、WSL 2 が前提になっている状態なのでしょう。

設定の Resouces の WSL INTEGRATION の「Enable integration with my default WSL distro」にチェックが入っているのを確認します。確認したら、問題なくチェックが入っていました。

この WSL 2 での Docker を使えば、Hyper-V を使わなくても仮想環境が作れる、というのが利点のようなんですが、Hyper-V というのが BIOS 的な何か、というくらいの理解しかしていません。

これで、とりあえず WSL2 と Docker が使えるようになりました。