【障害切り分けのコツはまずは森を見ること！】Gitlabのpushエラー、原因は（恐らく？）buffalo製ルータだった話

お久しぶりですにゃ。
やらなきゃいけない事があるからと、”優先度の低いものをする時間をマストタスクに割り当てよう”と考えながら
、結局マスト作業も先延ばしになり帳尻合わせが大変になる時空を生きて21年目の私です😢

実はこの間に、所属している会社のブログも1ページながら担当させていただきましたねこ！業務内容とおすすめ焼酎４選という内容なので、
良かったら探してみて欲しいぎょぴ！！
（さすがにネコ語は自重しましたぎょぴぼー）
貴重な経験をさせてくださった弊社の担当者様、ありがとうございますにゃー！

久しぶりの投稿ということで前置きが長くなってしまいましたが、
今回は自宅で特定の通信がハングアップしてしまったときのことを綴りますぴょん。
※解決法とういうよりは、ハチャメチャに慌ててる私をご覧いただく記事となります。

v目次にゃv

1.今回起こった問題
2.一旦バックグラウンド
3.対処１
4.対処２
5. 切り分け
6. 今回の件から私が得るべき教訓は…
7. エンドタイトル

今回起こった問題

自宅クライアントPCからドメインでGitlabへ200MB付近の容量ファイルをgit pushすると

error: RPC failed; curl 56 Recv failure: Connection was reset
fatal: The remote end hung up unexpectedly

とのエラーが出てpushできない。※今回は19MBのサイズでエラー出ました
どうやらサイズ制限にかかり、正常にpushできていないみたい。
※ファイルサイズが小さいものは問題なくpushできます。

〇　5KB
✖　19MB

一旦バックグラウンド

唐突ですが、当時の自宅の簡単な構成を…

Windowsサーバより外の構成は私関与していなかったので、聞き伝えでの図ですが…
今回、外部からWebサーバにアクセスできるようにbuffaloルータでポート開放されていますうさぎ～。

