徒然なるままに プログラミングメモや日々の生活などつれづれとつづっていくblog

2020年10月27日

OpnSense + Nginx + Let’s Encryptでルーター兼ロードバランサーを構築する。(Let’s Encrypt編)

Filed under: Let's Encrypt,Linux,Nginx,Opnsense — ranpei @ 12:24 AM

DNSによる名前解決ができることを前提として解説します。

◆Let’s Encryptプラグインをインストール

「os-acme-client」の「+」ボタンを押下してプラグインをインストールします。

◆Nginxの設定

Let’s Encryptがドメイン確認時にアクセスするパスを設定します。

  • URL Patternに「/.well-known/acme-challenge/」
  • File System Rootに「/var/etc/acme-client/challenges/.well-known/acme-challenge/」
  • Locationsに上記のLocationを追加
  • Enable Let’s Encrypt Plugin Supportのチェックを外す(ここ重要)

保存したら右下の更新ボタン(設定反映)を行ってから、右上の更新ボタンを押下して設定を反映させてください。

(どうも右下のボタンを押さないと設定がうまく反映されないことがあるようです)

◆Let’s Encryptプラグインの設定

「サービス>Let’s Encrypt>設定」でプラグインを有効化

「サービス>Let’s Encrypt>アカウント」 でアカウントを登録

「サービス>Let’s Encrypt>検証メソッド」で検証メソッドを登録

「サービス>Let’s Encrypt>検証メソッド」 で証明書を取得するドメインを設定

ドメインの設定が済んだら右メニューの更新ボタンを押下して証明書を発行・更新します。

しばらくたってACMEステータスが「OK」となれば証明書の取得完了です。

◆ Nginxの設定(証明書設定)

Http Serverからドメインに証明書を設定して再起動します。

(HTTP Onlyにチェックを入れると強制的にhttps接続にリダイレクトするようになります)

Httpsで接続して証明書がきちんと設定されていることを確認しましょう。

◆補足

さて、なぜNginx側で「 Enable Let’s Encrypt Plugin Support 」のチェックを外したか疑問に思う方もいるかもしれませんので補足です。

実はNginxでは上記チェックが入っていると「http://127.0.0.1:43580//.well-known/acme-challenge/」へのリバースプロキシが自動的に設定されます。

この「43580」ポートに関しては 「サービス>Let’s Encrypt>設定」 で詳細モードをONにすると設定項目が現れますので、管理用WebGUIのポートに変更してファイアウォールの設定をキチンとできればLocationの設定なしでも証明書の発行は行えると思われます。

ただ残念ながら私のうまくいかなかったため管理用WebGUIが参照するAliasパスを強制的に参照するように設定して、無理やりLet’s Encryptのドメイン確認が通るようにしました。

OpnSense + Nginx + Let’s Encryptでルーター兼ロードバランサーを構築する。(Nginxリバースプロキシ編)

Filed under: Let's Encrypt,Linux,Nginx,Opnsense — ranpei @ 12:24 AM

◆Nginxプラグインをインストール

「システム>ファームウェア>プラグイン」を選択

「os-nginx」の「+」ボタンを押下してインストールします。

◆管理WebUIの動作ポートを変更

Nginxを80・443ポートで動作させるため、管理用WebGUIのポートと被ってしまいます。

そのため管理用WebGUIのポートを変更しておきます。(変更したポートを忘れてログインできなくならないよう注意!)

TCPポートを任意のポートに変更します。

◆リバースプロキシを構成する

ここではLAN側に「192.168.1.100」というWebサーバーが存在する前提で設定を進めます。

「サービス>Nginx>構成」を選択。

①Upstreamサーバーを登録

「Upstream Server」を選択して、「+」ボタンを押下。

Upstream Serverを追加

「Upstream」を選択して、「+」ボタンを押下。

Server Entriesに↑で設定したサーバーを選択。

②Locationを設定

Upstream Serversに①のUpstreamを設定

