ししおどし

ゲートウェイルーターを OpenWrt 化した R7800 に置き換える計画は無事完了した。 これまで、ホームゲートウェイ直下の実質 DMZ である 192.168.0.0/24 と、ゲートウェイルーター（GateKeeper）の後ろにあるプライベート LAN の 192.168.1.0/24、VPN の仮想ネットワークの 192.168.255.0/24 という風に IP を割り付けていた。 しかし、これだと、これら全体の 192.168.0.0/16 を DMZ と LAN に再分割しようとする場合に、LAN にはプライベート LAN と VPN をグルーピングしたいのだが、サブネット的に無理である。192.168.0.0/24 と 192.168.1.0/24 は隣り合っているので、192.168.0.0/23 としてまとめることは可能だが、隔離したいのは DMZ 用の 192.168.0.0/24 の方なので、意味がない。 そこで、プライベート LAN を 192.168.1.0/24 から 192.168.128.0/24 にすることで、192.168.0.0/16 を 192.168.0.0/17 と 192.168.128.0/17 で真っ二つに分けると、前者には DMZ 用の 192.168.0.0/24 が、後者には プライベート LAN 用の 192.168.128.0/24 と VPN 用の 192.168.254.0/24 が含まれるという風に上手くサブネットでデザインできる。 （※ ちなみに、VPN 用を192.168.255.0/24 から 192.168.254.0/24 にするのは、単なる気まぐれである。何となく、偶数に揃えたかっただけという） 192.168.0.0 /17 11000000.10101000.0 0000000.00000000 ~ 11000000.10101000.0 1111111.11111111 すなわち、192.168.0.0~192.168.127.255 192.168.128.0 /17 11000000.10101000.1 0000000.00000000 ~ 11000000.10101000.1 1111111.11111111 すなわち、192.168.128.0~1

WireGuard VPN の仮想ネットワーク（192.168.255.0/24）から、接続先の LAN（192.168.1.0/24）内でブリッジ運用している Aterm WG1200HP（192.168.1.254）にアクセスできない。クイック設定 Web だけでなく、PING も反応なし。一方、このブリッジの向こう側にあるホストについては PING 等に応答は戻ってくる。 OpenVPN で TAP（ブリッジ）接続すると、WG1200HP に問題なく接続できる。TUN（ルーター）接続だとやはり駄目。 要するに、サブネット（セグメント）が異なると駄目なようだ。 単にブリッジ運用しているだけなので、VPN からアクセスできなくとも大して支障はないのだが、ともかく気持ち悪かった。 調べてみると、「 送信元検証機能 」が原因だった。（参考 👉 へっぽこ薬剤師のチラシの裏 ） 「使用しない」にして問題は解消、 VPN（別のサブネット）からでもクイック設定 Web と PING が ok となった。 はっきり言って、NEC のマニュアルの表現がおかしい。 送信元を詐称した通信を遮断する 送信元検証機能により、LAN側、WAN側からのアクセスを監視し、送信元のアドレスが不正なパケットを廃棄します。 別に「不正」じゃなくても、敵味方関係なく無差別攻撃しとるやんけ！ ユーザーを守る頼もしいヒーローのふりしてカッコつけたりしないで、「単純バカだから、サブネットが異なるのは、何も考えないでパケットを DROP」とでも書けばいいんだよ。こんなだから、ガラパゴス化して、国内トップでも国際競争力ゼロなんだよ……。

