投稿

6月, 2020の投稿を表示しています

R7800 OpenWrt(hnyman ビルド)のファイアーウォールの初期設定

イメージ
OpenWrt は fw3 を使っている。 fw3 では iptable を直接いじるのではなく、 設定ファイル (/etc/config/firewall 等)から一連の iptable を生成して、それを netfilter に渡す。netfilter に渡される iptable 自体はかなり複雑でユーザーが直接いじれるものではなくなっている。従って、fw3 に渡す設定ファイルの方を扱うことを考えればよく、UCI や LuCI で CUI/GUI を通じて操作するのも、設定ファイルの方である。 デフォルト設定 config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' グローバルに適用されるデフォルト設定(👉 Defaults )。 通信のルーター自身への出入は許可し、通過は拒絶する。syn_flood プロテクションを on。 lan ゾーン config zone option name 'lan' list network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT' lan のゾーン設定(👉 Zones )。 lan 側インターフェース(lan)をこのゾーン(lan)に割り当て、全ての通信を許可。 wan ゾーン config zone option name 'wan' list network 'wan' list network 'wan6' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' o

SyntaxHighlighter から Prism へ移行

プログラムのサンプルコードの表示用のツールを SyntaxHighlighter から Prism へ移行した。 このサイト(www.scaredeer.com)は Blogger で運用しており、Blogger の記事・ページとして生成されるファイル以外に、自分で任意のファイルを置けず、当然、Prism 用のファイル(prism.css と prism.js)も設置できない。 仕方ないので、DNS の設定でサブドメイン www2 の A レコードを追加して、別サーバー(nginx で運用)を用意し、そこに設置した Prism 用のファイルをこの Blogger から指し示すようにして運用している(👉 Blogger と独自ドメインの設定 )。 Blogger のテーマの HTML のカスタム箇所 <head> ... <link href='https://www2.scaredeer.com/prism/prism.css' rel='stylesheet'/> </head> <body> ... <script src='https://www2.scaredeer.com/prism/prism.js'></script> </body>

Favicon Generator