③HttpServerを設定

Locationsに②で作成したLocationを設定

終わったら「全般設定」で「Enable nginx」のチェックを入れて「適用」を押下。

正常に起動したら右上の▶が黄緑に変わります。

④ファイアーウォールを設定

ファイアウォールの設定で80、443ポートの接続を許可してください。

上手く設定できればOpnsenseにアクセスするとプロキシ先のページが表示されるはずです。

OpnSense + Nginx + Let’s Encryptでルーター兼ロードバランサーを構築する。(インストール編)

Filed under: Let's Encrypt,Linux,Nginx,Opnsense — ranpei @ 12:22 AM

我が家のネットワークはサーバー側をIPv6に対応させるため、2コネクタ使って二股に接続する体系をとっていたのですがさすがに配線が複雑化。。。。

それ以外にも固定IP側物理ルーターが古いため性能が低く、通信性能の低下を招くという問題もありました。

旧ネットワーク構成

そんなときOpnSenseというルーター兼ファイアーウォールを構築できるLinuxディストリビューションを見つけたため、これを使ってネットワークを整理することにしました。

整理後ネットワーク

多段ルーター構成となりますがIPv6通信が主流となりつつある状況なのでこの際IPv4の性能には目をつぶります。(というかこれなら下のルーターいらないですが固定IPを使いたいので・・・)

まあ当然いろいろとつまづいた点もありましたが、おおむね想定通りの構成を構築できたのでメモとして残します。

◆OpnSenseを選んだ理由

同じような使い方ができるLinux OSにはpfSenseやVyattaなどがあります。

その中でOpnSenseを選択した理由ですが、WebUIの管理機能(日本語対応)があったこと。

グラフを用いた詳細な分析機能が搭載されており、管理に役立ちそうだったこと。

opnsenseグラフ

特にプラグインを利用することでNginx + Let’s Encryptを用いたリバースプロキシサーバーを構築できる点がよく、現在Nginxで構築しているWebフロントを移行できれば管理しやすくなると考えたためです。

まあ、いろいろと苦労しましたがそれはおいおい説明します。

◆OpnSenseインストール

まずはOpnSenseをインストールします。

今回はEsxiにインストールしますが、OpnSensenはFreeBSDをベースとして開発されているため、ゲストOS種別に Debian を選択しました。(追記:OS種別その他にFreeBSDがありましたのでこちらを選択したほうが良いです)

仮想マシン作成1

この場合vHDDのSCSIコントローラーが「VMware Paravirtual」となるため「{コントローラー名}」に変更します。( 「VMware Paravirtual」 のままだとインストーラーにHDDが無いと怒られます。)

そのほか、ネットワークアダプタにはWAN用、LAN用のコネクタを2つ以上を設定します。(イメージではWAN用、LAN用、OPT1用(管理コネクタ)の3つを設定してあります。)

仮想マシン作成2

インストールCDからVMを起動してログイン画面に到達したら ログインID:installer、パスワード:opnsense と入力してログインします。

インストール1

インストーラーが立ち上がったらキーボード設定を「jp.kbd」に変更。

インストール2
インストール3

変更後「Accept these Settings>Guided installation」を選択して画面の指示にしたがってインストールを行います。

インストール4
インストール5

インストール後再起動すると と以下のコンソールが立ち上がるのでログインします。

ログイン

ログイン後「1)Assign interfaces」からコネクタを設定していきます。

①VLANは「N」を入力

コネクタ設定1

①WANに使うコネクタを入力

②LANに使うコネクタを入力

③OPT1~nの各コネクタに使用するコネクタを入力(選択コネクタがない場合、何も入力せずEnter)

コネクタ設定4

その後「2)Set interface IP address」からLANのIPアドレスの設定を行います。

①「1」でLANを選択

LANの初期設定

② 自身が割り振り元となるためDHCP利用は「N」、IPアドレス・サブネットマスクは任意で入力