Unsplash の Adam Nowakowski が撮影した写真 坂本慎太郎『朝 9 時 10 分までにしっかり儲ける板読み投資術』（東洋経済新報社、2017-07-27） 年収 1 億円ディーラーの投資術 板読みの基本の基本 板読み投資の基本テクニック 銘柄選びの基本テクニック 板読み投資の実践テクニック 最後はメンタル──テクニックよりも大切なこと 第 1 章：年収 1 億円ディーラーの投資術 「板が薄いから誰も売ってこないんだよ」 目から鱗とは、まさにこのことです。 私は、いつでも逃げられるように買い板の厚い銘柄を選んでトレードしていましたが、この先輩は、「買い板が薄くて逃げにくい銘柄だから、誰も売らないので株価が安定している」というロジックで、わざわざ買い板の薄い銘柄を選んでいたのです。 ときどき成行の投げ売りをしてくる投資家もいますが、それで株価が下げたときには、単なるイレギュラーによる売りだから、買えばいいというスタンスなのです。 この話を聞いたとき、これは株式投資の縮図だと思いました。 やはり、イレギュラーによって生じた株価のブレを取りに行くのが、トレードの基本です。そう考えると、この先輩のトレードは、究極の板読みではないかとも思えたものです。 何しろ、いまはここの買い板が無いけれども、いずれ株価が下がれば自然のうちに買い板が出てくるという考え方に基づいて、それに先回りしてポジションを取っているのですから、これは上級の板読みトレードです。 したがって、この先輩は常に 30 銘柄、50 銘柄というように、実に幅広い銘柄に分散投資していました。 たくさんの銘柄に買いを入れていくので、この先輩はまだ板がほとんど出ていないような、朝の 8 時くらいから、それこそ数百銘柄の板を見ていました。 そして引けた後、もう一度、数百銘柄の板を見ているのです。 こうして数千円、1 万円という小さな利益を積み重ねて、1 日の利益を生み出していました。 第 2 章：板読みの基本の基本 約定ルール（優先順位） 成行 より高い買い指値、より安い売り指値 より早い注文 強い板・弱い板 買い板の厚い板を選ぶのは、「確実に上がる」からではなく、いち早く他の買い勢に売り付けて逃げるため。 上がる

VPN と言えば、以前は OpenVPN だったが、最近のトレンドは WireGuard （言うなれば、Apache に対する nginx のような？）。先日まで OpenVPN の設定を徹底的にやり込んで納得行く状態が確立できた ばかりなので、引き続き、VPN のこと自体にある程度フレッシュな知見がある今のうちにと思って、手がけてみることにした。 ソフトウェア R7800（hnyman ビルド）では、デフォルトで wireguard-tools、kmod-wireguard、luci-app-wireguard、luci-proto-wireguard がインストールされていたので、wireguard のみ、LuCI から追加でインストールした。 鍵ペアの用意 mkdir -p /etc/wireguard cd /etc/wireguard wg genkey | tee privatekey | wg pubkey > publickey /etc/wireguard/privatekey と /etc/wireguard/publickey が生成される。さらに、おまけとして presharedkey も使う場合には： wg genpsk > presharedkey /etc/wireguard/presharedkey を生成する。 以上のファイルのパーミッションを念のため、600 にしておく。 chmod 600 *key ネットワークインターフェースの追加 Network > Interfaces で WireGuard 用の論理ネットワークインターフェースを追加する。プロトコルを WireGuard VPN にするのがポイント。名前は wg0 にしておいた。 OpenWrt では、LuCI では専用のメニューが用意されている OpenVPN と違い、WireGuard はこの Network の Interface としての設定ですべてを管理するようになっているようだ（つまり /etc/config/network に記載される）。 Private Key の欄に /etc/wireguard/privatekey の内容をコピー＆ペースト Listen port: 5182

楽天 UN-LIMIT の MTU サイズが調べてみたら 1340（MSS は 1300）だった： 放っておいても macOS が自動で上手くサイズを調節しているとは思うが、念のために手動で 1340 に設定しておいた： ──が、公衆 Wi-Fi など、楽天 UN-LIMIT のテザリング以外の他の環境でも使うわけなので、やはり自動に戻した。