イメージ
Favicon Generator ( realfavicongenerator.net ) を使って SVG 画像から各種 favicon とそれ用の head 内記述用タグを自動生成できる。 今回は、Blogger サイト用の favicon を生成して、Blogger の外部サイト(www2.scaredeer.com)を用意してそこに各種の favicon データを置いてみた(👉 Blogger と独自ドメインの設定 )。Blogger の favicon ガジェットを使うと、自動で 16x16 に圧縮された物凄く汚ないアイコン画像しか使えないからである。 以下、Blogger のテーマの HTML を修正するわけだが、その場合の注意点: 各タグが閉じられていないので、タグの最後の > の直前に / を入れて /> の形式にしておく必要がある。 head 内記述用タグの挿入する位置は CSS 定義よりも前にした方が良い(自分はテーマ HTML の viewport 定義と title の間にした)。そうしないと、meta theme-color が反映されなかった。cf. This value is used by the user agent to draw the background color of a shortcut when the manifest is available before the stylesheet has loaded. 生成される manifest のファイル名が web.manifest となっているが、これは json ファイルなので、manifest.json にファイル名を変更して Web サーバー側で .json ファイルとして適切に MIME が認識されるようにした。これに伴って、head 内記述用タグの manifest のリンク先も修正した。 ついでに manifest の中のエントリーとして description の情報も補っておいた。 head 内記述用タグ manifest.json { "name": "ししおどし", "short_name": "鹿威し&qu

Aterm BL902HW のファイアーウォールの初期設定

イメージ
au ひかりマンション(VDSL タイプ)用の HGW である Aterm BL902HW について、初期状態でのファイアーウォールの設定について調べてみた。 WAN 側インターフェース 種別 方向 プロトコル 送信元 送信元ポート 宛先 宛先ポート 優先度 廃棄 out UDP any any any 137-139 1 廃棄 out TCP any any any 137-139 2 廃棄 out UDP any any any 445 3 廃棄 out TCP any any any 445 4 廃棄 out TCP any any any 2049 5 廃棄 out UDP any any any 2049 6 廃棄 out TCP any any any 1243 7 廃棄 out TCP any any any 12345 8 廃棄 out TCP any any any 27374 9 廃棄 out TCP any any any 31785 10 廃棄 out UDP any any any 31789 11 廃棄 out UDP any any any 31791 12 廃棄 in TCP any any any 1243 13 廃棄 in TCP any any any 12345 14 廃棄 in TCP any any any 27374 15 廃棄 in TCP any any any 31785 16 廃棄 in UDP any any any 31789 17 廃棄 in UDP any any any 31791 18 一見複雑なようだが、全て廃棄するルールで、送信元ポートは全て any であり、重複してエントリーされているものがあるので、宛先ポート毎にまとめて考えれば、かなり単純だと思う。独自に宛先ポート毎の表にしてみた: WAN 側インターフェース 宛先ポート 方向 プロトコル 備考 137-139 out TCP/UDP NetBIOS over TCP/IP (Windows) 445 out TCP/UDP Direct Hosting of SMB (Windows) 2049 out TCP/UDP NFS (UNIX) 1243

Blogger と独自ドメインの設定

イメージ
SEO の観点からすると、サブドメインを無闇に乱立させずむしろ一箇所に集約させた方が良いようなので、一箇所に統合することにした。 従来 blog.scaredeer.com(@blogger):ブログ www.scaredeer.com(@nginx サーバー):コンテンツはほぼトップページのみ 統合後 www.scaredeer.com(@blogger):ブログ+ページ サブドメインなしの scaredeer.com は www.scaredeer.com にリダイレクトあれ、またプロトコル面でも、http を https にリダイレクトすることで、厳密に https://www.scaredeer.com へと集約 した。 Blogger での設定 カスタムドメイン:www.scaredeer.com カスタムドメインにリダイレクトする ✅ HTTPS の使用 ✅ HTTPS リダイレクト ✅ DNS(ムームー DNS で)の設定 Blogger でのサードパーティドメインの設定の過程において、DNS 側の一定の設定を行うことが求められる。自分は DNS そのものはあまり詳しくなく、ムームー DNS での設定しか実際に操作する機会がないので、下の設定で本当に良いのかはあまり自信がないが、大体こんなものだろうと思う: サブドメイン 種別 内容 備考 A 216.239.32.21 scaredeer.com 自体の IP アドレス(1/4) A 216.239.34.21 scaredeer.com 自体の IP アドレス(2/4) A 216.239.36.21 scaredeer.com 自体の IP アドレス(3/4) A 216.239.38.21 scaredeer.com 自体の IP アドレス(4/4) TXT google-site-verification=●●● Google にドメインオーナーであることを示す www CNAME ghs.google.com www.scaredeer.com → ghs.google.com ●●● CNAME gv-●●●.dv.googlehosted.com ●●●.scaredeer.com → gv-●●●.d

SEO for my.domain

『 3,000万ユーザーを集客した結果わかった、SEOに関する30の教訓 』 固執するのはコンバージョンであり、ランキングではない SEOからのトラフィックを上昇させる最も簡単な方法は、他国への展開である キーワードは、とても、とても、とても、とても重要だ AMPページはより多くのSEOトラフィックを発生させる SEOはペイド広告ほどコンバージョンしない リマーケティングはSEOからのROIを発生させる、最善の方法の1つである 過去のコンテンツのアップデートを怠らない タイトルタグの最適化を怠らない URLに日付は含めない ポップアップの使用を恐れない ブランドクエリはランキングに影響する 有料リンクにお金を費やさない ゲスト投稿は、リンクの構築ではなく、ブランド構築のために行う 内部リンクを忘れるべからず Googleが唯一の検索エンジンではない スピードは正義 質は量を凌駕する コンテンツマーケティング以上にツールは効果的 SEOに依存しすぎない 人々はデータにリンクすることを好む インフォグラフィックの存在を忘れてはならない Googleは重複コンテンツにペナルティを与えない 車輪の再発明はしない 一般的なドメイン名は使用しない ブラックハットSEOから学ぶものもあるが、ダークサイドに足を踏み入れてはならない 短いURLは長いURLよりも上位に表示される リストのパワー 足元をすくわれるな 最高のSEOのアドバイスはカンファレンスで得られる 学ぶ姿勢を止めない 1. 固執するのはコンバージョンであり、ランキングではない 至極もっともな正論だが、そもそもサイトの存在が知られてもいないレベルの段階の my.domain においては考えても仕方がない。 ただし、 crazyegg というツールは面白そうだ。 2. SEOからのトラフィックを上昇させる最も簡単な方法は、他国への展開である 外国人向けの業務は元々想定していたので、そのことと併せても英語サイトの展開は積極的にしても良さそうである。 3. キーワードは、とても、とても、とても、とても重要だ Ubersuggest で競合サイトに対抗するためのキーワードを探る。 4. AMPページはより多くのSEOトラフィックを発生さ

Netgear R7800 の OpenWrt 化

イメージ
最新の OpenWrt R7800 用ファームウェア(hnyman ビルド)のインストール NetGear R7800 は一部のハードウェアチップ用ドライバーが非公開のためサポートされていないもの(ハードウェア NAT 機能)もあるが、全体としては Linux カーネルの更新に追従し続けているため、発売当時の OpenWrt ベースのままである純正 OEM ファームウェアよりもはるかに良くなっている(👉 Some notes on the current support in OpenWrt ) このルーターは 2016 年末頃から OpenWrt コミュニティによってサポートされ続けており、既に十分に安定化しているので、迷わず OpenWrt 化することを決意した。特に、R7800 についてはコミュニティの中心的人物である hnyman 氏が コミュニティビルド を用意しており、絶大な支持を集めているので、その通称 hnyman ビルドの stable 版を用いた。 OEM 版からの GUI のファームウェア更新機能を利用してファームウェアを乗せ換えるので、使ったのは *-factory.img である(*-sysupgrade.bin は OpenWrt 化済の場合に OpenWrt の GUI からアップデートする場合に使うもの)。もちろん、 TFTP から *-factory.img を書き込むことも可能(反対に純正 OEM 版に戻す場合も TFTP から R7800-V1.0.2.68.img を書き戻せばよい)。 ちなみに、コミュニティで hnyman 氏らが慎重に検証していたが、OpenWrt 化に先立って予め、何らかの失敗に備えるために純正版の mtd をバックアップしておくような作業をする必要はない。OEM 版ファームウェアを書き戻す際に、付随する設定値を格納するパーティションも初期化されて復活するようになっているようである。そういう意味でやはり Netgear はカスタムファームウェアに対しては非常に寛容で好感の持てるメーカーであり、チップのドライバーの公開・非公開次第では OpenWrt フレンドリーな製品となりやすいブランドだと思う。 Wi-Fi 設定の初期化 👉 OpenWrt での Wi-Fi 設定 (

ゲートウェイルーターの置き換え

イメージ
従来の状況 1 年 4 ヶ月前の記事『 実家ネットワークの再構築 』の続編にあたる。 実家のネットワーク構成において、回線会社から貸与されているホームゲートウェイ(192.168.0.1)直下のネットワーク(192.168.0.0/24)を DMZ と命名し、そこに接続した別のルーター(192.168.0.254)を GateKeeper と命名して、さらのこの GateKeeper(192.168.1.1)の配下のネットワーク(192.168.1.0/24)を実際の家庭内 LAN として構成するデザインで運用している。 これまで、GateKeeper として単なる Wi-Fi ブリッジ兼用ルーター用途程度の性能しかない廉価な NEC Aterm WG1200HP を Floor A に配置してきた。このほど、OpenWrt 化用に最適な高性能機種としてかなり以前から候補にしていた Netgear R7800 がとうとう中古で入手できたので、これを OpenWrt 化した上で、この WG1200HP をリプレースし、さらに、Floor B 用の Wi-Fi アクセスポイントとして使っていた OpenWrt 化済 Buffalo WZR-HP-AG300H(IEEE 802.11ac 非対応)に担わせていた OpenVPN サーバーと DHCP サーバーの役割も新しい GateKeeper(OpenWrt 化 R7800)に担わせ、この WZR-HP-AG300H は退役、代わりに Floor B 用の純粋な (IEEE 802.11ac 対応の)Wi-Fi アクセスポイントとして WG1200HP に置換したいと思う。 予定のネットワーク構成図 現状のスピードテスト

アドレス帳データの iOS (iCloud) から Android (Google コンタクト) への移行

最近、楽天モバイルに乗り換え、スマートフォンの環境を徐々に iOS から Android に再び移行しつつある。逆の方向の移行の場合も似たようなものだが、アドレス帳については、基本的に、vCard 形式のデータでエクスポート&インポートができるので、特に難しくはない。 今回は、Mac 上で、連絡先アプリ(iCloud)から vCard をエクスポートし、Web で Google アカウントの Google コンタクト を開いて、インポート作業を行った。 Web の Google コンタクトでインポートする際に、vCard の拡張子を .vcf にしていないと、読み込めるファイルとして認識されなかった。 個別のアドレスデータは特に問題なくエクスポート&インポートできるが、グルーピング・タグ付けは、それぞれのアドレス帳アプリが行っていることなので、そこは改めてやり直す必要がある。 Google コンタクトインポート直後は、インポートの「月日」の名前を付けられたタグにまとめられている。そこから自分でタグを仕分けする。 少なくとも Web の Google コンタクトでは、デフォルトでは「名姓」の順番で表記されるので、設定で「姓名」に変更する必要があった。 Web の Google コンタクトを変更すれば、そのまま同じ Google アカウントに紐付いた Android のアドレス帳に反映されている。