LAN初期設定2

③ LANなので何も入力せずにEnter

LAN初期設定3

④ LAN側でDHCPサーバーを起動するため「y」

LAN初期設定4

⑤IPアドレスの範囲はお好みでどうぞ

LAN初期設定5

⑦ WebGUIへのアクセスを許可するか聞かれるので「y」を入力

◆OpnSense設定(前準備)

設定後はWebUIから設定を行うのですが、今の状態ではLAN側からしかアクセスできません。

そのため以下の操作はLAN側に接続するVMを用意して行っています。

①WebUI画面にログイン(アカウントID/パスワードはコンソールと同じ)

②ウィザードが立ち上がるため順次設定を行う

  • Languageを「Japanese」
  • DNSサーバーは任意に設定
  • タイムゾーンは「Asia/Tokyo」
  • IPv4構成タイプはいったん「DHCP」(あとで変更します)
  • IPアドレスとサブネットは任意に設定
  • パスワードを変更しない場合は未入力で「次」
  • 「リロード」を押下して設定を反映させる

③OPT1からWebUIに接続できるように設定

・ メニューから「インタフェース>OPT1」を選択

  • 「インタフェースを有効」にチェック
  • IPv4構成タイプは「静的IPv4」
  • IPv4アドレスは「任意のIP/24」
  • 「保存」したら右上の「変更を適用」を押下して設定を適用

・メニューから「ファイアウォール>ルール>OPT1」を選択、「追加」ボタンを押下

  • 動作は「許可」
  • 方向は「in」
  • TCP/IPバージョンは「IPv4」
  • プロトコルは「any」
  • 送信先、送信元は「任意」

「保存」押下後、右上の「変更を適用」ボタンを押下して変更を適用する

以上でOPT1からのアクセスが可能となります。

OPT1側から設定したIPアドレスにアクセスしログイン画面が表示されるか確認しましょう。

◆ OpnSense設定(IPv4 PPPoE + IPv6 DHCP)

ここからはOPT1側から設定していきます。

① PPPoE接続の設定を行う。

「インタフェース>WAN」を選択

  • IPv4構成タイプは「PPPoE」
  • PPPoEの「ユーザー名」「パスワード」はISPのものを入力

「保存」押下後、「変更を適用」で設定を適用する。

② DHCPv6の設定を行う。

「インタフェース>割当」を選択、WAN6としてコネクタを割り当てる。

「インタフェース>WAN6」を選択、IPv6側をDHCPで設定。

ダッシュボードで確認するとWAN、WAN6にそれぞれアドレスが割当られていることが確認できるはずです。

2020年2月27日

MintLinux19からL2TPでVPN接続する

Filed under: Linux,SoftEtther VPN,VPN — ranpei @ 12:37 AM

Ubuntu系のMintLinux19からSoftetherサーバーへL2TPで接続するのに少々手こずったのでメモ。

1.GUIで設定できるようにする。

まず、ネットワーク設定に「Layer 2 Tunneling Protocol(L2TP)」がないんで追加します。

・Network-manager-l2tp-gnomeをインストール。

そうするとネットワーク設定に「Layer 2 Tunneling Protocol(L2TP)」が追加されるのでVPN設定が追加できるようになります。

・L2TPで接続する設定

設定に関しては以下のような感じ。

  • 名前(N)は任意。
  • ゲートウェイ(G)には接続先のIPまたはドメインを入力。
  • ユーザー名は「ユーザー名@ハブ名形式」で入力。 ※パスワードは接続時に入力します。
  • Gateway IDは空欄。
  • Phase1 Algorithmsに「aes128-sha1-modp1536」を入力。
  • Pre-shared KeyにはSoftetherで設定した「IPsec 事前共有鍵」を入力。
  • Phase2 Algorithmsに「aes128-sha1」を入力。
  • MPPE暗号を使用する(P)にチェックを入れる。
  • PPP Echoパケットを送信する(E)にチェックを入れる。

