tag:crieit.net,2005:https://crieit.net/tags/%E3%81%A3%E3%81%BD%EF%BC%81/feed Crieitでタグ「っぽ！」に投稿された最近の記事 2022-02-24T23:44:23+09:00 https://crieit.net/tags/%E3%81%A3%E3%81%BD%EF%BC%81/feed tag:crieit.net,2005:PublicArticle/18124 2022-02-24T23:29:56+09:00 2022-02-24T23:44:23+09:00 https://crieit.net/posts/Gitlab-push-buffalo <p>お久しぶりですにゃ。<br /> やらなきゃいけない事があるからと、”<strong>優先度の低いものをする時間をマストタスクに割り当てよう</strong>”と考えながら<br /> 、<strong>結局マスト作業も先延ばしになり帳尻合わせが大変になる</strong>時空を生きて21年目の私です😢</p> <p>実はこの間に、所属している会社のブログも1ページながら担当させていただきましたねこ！業務内容とおすすめ焼酎４選という内容なので、<br /> 良かったら探してみて欲しいぎょぴ！！<br /> （さすがにネコ語は自重しましたぎょぴぼー）<br /> 貴重な経験をさせてくださった弊社の担当者様、ありがとうございますにゃー！</p> <p>久しぶりの投稿ということで前置きが長くなってしまいましたが、<br /> <strong>今回は自宅で特定の通信がハングアップしてしまったときのこと</strong>を綴りますぴょん。<br /> ※解決法とういうよりは、ハチャメチャに慌ててる私をご覧いただく記事となります。</p> <hr /> <h4 id="v目次にゃv"><a href="#v%E7%9B%AE%E6%AC%A1%E3%81%AB%E3%82%83v">v目次にゃv</a></h4> <p>1.今回起こった問題<br /> 2.一旦バックグラウンド<br /> 3.対処１<br /> 4.対処２<br /> 5. 切り分け<br /> 6. 今回の件から私が得るべき教訓は…<br /> 7. エンドタイトル</p> <hr /> <h4 id="今回起こった問題"><a href="#%E4%BB%8A%E5%9B%9E%E8%B5%B7%E3%81%93%E3%81%A3%E3%81%9F%E5%95%8F%E9%A1%8C">今回起こった問題</a></h4> <p>自宅クライアントPCからドメインでGitlabへ200MB付近の容量ファイルをgit pushすると</p> <blockquote> <p>error: RPC failed; curl 56 Recv failure: Connection was reset<br /> fatal: The remote end hung up unexpectedly</p> </blockquote> <p>とのエラーが出てpushできない。※今回は19MBのサイズでエラー出ました<br /> どうやら<strong>サイズ制限にかかり、正常にpushできていない</strong>みたい。<br /> ※ファイルサイズが小さいものは問題なくpushできます。</p> <p>〇　5KB<br /> ✖　19MB</p> <hr /> <h4 id="一旦バックグラウンド"><a href="#%E4%B8%80%E6%97%A6%E3%83%90%E3%83%83%E3%82%AF%E3%82%B0%E3%83%A9%E3%82%A6%E3%83%B3%E3%83%89">一旦バックグラウンド</a></h4> <p>唐突ですが、当時の自宅の簡単な構成を…<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f062177aebea260.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f062177aebea260.png?mw=700" alt="image.png" /></a></p> <p>Windowsサーバより外の構成は私関与していなかったので、聞き伝えでの図ですが…<br /> 今回、外部からWebサーバにアクセスできるように<strong>buffaloルータでポート開放</strong>されていますうさぎ～。</p> <p>また、CentOS内部では、80番ポートはプロジェクト管理ソフトWebGUIへ（Apache）<br /> GitLabはパッケージ内包のNginxで動いています。<br /> <strong>hoge/projects</strong>と<strong>hoge/gitlab</strong>で<strong>サブディレクトリ</strong>にして、<strong>Apaceでリバースプロキシ設定で運用</strong>していますきんぎょ～。<br /> 今回アクセスする経路はドメイン指定するので<strong>1度インターネット抜けしてからLAN内にあるサーバに戻ってくる</strong>形です。（混乱する要因の1つ）<br /> この辺の詳細は省きます。わけわかランボルギーニ～(^^♪＜ふんっ！ふんっ！</p> <hr /> <h4 id="対処１"><a href="#%E5%AF%BE%E5%87%A6%EF%BC%91">対処１</a></h4> <p>原因を調べたところ、GItLab側（Nginx）で<strong>一定値を超えるものは制限</strong>をかけているらしい。（そもそも大容量通信を想定していない）<br /> 早速、ネットに記載されていた対処法を試すねこ！</p> <p>まずは<strong>クライアント側でバッファを増やす設定</strong>をするにゃ</p> <pre><code>git config --global http.postBuffer 524288000 </code></pre> <p>次に<strong>サーバ側のＧitlabのサイズ制限を変更す</strong>るために、Nginxのconfigに追記するぎょぴぼー。</p> <pre><code>client_max_body_size 200M </code></pre> <p>その後、各ソフトとサーバーを<strong>再起動</strong>っぽ！<br /> 。<br /> 。<br /> 。<br /> 同じエラーが返ってくる…</p> <hr /> <h4 id="対処２"><a href="#%E5%AF%BE%E5%87%A6%EF%BC%92">対処２</a></h4> <p>根気強くネットで解決策をさがすと、”<strong>プロキシを挟まずに直でGitlabにつないだらいけた</strong>！！”との記事を発見！<br /> バックグラウンドを見ていただくと分かると思いますが、自宅構成では<br /> <strong>クライアントからGitlabに行く際に、リバースプロキシを介しています</strong>。<br /> しかし、リバースプロキシを使わないと、Gitlabかプロジェクト管理GUIのどちらか一方しかアクセス出来なくなりますぴょん…<br /> もちろん、URLでポート指定すればよいのですが、ユーザ側の負担が増えるため却下ですにゃ…<br /> というか、そもそも<strong>Apacheにデフォルトでサイズ制限はない</strong>らしい！！（もしかしたらという事もあるので一応設定をいろいろ試しました）</p> <hr /> <h4 id="切り分け"><a href="#%E5%88%87%E3%82%8A%E5%88%86%E3%81%91">切り分け</a></h4> <p>ここまで、サーバ側、もしくはクライアントの設定を疑い試行錯誤してきましたが、一向に解決しないため、<br /> サーバ内だけでなく全体を見て切り分けを行いましたきんぎょ。<br /> 通常なら切り分けを最初にするべきですが、ネット上に同じ問題に直面している方がおり、<br /> さらに解決策まで載っているという事で<strong>先入観を持ってしまったのが私の敗因</strong>ですねこ…</p> <p>まずはリバースプロキシが原因かどうかを確認するため、<br /> 新しくテスト仮想サーバをつくり、Gitlabだけ構築します。<br /> Gitlabは設定を変更せず、リポジトリだけ作成し、大容量push時にエラーを返す状態を再現します。<br /> ドメインを紐づけるのはめんどくさかったので、プライベートIPで開くようにしました。</p> <p>↓リポジトリパス↓</p> <blockquote> <p>http:\192.168.100.101/gitlab/piyopiyo.git</p> </blockquote> <pre><code>###push 結果↓ 〇　5KBのデータ　　←小さいファイルはOKですね 〇　19MBのデータ　←え！？pushできた！！！！ </code></pre> <p>ということは、<strong>GitlabやNginxは問題なし</strong>。リバースプロキシが怪しい…<br /> 前段階でリバースプロキシは違うと踏んでただけに驚きました。</p> <p>より本番環境に近い（外部からのアクセス）挙動も確認したいので、一応ドメインとIPを紐づける（もちろん本番環境のIPは重複を避け変更しておく）<br /> クライアント側でリポジトリのパスをドメイン指定に変更<br /> ↓リポジトリパス↓</p> <blockquote> <p>http:\hogehoge.nk/gitlab.piyopiyo.git</p> </blockquote> <pre><code>###push 結果↓ 〇　5KBのデータ　　←小さいファイルはOK ✖　19MBのデータ　 ←あれ、いつものエラーで通らない…💦 </code></pre> <p>小さいファイルは通っているのでDNSの根本的な間違えはなさそう…<br /> 今回はリバースプロキシは設定していないので、リバースプロキシのせいでエラーが出るわけではなさそう<br /> もしや、<strong>wanを抜ける過程で失敗している</strong>？？</p> <hr /> <p>テスト仮想サーバを閉じ、本番サーバのIPとドメインを紐づけ直して再度検証</p> <pre><code>###push 結果↓ 〇　5KBのデータ　　←小さいのは通った！ ✖　19MBのデータ　 ←通らない </code></pre> <p>この場合、以下の2つ範囲で考えることが出来ますね。<br /> <strong>①プロバイダ側で何かしら制限がある（これだったらお手上げです😢）<br /> ②自分の管轄範囲のNWで問題がある</strong></p> <p><del><strong>想定できる原因</strong></del><br /> <del>・大容量通信は弾いている<br /> 　→Youtube等の大容量のデータはup,down共に正常に疎通可能。おそらく違う。</del></p> <p><del>・特定プロトコルの大容量データを弾いている<br /> 　→gitの仕様詳細まで分からず、未検証。（今回はサイズによらずHTTPを使っているはず）</del></p> <p><del>・十分な帯域が確保できず、通信量を絞っている<br /> 　→サーバ側のタイムアウト時間も延長したがダメ</del></p> <p>Lanでは繋がり、Wanでは繋がらない（小さいデータは繋がるが）という事で、私の手が届く1番Wan側のbuffaloルータを詳しく見てみます。<br /> 設定を覗いた感じ、QoSが設定してあるわけでもなく、問題はなさそう。<br /> <strong>機器固有の設定は不明</strong>なので、我が家にある<strong>FortiGateに置き換えることにした</strong>にゃ！<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f0621774bb13a10.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f0621774bb13a10.png?mw=700" alt="image.png" /></a><br /> ついでなので、セグメント別けしました。（NW図の構成が甘くてすみません）</p> <p>FortiGateの設定を行い、接続確認をしました。<br /> ↓リポジトリパス↓</p> <blockquote> <p>http:\hogehoge.nk/gitlab.piyopiyo.git</p> </blockquote> <pre><code>###push 結果↓ 〇　5KBのデータ　　←小さいファイルはOK 〇　19MBのデータ　 ←無事に通った！ </code></pre> <p><strong>通常利用が想定されるWanを介しての大小データのpushに成功したのにゃ！！</strong></p> <hr /> <h4 id="今回の件から私が得るべき教訓は…"><a href="#%E4%BB%8A%E5%9B%9E%E3%81%AE%E4%BB%B6%E3%81%8B%E3%82%89%E7%A7%81%E3%81%8C%E5%BE%97%E3%82%8B%E3%81%B9%E3%81%8D%E6%95%99%E8%A8%93%E3%81%AF%E2%80%A6">今回の件から私が得るべき教訓は…</a></h4> <p>まずは、今回、問題解決に至るまでのネックポイント<br /> ・ネット記事に、同一サーバにWebサーバを同時導入（リバースプロキシ使用）例が少ない<br /> ・GitHubの方がユーザが多くGitlabはどちらかといえば少数派なため、なぜかGithubの記事に案内される<br /> ・Hyper-vよりDockerを使用している例が多いため、解決法がマッチしない<br /> ・buffaloルータの仕様を理解できていない</p> <p>以上を踏まえ、<strong>今回の件から私が得るべき教訓は、全体を見て切り分けをしっかりしよう！ということだ。</strong></p> <p>↓今回の切り分け例↓<br /> <strong>サーバサイド</strong><br /> ・リバースプロキシがおかしい<br /> ・Gitlabがおかしい<br /> ・Nginxがおかしい<br /> ・ポートやファイアウォールの設定がうまく機能していない<br /> <strong>その他物理</strong><br /> ・クライアントの設定ミス<br /> ・物理機器の故障、謎仕様<br /> <strong>ネットワークサイド</strong><br /> ・Wan側がおかしい<br /> ・Lan側がおかしい<br /> ・NW境界部がうまく機能していない</p> <p>てっきりサーバ側だと思い込んでそちらばかり対応にあたったのがダメでした。<br /> 今回は<strong>ネットワークサイド、NW境界部（buffaloルータの仕様なのかな？）があたり</strong>でしたね…<br /> 結局、最たる原因は仕様が不明のため、buffaloさんには問い合わせて回答をいただく予定です。</p> <h4 id="エンドタイトル"><a href="#%E3%82%A8%E3%83%B3%E3%83%89%E3%82%BF%E3%82%A4%E3%83%88%E3%83%AB">エンドタイトル</a></h4> <p>今回は個人的にいろいろな事象が複雑に面倒くさく絡まっていたのが、解決への道を妨げるものでした。<br /> リソースの関係上仕方がないとはいえ、シンプルな設計の重要さを身をもって学びました。み〇ほ銀行のジャングルシステムがいい例ですね。いや、悪い例か…<br /> 複雑なものをどのようにまとめようか思考しながら筆をとった結果、語尾も中途半端になる始末…（しかも非常に読みづらくて申し訳ない）</p> <p>今回はここまで🐾<br /> 自宅にて、焼酎のお湯割りを飲みながら…。</p> <p>次回も頑張るきんぎょー…</p> <h5 id="編集後記"><a href="#%E7%B7%A8%E9%9B%86%E5%BE%8C%E8%A8%98">編集後記</a></h5> <p>私のCrieit記事では、私個人の思ったことや考えを色濃く記事に出しています。qiitaやStack Overflowのような解決を求める記事や、参考となる記事とは違い、実際に困難（？）に直面しているへっぽこ技術者の狭い視野やドキドキを臨場感のある雰囲気を含め楽しんで屍を越えて下されば幸いです。</p> <p>せっかくなので、次回あたりFortiGateの設定などもご紹介できればよいですにゃ～…</p> keito_woood tag:crieit.net,2005:PublicArticle/17634 2021-09-05T02:24:22+09:00 2021-09-05T02:30:12+09:00 https://crieit.net/posts/NAT-NAT <p>おつかれちゃ～ん！！<br /> ども！私だにゃ～ん。<br /> 友達たちに「<strong>心霊スポットにドライブ行こう！</strong>」と提案したのですが、NGもらいました…<br /> お化けが怖いのか、それとも私の運転が怖いのか…</p> <p>さて、今回は理解に躓く<strong>双方向NAT</strong>につい<strong>て自分なりにキャッチーに分かりやすく</strong>した（つもり）ので、いつか私が未来の新卒さんたちに教えるときに楽できるように、ここで載せっちゃうぴょん♪</p> <hr /> <h4 id="v目次にゃv"><a href="#v%E7%9B%AE%E6%AC%A1%E3%81%AB%E3%82%83v">v目次にゃv</a></h4> <p>1.NATについての感想<br /> 2.躓きやすいポイントと原因<br /> 3.対策<br /> 4.NAT攻略～勝利のカギは地形選択にあり編～<br /> 5.NAT攻略～双方向NATとは男のプライドを守るためにあるのだ編～<br /> 6.まとめ</p> <hr /> <h4 id="NATについての感想"><a href="#NAT%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E6%84%9F%E6%83%B3">NATについての感想</a></h4> <p><strong>NATってややこしい</strong>！というのが始めてNATを行った際の感想うさ～。<br /> NAT単体でもそう感じるのに、適用するインターフェース、インサイド、アウトサイド、<br /> さらには、＋HSRP（VRRP）に＋BGPと難しくなるばかり…<br /> ということで、NATを攻略法を記述してきますぎょぴ～。</p> <hr /> <h4 id="躓きやすいポイントと原因"><a href="#%E8%BA%93%E3%81%8D%E3%82%84%E3%81%99%E3%81%84%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%81%A8%E5%8E%9F%E5%9B%A0">躓きやすいポイントと原因</a></h4> <p>せっかくなので、<strong>どこをなぜ躓くのか</strong>挙げたいとおもうきんぎょ～。<br /> 分からい時に、その時の考えや躓きを残すことは大事ねこ～。理解したときには、分からなかった自分には戻れないので…</p> <p><strong>躓きポイント</strong><br /> ・結局何がしたいのか不明<br /> ・インサイド側送信元IP、宛先IPーーアウトサイド側送信元IP、宛先IPとどれがなんだが…<br /> ・双方向NATする意味は？<br /> ・そもそも何故、NATでIPを書き換えるの？？</p> <p><strong>原因</strong><br /> ・グローバルIPとプライベートIPの理解が足りていない<br /> ・でてくるアドレスが区別できていない<br /> ・頭だけで考えている</p> <p>書いていて、思ったより資料が必要そうで苦笑しているうさ～。<br /> と筆者のボヤキはさておき、対策を考えるぴょん！</p> <hr /> <h4 id="対策"><a href="#%E5%AF%BE%E7%AD%96">対策</a></h4> <p>あがった問題点からザックリと対策を書き出してみるキツネ。<br /> <strong>対策</strong><br /> ・NATの必要性を考える！（グローバルアドレスとプライベートアドレスについて）<br /> ・どのアドレスをどうしたいのか区別をつける！<br /> ・頭だけで演算せず、書き出す！<br /> ・イメージをつかむ！</p> <hr /> <h4 id="NAT攻略～勝利のカギは地形選択にあり編～"><a href="#NAT%E6%94%BB%E7%95%A5%EF%BD%9E%E5%8B%9D%E5%88%A9%E3%81%AE%E3%82%AB%E3%82%AE%E3%81%AF%E5%9C%B0%E5%BD%A2%E9%81%B8%E6%8A%9E%E3%81%AB%E3%81%82%E3%82%8A%E7%B7%A8%EF%BD%9E">NAT攻略～勝利のカギは地形選択にあり編～</a></h4> <p>古代中国のすごい人は<br /> 「<strong>勝つためには、兵力や課金だけでなく、有利な地形を選ぶべし</strong>！」<br /> とおっしゃっていましたきんぎょ～。（ソースは動画サイトのゲーム広告です）<br /> NATも、まずは地盤を固めていくのが勝利（？）の秘訣ですぞ～こうめいこうめい～。</p> <p>まずはNATの必要性についてねこ～。<br /> 下の図はPCでどこかのサーバにアクセスできる図だぴょん！<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f0613395fec458f.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f0613395fec458f.png?mw=700" alt="image.png" /></a></p> <p>ここでは<strong>LANにあるPCがインターネットを介してサーバにアクセスする</strong>ことだけを汲み取ってくださいぎょぴ～。<br /> 特に細かいIPアドレスは覚えなくてOK<br /> （IPアドレスは適当に振っています）</p> <hr /> <p>次にインターネット側から見た同じ図ですキツネ！<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061338e96dc1a0.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061338e96dc1a0.png?mw=700" alt="image.png" /></a></p> <p><strong>インターネットから見るとLAN側の複数あるPCは見えていませんね？</strong><br /> 基本的に<strong>1つのローカルエリアに1つのグローバルアドレス</strong>があるイメージです。（厳密には違いますが、今回はそのていで進めます）<br /> つまり、<strong>あるエリアからあるエリアまで通信するためにはグローバルアドレスを使いま</strong>すうさ～。</p> <p>しかし、実際には青いエリアにはPCは2台以上ありますよね？<br /> ということは、PCにグローバルアドレス200.10.0.20を振ってあげると<strong>1台しか通信できない</strong>ことになります。<br /> これでは困りますうさぎね。自宅で考えるとPCかスマホのどちらかでしかインターネットにアクセス出来ない状況です。（IPv4アドレスは数に限りがあるので端末1台1台にグローバルアドレスを振ることはできません）<br /> これを<strong>解決できるのがNATという技術</strong>ですねこ～！</p> <p>ここで重要なのは<strong>LAN内のPCやスマホに振ってあるプライベートアドレスをグローバルアドレスに変換</strong>するという事です！<br /> いいかい。深く考えるな？ここではインターネットに出るためには<strong>端末のプライベートアドレスをグローバルアドレスに変換しなきゃいけない</strong>ことだけを頭に入れるんだ。<br /> （もし、ここでどうしても頭を抱えるようならば、グローバルアドレス、プライベートアドレスの理解が必要です。その場合は各自で調べてください）</p> <p>ちなみに複数の端末で通信をさせたいときはNAPT、PATというNATの技術を使いますぎょぴ。</p> <hr /> <h4 id="NAT攻略～双方向NATとは男のプライドを守るためにあるのだ編～"><a href="#NAT%E6%94%BB%E7%95%A5%EF%BD%9E%E5%8F%8C%E6%96%B9%E5%90%91NAT%E3%81%A8%E3%81%AF%E7%94%B7%E3%81%AE%E3%83%97%E3%83%A9%E3%82%A4%E3%83%89%E3%82%92%E5%AE%88%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E3%81%82%E3%82%8B%E3%81%AE%E3%81%A0%E7%B7%A8%EF%BD%9E">NAT攻略～双方向NATとは男のプライドを守るためにあるのだ編～</a></h4> <p>お次は具体的にNATが何をするのかですうさぎ～。<br /> この記事をご覧の方は、NATの基本的なことは調べ済みだと思うので、必要な部分だけ掻い摘みます。</p> <p>NATは<strong>アドレスを書き換える</strong>ことが出来ます！<br /> 今回は<strong>双方向NAT</strong>ということなので、<strong>送信元IPと宛先IPの両方を書き換えます</strong>。<br /> 双方向NATをする意味ですが、<br /> <strong>お客さんにサーバの本当のアドレスを知られない、<br /> サーバ側もお客さんの本当のアドレスを知ることができない</strong><br /> という側面があります。<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061339c02e2d33.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061339c02e2d33.png?mw=700" alt="image.png" /></a><br /> イメージで言うと、<strong>TwitterのDM</strong>だぴょんぴょん。<br /> お互いに本人のことは分からないけど、届けたい人に届けたいメッセージは届きますうさ～。<br /> ニャン子さん宛のメッセージは届けることが出来るけど、ニャン子さんは実はおじさんだなんて知る由もありませんね。</p> <hr /> <p>先程はTwitterでイメージしましたが、もっと実践によった見方をしていきますきんぎょ。</p> <h5 id="送信元NAT"><a href="#%E9%80%81%E4%BF%A1%E5%85%83NAT">送信元NAT</a></h5> <p><a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061339e9640163.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061339e9640163.png?mw=700" alt="image.png" /></a><br /> 送るデータをお父さんとして考えてみます。<br /> 男というのは見栄を張る生き物です。ちゃんねぇにはカッコイイところを見せたい。その気持ちわかります。<br /> この気持ちを心の片隅にご覧いただければと思いますおじ～。</p> <p><a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061339ebc09645.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f061339ebc09645.png?mw=700" alt="image.png" /></a><br /> 父は本当は35年ローンの家から夜の街へ通っていますが、<br /> 夜の街のおねーちゃんには高級なお城から通っていると来た場所を偽ります。<br /> <strong>家→高級お城</strong><br /> これが<strong>送信元NAT</strong>ですっぽ！</p> <hr /> <h5 id="宛先NAT"><a href="#%E5%AE%9B%E5%85%88NAT">宛先NAT</a></h5> <p><a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a1d33ddb4.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a1d33ddb4.png?mw=700" alt="image.png" /></a><br /> 男というのは家族には知られたくない秘密を1つや2つ持っている生き物です。<br /> 秘密は共に死線をくぐり抜けてきた同志にだけ打ち明けます。<br /> ということをご理解の程、続きをご覧ください。</p> <p><a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a26f14a30.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a26f14a30.png?mw=700" alt="image.png" /></a><br /> 父は本当は家から夜の街へ通いますが、大切な家族にはそのことを知られたくありません。<br /> そこで、行き先を会社だと偽ります。<br /> <strong>夜の街→会社</strong><br /> これが<strong>宛先NAT</strong>っぽ！</p> <p>いいですか。ここまでで大事なことは<strong>変換しているのは送信元同士、宛先同士</strong>ですよ。<br /> 決して送信元を宛先へ変換しているわけではありません。<br /> 実際に機器でNATを行うとこの辺りがごちゃ混ぜになりますハト～。</p> <hr /> <h5 id="双方向NAT"><a href="#%E5%8F%8C%E6%96%B9%E5%90%91NAT">双方向NAT</a></h5> <p><strong>双方向NATとは送信元NATと宛先NATの両方をすること</strong>です。<br /> つまり、おねーさんには家を高級お城と偽り、家族には夜の街を会社と偽ります。<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a4034676b.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a4034676b.png?mw=700" alt="image.png" /></a><br /> これが<strong>双方向NAT</strong>っぽ！</p> <p>NATをかけるイメージは下図の通りですハトー。<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a47e0b8c4.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a47e0b8c4.png?mw=700" alt="image.png" /></a><br /> この図をみて違和感を得た方。おそらく、現場でのNATでも違和感をえるでしょう。<br /> そう、この図だと<br /> <strong>NAT前　→　NAT後</strong><br /> となっています。ですが、実際には<br /> <strong>NAT前送信元　→　NAT後送信元<br /> NAT前宛先　　→　NAT後宛先</strong><br /> となります。IPアドレスは数字だけの情報のため、現場だと脳が混乱します。<br /> どのIPアドレスをどのIPアドレスへ変換すべきなのか、<strong>ここを書き出して整理しておくことを推奨</strong>しますねこ～。マジで。</p> <p>NAT前とNAT後をまとめたものが下図です。<br /> <a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a5ad2523a.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a5ad2523a.png?mw=700" alt="image.png" /></a><br /> ちなみにですが、ふつうは送信元、宛先共に、NATする際は同一セグメントにしないので悪しからず。ここはケースバイケースですかにゃー。</p> <hr /> <h4 id="まとめ"><a href="#%E3%81%BE%E3%81%A8%E3%82%81">まとめ</a></h4> <p><a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a6477c4a2.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f06133a6477c4a2.png?mw=700" alt="image.png" /></a></p> <hr /> <h4 id="エンドタイトル"><a href="#%E3%82%A8%E3%83%B3%E3%83%89%E3%82%BF%E3%82%A4%E3%83%88%E3%83%AB">エンドタイトル</a></h4> <p>今回は筆者のミスで、この記事を書いている途中で誤って記事を消してしまいました…<br /> さすがに力尽きてしまい、少々雑な記事になったいます。ごめんなさい。<br /> また、世の中の男性、お父様方、この記事で風評被害をうけてしまうかもしれません。<br /> この場を借りて謝罪申し上げます。<br /> 陳謝👏&Good Luck👍<br /> 家庭円満のためにも、自身へ双方向NATは適用しない事を推奨します。ちゃんねぇーも正直な男のほうが好きだと思いますよ！（）</p> <p>文末になってしまいましたが、NATの適用インターフェースについては、また後日。反響があればという事で…</p> <p>今回はここまで🐾<br /> 自宅にて、終わりを迎えつつある夏を感じながら…。</p> <p>次回も頑張るきんぎょー…</p> keito_woood