一応、公式に基本ガイド（👉 OpenVPN Basic ）があるが、「 OpenWrt の OpenVPN 基本ガイドの徹底解析 」で先日述べたように何かと不満があるので、自分用を兼ねて包括的なメモを記しておくことにする。 情報の鮮度的には、古い方のルーター（OpenWrt v18.06.2）が OpenVPN v2.4.5、新しい方のルーター（OpenWrt v19.07-SNAPSHOT）が OpenVPN v2.4.7 である。 また、クライアント側は、macOS の Tunnelblick を使用している。 ソフトウェア openvpn-openssl と openvpn-easy-rsa（と luci-app-openvpn）を LuCI からインストールした。 PKI PKI については基本ガイドや巷の情報でほとんど十分だと思うので基本的に割愛する（👉 Easy-RSA 3 Quickstart 、 Easy-RSA 3 ）。PKI 用の easyrsa コマンドは /etc/easy-rsa で実行し、PKI のパスが /etc/easy-rsa/pki となりその以下に各ファイルが配置されている。ただし、openvpn コマンドで作成する tlscrypt.key のみ、/etc/openvpn に置いている。 cd /etc/easy-rsa easyrsa init-pki easyrsa build-ca nopass easyrsa build-server-full openvpn-server nopass easyrsa build-client-full openvpn-client nopass easyrsa gen-dh openvpn --genkey --secret /etc/openvpn/tlscrypt.key TAP サーバーとして動かす場合 TAP サーバーとして設定するのは特に難しくなく、既存の情報で何か不足するようなこともない。 tap0 の準備 OpenVPN 自体の設定に一所懸命になっていると、この作業を思わず忘れてしまっていて動かずに原因がわからずに悩む場合があるが、仮想のものではあるとは言っても、まずは tap0 というインターフェースを用意してア

OpenWrt 公式の OpenVPN の基本ガイド（👉 OpenVPN Basic ）について。（日本人にとっては英語情報であるということ以前に、たとえネイティブであってとしても）ただ単に設定方法のシェルコマンドが掲載してあるだけで、ほとんど説明がされていないので、今回はかなり細かく解析して検証してみたいと思う。 ソフトウェアのインストール opkg update opkg install openvpn-openssl openvpn-easy-rsa これは一目瞭然だと思うが、openvpn-openssl と openvpn-easy-rsa パッケージをインストールしているだけ。LuCI からアプリをインストールするのと何ら違いはない。 openvpn-openssl が OpenVPN サーバー本体。openvpn-easy-rsa は証明書と鍵を生成するための認証局用のプログラム（easyrsa コマンドを使えるようにする）。この OpenWrt ルーターで証明書・鍵を直接発行せずに、他の PC 等で別途用意した証明書・鍵をルーターに持ってきて使用する場合には、openvpn-easy-rsa の方のインストールは必ずしも必要ではないのかもしれない。 証明書・鍵の発行 これだけが openvpn-easy-rsa に関する作業で、OpenVPN 本体とは直接関係がない、下準備に関する話ので、先に説明を済ませておくことにする。 easyrsa init-pki easyrsa gen-dh easyrsa build-ca nopass easyrsa build-server-full server nopass easyrsa build-client-full client nopass openvpn --genkey --secret /etc/easy-rsa/pki/tc.pem 各コマンドの意義は原文のコメントにある通り： Remove and re-initialize the PKI directory Generate DH parameters Create a new CA Generate a keypair and sign locally for a server Gen

これまで長い間 QNAP の NAS と Mac を使っていながら、iTunes を使ったことがなかった。自分が全然 iTunes で音楽を聴くというような行動スタイルがなかったからだ。ところが、家族が Mac で NAS に取り込んだ音楽を聴けるようにする要請があり、今さら、QNAP の NAS を iTunes サーバー化してみようかということになった。 元々、QNAP が iTunes にも対応しているということは管理画面でも知っていたが、調べてみると、 たった 1 ページの説明 で済む簡単な作業のようだった。 ところが、iTunes Server を有効化して、macOS (Catalina) のミュージック.app から QNAP 上の iTunes サーバーが見えるようになるまでは簡単にできたのはいいのだが、NAS 上のアルバムを選択しても、再生ができない。調べてみると、macOS Catalina (10.15) から新しくなったミュージック.app の仕様の変更が原因で、古い DAAP（ Digital Audio Access Protocol ）に対応しなくなったため（プロトコルのメッセージ中の「:」が「@」に変更されているとか）。原因はそれなのだが、悪いのはむしろ、とっくの昔に開発が停止した古い DAAP 用のサーバーアプリ（Firefly）のままで放置している QNAP の怠慢である（同じ台湾メーカーの Synology も似たりよったりな状況らしい）。Firefly の後継の forked-daapd にとっくの昔にリプレースしておくべき話だという。 Docker で forked-daapd を入れる（Docker） そこでどうにかする方法としてネットに出ているのが、 Docker を使って forked-daapd を入れてしまう という方法。ところが、Docker を入れられないモデルの NAS の場合はどうしようもない！ そう、うちの QNAP の NAS、 HS-210 がそうだ。ふざけんな QNAP！ macOS Catalina に iTunes.app を入れる（Retroactive） 仕方がないので、以前の iTunes.app を入れることで、当面の時間稼ぎをすることにした。 Retr