・ポイント

ここでポイントとなるのは IPsec Settings… の設定。

Advanced で暗号化方式を自鯖に合わせて設定しないといけません。(ここに設定する値を調べるのに時間がかかった・・・・)

・愚痴・・・・

なお、うちの環境だとドメイン経由だとなんかうまく接続できないです・・・・

IP直指定でも問題ないんで今日はここまで。

2019年6月24日

運用中のMisskeyをv10→v11に更新する。

Filed under: Fediverse,Misskey,オープンソース — ranpei @ 1:06 AM

分散型SNSが流行りだした当初、MastodonのほかにもMisskeyという国産の分散SNSも運用してまいりました。

月日はたちMisskeyも順調に開発が進められてついにv11になったのですが、
このv11からDB鯖がMongoDB→PostgreSqlに変更となったため
更新にひと手間かかります。

国産でありながらあまり情報が出回って無いようですので、
何かのお役に立てばと共有がてらメモを記録します。

■更新手順

リリースノートに更新の作業について書いているのですが、更新手順として

  • 最新ソースを取得後、migrationブランチをチェックアウトする。
  • 設定ファイルにMongoDBとPostgreSQLの接続設定を記載する。
  • ※またconfig.yml内のid:’aid2’となってる箇所をid:’objectid’にしてください
  • npm migrateを実行。
  • ブランチをmaster(もしくは使用するバージョン)に戻してMisskeyを起動する。

を行えばよいです。

ただ、上記には補足があって11.23.0現在までmigrationブランチは整備されています。
なのでv10.100→v11.0.0(migration)→v11.0.0(master)→最新verって感じに徐々に上げていく必要はありません。

上げる場合はその時点での最新バージョンで行いましょう。


手順は割愛します。リリースノート通りにやれば問題ないんで。

(むしろ更新するバージョンに合わせないと何度もやり直す羽目になります;;)

2019年3月1日

Dockerコンテナでポート変更せずに共存させる方法

Filed under: Docker — ranpei @ 8:45 PM

Dockerでサービスを起動させる場合

# docker run -p 80:80 wordpress

wordpress:
  image: wordpress
  ports:
    - "80:80"

って感じでポートを開けますね。

でもこのポートがかぶっていた場合はどうしますか?

“81:80”, “82:80”, “83:80” って開放するポートをずらして起動します?

 

それでも良いですがDockerのネットワーク機能を使うことで

ポートを変更せずに同居させる方法があるのでご紹介します。

 

■方法

やり方は簡単です。以下のように起動コンテナに固定のIPアドレス割り当てるだけです。

version: '3'
services:
  concrete5:
    image: concrete5
    restart: always
    networks:
      vpcbr:
        ipv4_address: 172.168.0.2
  wordpress:
    image: wordpress
    restart: always
    networks:
      vpcbr:
        ipv4_address: 172.168.0.3
networks:
  vpcbr:
    driver: bridge
    ipam:
      config:
        - subnet: 172.168.0.0/16
          gateway: 172.168.0.1

 

後はリバースプロキシ設定に固定化したIPアドレスを設定するすれば

ポート変更の必要なくサービスを同居させることができます。

 

■補足

当然ですが同じDockerネットワーク上にいることが条件です。

複数ホストで運用している場合は相互に通信できるようにDockerネットワークを構築してください。

ネットワークイメージ

(当サーバーではホスト上にインストールしたNginxでリバースプロキシしています)

2019年2月27日

マストドンを初めて使う人のためのハウツー

Filed under: Fediverse,Mastodon,オープンソース — ranpei @ 9:37 PM

これからマストドン(Mastodon)を始めようとする方が戸惑うポイントをつらずらと書いていきます。

 