また、CentOS内部では、80番ポートはプロジェクト管理ソフトWebGUIへ（Apache）
GitLabはパッケージ内包のNginxで動いています。
hoge/projectsとhoge/gitlabでサブディレクトリにして、Apaceでリバースプロキシ設定で運用していますきんぎょ～。
今回アクセスする経路はドメイン指定するので1度インターネット抜けしてからLAN内にあるサーバに戻ってくる形です。（混乱する要因の1つ）
この辺の詳細は省きます。わけわかランボルギーニ～(^^♪＜ふんっ！ふんっ！

対処１

原因を調べたところ、GItLab側（Nginx）で一定値を超えるものは制限をかけているらしい。（そもそも大容量通信を想定していない）
早速、ネットに記載されていた対処法を試すねこ！

まずはクライアント側でバッファを増やす設定をするにゃ

git config --global http.postBuffer 524288000

次にサーバ側のＧitlabのサイズ制限を変更するために、Nginxのconfigに追記するぎょぴぼー。

client_max_body_size 200M

その後、各ソフトとサーバーを再起動っぽ！
。
。
。
同じエラーが返ってくる…

対処２

根気強くネットで解決策をさがすと、”プロキシを挟まずに直でGitlabにつないだらいけた！！”との記事を発見！
バックグラウンドを見ていただくと分かると思いますが、自宅構成では
クライアントからGitlabに行く際に、リバースプロキシを介しています。
しかし、リバースプロキシを使わないと、Gitlabかプロジェクト管理GUIのどちらか一方しかアクセス出来なくなりますぴょん…
もちろん、URLでポート指定すればよいのですが、ユーザ側の負担が増えるため却下ですにゃ…
というか、そもそもApacheにデフォルトでサイズ制限はないらしい！！（もしかしたらという事もあるので一応設定をいろいろ試しました）

切り分け

ここまで、サーバ側、もしくはクライアントの設定を疑い試行錯誤してきましたが、一向に解決しないため、
サーバ内だけでなく全体を見て切り分けを行いましたきんぎょ。
通常なら切り分けを最初にするべきですが、ネット上に同じ問題に直面している方がおり、
さらに解決策まで載っているという事で先入観を持ってしまったのが私の敗因ですねこ…

まずはリバースプロキシが原因かどうかを確認するため、
新しくテスト仮想サーバをつくり、Gitlabだけ構築します。
Gitlabは設定を変更せず、リポジトリだけ作成し、大容量push時にエラーを返す状態を再現します。
ドメインを紐づけるのはめんどくさかったので、プライベートIPで開くようにしました。

↓リポジトリパス↓

http:\192.168.100.101/gitlab/piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOKですね
〇　19MBのデータ　←え！？pushできた！！！！

ということは、GitlabやNginxは問題なし。リバースプロキシが怪しい…
前段階でリバースプロキシは違うと踏んでただけに驚きました。

より本番環境に近い（外部からのアクセス）挙動も確認したいので、一応ドメインとIPを紐づける（もちろん本番環境のIPは重複を避け変更しておく）
クライアント側でリポジトリのパスをドメイン指定に変更
↓リポジトリパス↓

http:\hogehoge.nk/gitlab.piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOK
✖　19MBのデータ　 ←あれ、いつものエラーで通らない…💦

小さいファイルは通っているのでDNSの根本的な間違えはなさそう…
今回はリバースプロキシは設定していないので、リバースプロキシのせいでエラーが出るわけではなさそう
もしや、wanを抜ける過程で失敗している？？

テスト仮想サーバを閉じ、本番サーバのIPとドメインを紐づけ直して再度検証

###push 結果↓
〇　5KBのデータ　　←小さいのは通った！
✖　19MBのデータ　 ←通らない

この場合、以下の2つ範囲で考えることが出来ますね。
①プロバイダ側で何かしら制限がある（これだったらお手上げです😢）
②自分の管轄範囲のNWで問題がある

想定できる原因
・大容量通信は弾いている
　→Youtube等の大容量のデータはup,down共に正常に疎通可能。おそらく違う。

・特定プロトコルの大容量データを弾いている
　→gitの仕様詳細まで分からず、未検証。（今回はサイズによらずHTTPを使っているはず）

・十分な帯域が確保できず、通信量を絞っている
　→サーバ側のタイムアウト時間も延長したがダメ

Lanでは繋がり、Wanでは繋がらない（小さいデータは繋がるが）という事で、私の手が届く1番Wan側のbuffaloルータを詳しく見てみます。
設定を覗いた感じ、QoSが設定してあるわけでもなく、問題はなさそう。
機器固有の設定は不明なので、我が家にあるFortiGateに置き換えることにしたにゃ！

ついでなので、セグメント別けしました。（NW図の構成が甘くてすみません）

FortiGateの設定を行い、接続確認をしました。
↓リポジトリパス↓

http:\hogehoge.nk/gitlab.piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOK
〇　19MBのデータ　 ←無事に通った！

通常利用が想定されるWanを介しての大小データのpushに成功したのにゃ！！

今回の件から私が得るべき教訓は…

まずは、今回、問題解決に至るまでのネックポイント
・ネット記事に、同一サーバにWebサーバを同時導入（リバースプロキシ使用）例が少ない
・GitHubの方がユーザが多くGitlabはどちらかといえば少数派なため、なぜかGithubの記事に案内される
・Hyper-vよりDockerを使用している例が多いため、解決法がマッチしない
・buffaloルータの仕様を理解できていない

以上を踏まえ、今回の件から私が得るべき教訓は、全体を見て切り分けをしっかりしよう！ということだ。

↓今回の切り分け例↓
サーバサイド
・リバースプロキシがおかしい
・Gitlabがおかしい
・Nginxがおかしい
・ポートやファイアウォールの設定がうまく機能していない
その他物理
・クライアントの設定ミス
・物理機器の故障、謎仕様
ネットワークサイド
・Wan側がおかしい
・Lan側がおかしい
・NW境界部がうまく機能していない

てっきりサーバ側だと思い込んでそちらばかり対応にあたったのがダメでした。
今回はネットワークサイド、NW境界部（buffaloルータの仕様なのかな？）があたりでしたね…
結局、最たる原因は仕様が不明のため、buffaloさんには問い合わせて回答をいただく予定です。

エンドタイトル

今回は個人的にいろいろな事象が複雑に面倒くさく絡まっていたのが、解決への道を妨げるものでした。
リソースの関係上仕方がないとはいえ、シンプルな設計の重要さを身をもって学びました。み〇ほ銀行のジャングルシステムがいい例ですね。いや、悪い例か…
複雑なものをどのようにまとめようか思考しながら筆をとった結果、語尾も中途半端になる始末…（しかも非常に読みづらくて申し訳ない）

今回はここまで🐾
自宅にて、焼酎のお湯割りを飲みながら…。

次回も頑張るきんぎょー…

編集後記

私のCrieit記事では、私個人の思ったことや考えを色濃く記事に出しています。qiitaやStack Overflowのような解決を求める記事や、参考となる記事とは違い、実際に困難（？）に直面しているへっぽこ技術者の狭い視野やドキドキを臨場感のある雰囲気を含め楽しんで屍を越えて下されば幸いです。

せっかくなので、次回あたりFortiGateの設定などもご紹介できればよいですにゃ～…