ゲートウェイルーターの置き換え計画 の下、 新しく入手した NetGear R7800 のファイアーウォール設定を、 初期状態 から変更した箇所を解説。 ※原則として /etc/config/firewall を直接編集するのではなく、LuCI の GUI を通じて設定しており、以下に掲載する Traffic Rules は、その GUI 操作による結果が反映されたものである。 デフォルト設定 config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' 変更せず。 lan ゾーン config zone option name 'lan' list network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT' 変更せず。 wan ゾーン config zone option name 'wan' list network 'wan' list network 'wan6' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' 「option mtu_fix '1'」を削除。これは WAN 側がモデムを介したプロバイダー側ネットーワークに直結しているケースを前提とした設定のものと思われ、実家の LAN 環境での LAN 間に設置する GateKeeper として運用するこのルーターでは不要。 フォワ

My car needs to be repaired. My car needs being repaired. My car needs repairing. 👉「 動名詞と TO-不定詞の使い分け 」で述べたように、これもやはり、動名詞と to-不定詞の根本的違いの観点から理解すれば特に不可解なことはない。 1. My car needs to be repaired. 本質的に to-不定詞は M であり、need は自動詞として存在するから、意味上の主語は SV の S と同じである。従って to-不定詞句は受動態で表現することになる。 2. My car needs being repaired. 動名詞句 being repaired は他動詞 need の目的語（O）である。S は O に他動詞を介して働きかける関係であるから、O の意味上の主語が my car となることは S と O が一致することとなり、他動詞の原理的に有り得ない。つまり、意味上の主語は S の my car 以外の他者を意味しているので、being repaird という受け身ではなく repairing という能動表現が適切である。ちなみに、being repaird とすると、受動表現ではなく、my car 以外の他者を意味上の主語とする進行形表現となってしまう。 3. My car needs repairing. 要するにこれは My car needs someone('s) repairing. の someone が不特定の人物なので明示せず省略された表現と考えれば良い。もちろん、repair する人物が特定している状況においては当然、My car needs the mechanic's repairing. という形の表現となるだろう。

動詞によって目的語に動名詞を取る場合と to-不定詞を取る場合、両方を取る場合がある。 動詞＋動名詞 動詞＋to-不定詞 両方（意味は同じ） 両方（意味が異なる） このような分類を受け容れると、結局はそれぞれの動詞群を暗記するしかなくなる。動名詞と to-不定詞の根本的な違いで理解するならば、そのような必要はなくなる。 1. 動詞＋動名詞 ex. avoid, deny, enjoy, finish, mind, stop この場合、本質的に動詞は他動詞であり、SVO の O として動名詞が存在する。なので、O の具体的存在感が重視される。 2. 動詞＋to-不定詞 ex. afford, expect, hope, pretend, wish この場合、本質的に動詞は自動詞であり、SVM の M として to-不定詞が存在する。なので、SV によって叙述が一応完結し、to-不定詞は付加的情報としての漠然とした曖昧模糊とした存在感となる。 3. 両方（意味は同じ） ex. begin, continue, like, start 日本語に訳す場合に同じ表現になるというだけで、本当は違うことになる。 4. 両方（意味が異なる） ex. forget, remember, regret, stop SVO か SVM かの違いが、「過去〜現在」の具体性か、「未来」の漠然性か、という違いを生むことになる。 要するに 4 ケースに分けてそれぞれの動詞群を暗記するようなことをする必要はなく、単に、「動詞＋動名詞（SVO）か、動詞＋to-不定詞（SVM）か」ということを理解していれば良い。

Do you mind my smoking? Do you mind me smoking? 動名詞の意味上の主語が、「述語動詞の目的語との混同で目的格（この例では me）となる場合がある」という説明がよくされるが、間違っている。 後者の smoking は動名詞ではなく、分詞であり、目的語 me を修飾する形容詞である。名詞と形容詞の区別は極めて初歩的な物事のはずだが、それができていない場合は、たとえ英語の専門教育を受けていて教育に携っているような人であっても、解説の方は信用してはならない。ただ、その道の情報について博識だというだけの話。 私の喫煙行為を気にしますか？ 喫煙する私のことを気にしますか？ そもそも、より本質的なことを言うと、「動名詞」なんて分類もおかしな話で、あくまでも分詞、そのうちの名詞的用法に過ぎないわけなのだが。

I don't know what to do with him. 特別視する必要はなく、単なる名詞＋不定詞（形容詞的用法）である。 彼と一緒にするべき何か（を、私は知らない） 要するに疑問詞 what はここでは名詞である。

.m3u8 形式の動画ファイルを公衆 Wi-Fi 環境でダウンロードして、後で部屋でゆっくり観ることができるようにする要請が生じたため、調べてみた。 .m3u8 ファイル自体をダウンロードする Firefox 版の 動画ゲッター を使った。 動画の視聴を始めると、プラグインが .m3u8 を認識し、.m3u8 ファイルをダウンロードできるようになる。動画ゲッターでは .m3u8 ファイルの中身の .ts ファイルもダウンロードできるが、そこまでする必要はない。 もちろん、面倒臭くなければ、ページの HTML ソースを直接見て、該当すると思われるプレイリストの .m3u8 を含む URL を抜き出してしまえば、動画ゲッターを使うまでもない。動画ゲッターで取った .m3u8 に記載されている URL が相対 URL だったりするなど、場合によってはこちらの方が手っ取り早い場合もある。 動画ゲッターでダウンロードした .m3u8 の中身 #EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1500000 https://???.cloudfront.net/???/???.m3u8 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=1500000,URI="https://???.cloudfront.net/???/???_iframe.m3u8" 動画ゲッターでダウンロードした .m3u8 ファイルの中身の https://???.cloudfront.net/???/???.m3u8 のアドレスを ffmpeg コマンドの入力ファイルとして使った。 ffmpeg で .m3u8 ファイルから MP4 に変換・結合する ffmpeg を使うのがシンプルかつ強力なので、Homebrew で ffmpeg をインストールした。 インストール brew install ffmpeg ffmpeg コマンド ffmpeg -protocol_whitelist "file,crypto,http,https,tcp,tls" -i ???.m3u8 -c copy -bsf:a aac_adtstoasc out.mp4 m3

100 個近くの一組のファイル画像群のウォーターマークを一斉更新する必要が生じたので、この機に GIMP の Python-Fu を使ってみることにした。 エラーがない状態でないと、Python-Fu スクリプトとしての認識自体がされない。 Python-Fu スクリプトとして認識させるために、一定のフォーマットを整える必要がある。 Python 2.x に基いているようなので、Unicode の扱いや str.format など 3.x と違う点に留意しなければならない。 macOS では ~/Library/Application Support/GIMP/2.10/plug-ins に置く。 上述のように、そもそもデバッグが不可能なので、スクリプトとして正常に認識されるフォーマットのスケルトン状態から一つ一つの機能を確実に実装して確認していくやり方でスクリプトを完成させていくのが適切な開発手法だろう。 使える機能（pdb.*）のリファレンスはヘルプ > プロシージャーブラウザーにある。 # -*- coding: utf-8 -*- from gimpfu import * WATERMARK = 'https://www.scaredeer.com' def watermark(infile, outfile): pdb.gimp_context_set_foreground((255, 255, 255, 255)) # RGBA image = pdb.gimp_file_load(infile, 'background') pdb.gimp_image_scale(image, 350, 600) # 縮小 background = pdb.gimp_image_merge_visible_layers(image, EXPAND_AS_NECESSARY) pdb.gimp_rotate(background, 0, pi) # 180°回転 text_layer = pdb.gimp_text_layer_new(image, unicode(WATERMARK, 'utf-8'),