■基本編

  • マストドン(Mastodon)って何?

    Twitterライクな分散型SNSです。(とりあえず今はこれだけ覚えてください。)

  • まず何をすればいいの?

    気になるアカウントをどんどんフォローしていって
    メインとなるホームタイムラインを充実させましょう。

  • 知らない人をいきなりフォローして失礼じゃないの?

    問題ありません。むしろマストドンは「勝手フォロー」「勝手ブースト」が推奨です。

  • Twitterと全然違うね。。。

    別物なんですからむしろ当然では?
    下手にTwitterと同じように使うよりも、別の切り口で使った方が楽しいかもですよ?

■使い方編

  • トゥートって何?

    Twitterでのツイート(つぶやき)のことです。

  • ブーストって何?

    リツイートのことです。

  • 「ホーム」「ローカルタイムライン」「連合タイムライン」って何?

    とりあえずは以下の認識で・・・・

    [ホーム] :メインで利用するやつ。(どんどんフォローしてにぎやかにしましょう。)
    [ローカル]:このサーバーにいる人たちの公開トゥートが見れる。
    [連合] ※ :このサーバー”以外”の人たちの公開トゥートが見れる。(ここから気になる人を見つけてどんどんフォローしよう)

    ※ ごめんなさい。分散型の核となる機能なんですが説明量が多いんで省かせてください;;

  • カメラアイコンの横に「公開」「未収載」「フォロワー限定」「ダイレクト」ってあるけど詳しく教えて

    トゥートの公開範囲ですね。トゥートが見れる範囲が以下のようになります。

    [公開] :トゥートがタイムラインに流されて多くの人の目に留まりやすくなります。
    [未収載] :トゥートはタイムラインには流されませんが、見れないわけではありません。(あなたのアカウントをたどれば普通に見れます。)
    [フォロワー限定]:フォロワーのみが見れる状態でトゥートします。
    [ダイレクト] :特定のアカウントと1対1で話す場合に使用します。(まんまTwitterのDMですね。)

  • 画像を上げると目のアイコンが出たんだけど何?

    NFSWを設定して画像を投稿するオプションです。

  • NFSWって何?

    画像を隠した状態でタイムラインに流します。
    その画像を見る人が不快に思ったり、傷つくことが予想される場合に使用します。

    見る人はクリック(or タップ)すれば画像が見れる状態になります。

  • それ意味あるの??

    ワンクッション置くことで見る人は心の整理が付きますし、
    本当に見たくない人はそのまま見なければいいです。

    私は相手に選択の余地を残してあげる「思いやり」だと思っています。

  • CWって何?

    NFSWの文字版。
    タイムラインには折りたたまれた状態でトゥートが流れます。
    そのトゥートを見る人が不快に思ったり、傷つくことが予想される場合に使用します。

  • ってことは・・・

    はい。見る人はクリック(or タップ)すれば見れる状態になります。

    でもいきなり言葉を投げつけられるよりも
    相手に受け取るかを選択してもらう方が親切ですよね。

 

※もっと楽しく使いたいなら以下のサイトもおすすめです
〇Quesdon(ザ・インタビューズとかaskfmとかそんなかんじのやつ)
https://quesdon.rinsuki.net/
〇カスタム絵文字でお絵かきツール
https://mamemomonga.github.io/mastodon-custom-emoji-oekaki/
〇ドン廃あらーと(毎日午前0時にアカウントの変動状態をトゥートします)
https://donhaialert.herokuapp.com/

2018年8月20日

GoAccessを使ってリアルタイムアクセス解析を行う

Filed under: GoAccess,Linux,Nginx,OSS,ログ,不正アクセス — ranpei @ 9:04 PM

Ubuntu 16.04 + Nginx にGoAccessを使ったリアルアイムアクセス解析の環境を作ったのでその内容をメモ。

 

1.GoAccessをインストール
これは公式の手順を参考にインストール。

// 必要パッケージをインストール
$ sudo apt-get -y install libncursesw5-dev gcc make
$ sudo apt-get -y install libgeoip-dev libtokyocabinet-dev

