音楽を紹介すらしない無能

音楽を紹介すらしない無能

今後は旅日記とか、バイク関連も書くと思う

へいとんのネスペ参考資料保管庫

VPNサーバーが割り当てるIPアドレスとモバイルWiFiが割当てるIPアドレスは重複しては行けない理由について

重点対策 p124 H28 A PI 問2

IPアドレスNICごとに割り当てられるため、重複しても良いのではないか?と考えていたが違った。

そもそもIPアドレスの重複以前に、NICごとにサブネットが違っている必要がある。

なぜならそもそもPCはルーティングテーブルに従って通信先を決める。

複数NICがあってIPアドレスが割り当ててられてても、ルーティングテーブルは端末に1つということが重要。

ルーティングテーブルが1つ = サブネットを分けないとNICを使い分けることが出来ない。

下記のURLも参考になる。

NICが複数ある場合には、サブネットも分けなければならない。同じエントリが複数ある状態になり、どちらのNICから送信して良いか分からなくなるからだ。

使用したことのあるVPN製品が全て仮想NICを割り当てると、物理NICを殺すものばかりだったので、それ以外(複数NICを同時にしようできる仕様のもの)もあると理解しておく。

下記のサイトも参考になる。ちょうど仮想NICと物理NICのサブネットが重なった時にどのようになるかが書いてある。(物理NICと仮想NICで同じセグメントのIPアドレスが割り当てられたPCでは、NICの優先順位によって、どちらかが無視されます。)

後日有線と無線どちらもIPを割り当てたPCのルーティングテーブルを確認したが、やはり1つだった。デフォゲは入れた方だけが現れるみたいである。

それぞれのセグメントごとに下記のアドレスが乗っているみたいだ。

  1. ネットワークアドレス
  2. 自分のIPアドレス
  3. ブロードキャストアドレス

f:id:mirrorino:20240228093322p:image

ちなみに設定すれば一応デフォゲは増える。上述の利用でしないが。

f:id:mirrorino:20240228094309p:image

広域イーサのアクセス回線 イーサネット接続にもダークファイバの概念がある話

 

電子署名電子証明書もセットという話

電子署名とは「電子署名電子証明書」が合わさって初めて証明できる。
電子証明書には、電子署名の公開鍵と認証局による署名が書かれている。

f:id:mirrorino:20240227202648j:imagewww.jipdec.or.jp

復号プロキシが何をしているのかの整理

TLSを終端するのはプロキシが中身を見るためである。
だがそうなるとクライアント側ではWeb鯖を認証する事ができない。
そのため、サーバー証明書における署名前証明書のだいたいの部分をそのまま使い、署名と公開鍵をプロキシサーバーのものに入れ替える。
そうなると改造した証明書だから当然弾かれるわけだから、端末は異変に気付くが、端末にはプロキシ鯖のルート証明書が存在しているため、プロキシサーバーは正しい証明書として認識してしまう。

nw.seeeko.com

pansetech.net

プライマリDNSはゾーンの中に1つという話

当たり前と言えば当たり前だが、ゾーン情報の整合性を保つためにプライマリDNSは1つしかない

プライマリDNSセカンダリDNSが1:1ではないという点にも注意

また、スタブリゾルバからはプライマリ・セカンダリの区別はなく並列に見えている。

セカンダリはコンテンツDNSである+プライマリからコピーを受けるもの、プライマリはコピーを送るものと考える

この世にセグメントを越えられるブロードキャストなんて存在しない話

リミテッドだろうがルーターは越えられない。

ブロードキャストはL2の概念である。

ちなみに他セグにブロードキャストもルーティングできる。他セグルータにたどり着くまではユニキャスト

 

これ全部おぼえる

XFFヘッダはIPアドレスを複数記載できる話

TLS通信ではサーバ認証で使う鍵ペアと通信を流す鍵ペアは違う

今まで「セッションごとに公開鍵と秘密鍵のペアを作り直す」という表現に、「いやお前それサーバ証明書の公開鍵って……???」となっていたものについて、なんとなくそうじゃないかなって思ってたことを、クラウドフレアさんが書いてくれた。f:id:mirrorino:20240307105311j:image

f:id:mirrorino:20240307105320j:image

サーバ証明書の鍵ペアは最初の認証のみ使い、後は別の鍵ペアを使用して暗号通信を行う。

https://www.cloudflare.com/ja-jp/learning/ssl/keyless-ssl

もうちょい詳しい関連情報はこっち

お互いの公開鍵と秘密鍵を計算すると同じ情報ができるのはそういうもんだって話

f:id:mirrorino:20240308095435j:image

SSHの認証の時に、相手の一時公開鍵と自分の一時秘密鍵を計算すると、クライアント・サーバーどちらも同じものが出来上がるのがどうしても意味不明だったが、どうやらそういうもんとして覚えた方が良いらしい。