// GoAccessをダウンロード
$ wget http://tar.goaccess.io/goaccess-1.2.tar.gz

// コンパイルしてインストール
$ tar -xzvf goaccess-1.2.tar.gz
$ cd goaccess-1.2
$ sudo ./configure --enable-utf8 --enable-geoip=legacy
$ sudo make
$ sudo make install
$ sudo ln -s /usr/local/bin/goaccess /usr/bin/goaccess

インストールできたら試しに解析してみる。

$ sudo goaccess /var/log/nginx/access.log --log-format=COMBINED

こんな画面が表示される。

 

さて、GoAccessは解析結果をHTMLとして出力することもでき、
さらに –real-time-html オプションをつけることで常時情報が更新されるHTMLを出力できます。

注意点としては情報更新の通信(WebSocket)に 7890番ポートを使用するためFWを開放しておきましょう。

$ sudo ufw allow 7890

※ ルーターの開放なども必要ですが割愛します。

開放したら以下のコマンドでリアルタイム解析HTMLを出力しましょう。

$ sudo goaccess /var/log/nginx/access.log -a -o /usr/share/nginx/html/report.html --real-time-html --log-format=COMBINED

http://[ホスト名 or IPアドレス]/report.html にアクセスすると以下ような画面が見れるはずです。

 

 

2.サービス化する
常時起動するには毎回先ほどのコマンドを実行するわけにはいきませんので、

今回はサービス化して常時起動する状態にしたいと思います。

// 定義ファイルを作成
$ sudo vi /etc/systemd/system/goaccess.service
↓↓ 記載
[Unit]
Description=Goaccess Web log report.
After=network.target

[Service]
Type=simple
User=root
Group=root
Restart=always
ExecStart=/usr/local/bin/goaccess -a -g -f /var/log/nginx/access.log -o /usr/share/nginx/html/report.html --real-time-html --log-format=COMBINED --ws-url <host名>
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target
↑↑ 記載

// サービスファイルとして認識されたか確認
$ sudo systemctl list-unit-files --type=service | grep goaccess
goaccess.service disabled ← 表示されればOK

// サービスを有効化
$ sudo systemctl enable goaccess

// サービス起動
$ sudo systemctl start goaccess

// サービス状態確認
$ sudo systemctl status goaccess
● goaccess.service - Goaccess Web log report.
Loaded: loaded (/etc/systemd/system/goaccess.service; enabled; vendor preset: enabled)
Active: active (running) since 月 2018-08-20 16:46:27 JST; 4h 5min ago
Main PID: 91584 (goaccess)
Tasks: 3
Memory: 3.7M
CPU: 1min 7.536s
CGroup: /system.slice/goaccess.service
mq91584 /usr/local/bin/goaccess -a -g -f /var/log/nginx/access.log -o /usr/share/nginx/html/report.html -

8月 20 16:46:27 MainServer systemd[1]: Started Goaccess Web log report..

起動できたら先ほどのURLにアクセスしてみましょう
きちんと解析画面が表示されれば設定完了です。

 

あとは必要であればアクセス制限を設けるなどしてください。

2018年4月22日

1つのサーバーでMastodonとPleromaを運用すると相互にフォローできない件

Filed under: Docker,Mastodon,OSS,オープンソース — ranpei @ 8:31 PM

うちの鯖ではDockerで構築したMastodonとPleromaとMisskeyの各インスタンスをVirtualHostでドメインごとに振り分ける運用をしています。

 

ただ、外部のインスタンスとはフォローし合えるのに内部のインスタンス同士ではフォローできずに困っておりました。

 

で、原因を探ったら以下の手順を踏むことで回避できました。

■回避方法

  1. DNSやhostsを使って名前解決できるようにする。
  2. Mastodonのソースをいじる。

 

順に説明していきます。

 

1.DNSやhostsを使って名前解決できるようにする。

まあ、これは真っ先に疑うことですよね^^;

LAN内部からドメインでアクセスするためには内部DNSを構築するかhostsを書き換えなければいけません。

うちは内部DNSを構築済みだったためこいつに設定を追加するだけで済みました。

そして、相互に名前解決できるようになったのですがこれだけでは不十分という・・・・

(一応Mastodonの検索欄で”@名前@ドメイン”で検索した際のエラーが「503 Remote data could not be fetched」→「422 Mastodon::HostValidationError on ドメイン」と変化しました)

 

 

2.Mastodonのソースをいじる。

この「422 Mastodon::HostValidationError」ってエラーについて調べてみてもよくわかんない(422ってWebDav拡張のステータスらしいですが・・・)

しょうがないのでMastodonのソースを見て「Mastodon::HostValidationError」がスローされている箇所を見てみると

app/lib/request.rb(135行目)に気になる部分を発見。

        Addrinfo.foreach(host, nil, nil, :SOCK_STREAM) do |address|
          begin
            raise Mastodon::HostValidationError if PrivateAddressCheck.private_address? IPAddr.new(address.ip_address)
            return super address.ip_address, *args
          rescue => e
            outer_e = e
          end
        end

これはプライベートアドレスの場合は問答無用にHostValidationErrorにしている??

 

で、PrivateAddressCheckについて調べてみるとconfig/environments/development.rbでわざわざfalseを返すように書き換えを行っていました。

ということはここのチェックでfalseとなるようにすればいいのでは??っと思いconfig/environments/production.rb側に以下の記載を追記。

module PrivateAddressCheck
 def self.private_address?(*)
 false
 end
end

 

そしてDockerコンテナをビルドしなおしてみると・・・・


$ docker-compose build web
$ docker-compose up -d

無事検索欄で”@名前@ドメイン”で検索してもちゃんとアカウントが表示されるようになりましたv^^v

 

 

とりあえずフォローできない問題は解決したんですが以下の2つが気になる。。。

  1. Mastodonはなぜわざわざプライベートアドレスをはじくようにしているのか?
  2. この対応の仕方で不都合が起きることはないのか?

そんなわけでこの対処方法は自己責任で行ってください。

2018年2月9日

Mastodonでリモートフォローが「承認待ち」になる場合の対処方法

Filed under: apache,Docker,Mastodon — ranpei @ 9:58 PM

2月初めごろからかな?(実はもっと前からあって表面化したのかそれぐらいかもしれませんが)

フォローすると「承認待ち」のステータスになり、

連合にも相手の最新のトゥートが出てこないなどの弊害が多数発生していました。

 

デバッグモードでログを追ったり、Mastodonのソースを読んだりしていろいろ調べましたましたが

結局Nginxの設定の問題だと分かったため、情報共有の目的でここに書かせていただきます。

 

 

■問題の設定

・変更前

ssl_certificate /etc/letsencrypt/live/mstdn-jp.site/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mstdn-jp.site/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mstdn-jp.site1/chain.pem;

・変更後

ssl_certificate /etc/letsencrypt/live/mstdn-jp.site/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mstdn-jp.site/privkey.pem;
#ssl_trusted_certificate /etc/letsencrypt/live/mstdn-jp.site1/chain.pem;

ssl_trusted_certificateの設定をなくしただけですね。

(そもそもssl_trusted_certificateに指定する証明書間違ってるって突っ込みはなしでお願いします;;)

 

■なぜこれで治ったのか?

実は明確な原因はわかっていません;;

 

ただソースを見る限りActivityPubはSSLを基盤としているため証明書の評価を行っているようなんです。

その評価の過程でActivityPubでのやり取りが途中で止まってしまっていたのでは?と疑っています。

 

 

何はとも本来非公開ユーザーをフォローした場合にしかありえない「承認待ち」が

公開ユーザーでも発生するって場合はSSL証明書を疑って見た方がいいみたいです。

 

Older Posts »

Powered by WordPress