Networking

k8s構築日記その３。 過去の奮闘記録。 構築日記その１ 構築日記その２ 実は今まで一回もK8S上でアプリを動かしたことがないという。 これは正直恥ずかしいですね。構築はしたが、動かせはしていないという話だな。勿体無い！！ ってことで、今回は、K8S構築日記その３ということで、構築日記その１と構築日記その２を振り返りつつ、 ちゃんとアプリをクラスタ上で動かせるようにしたいと思います。はい。動かすアプリは、そうです、例の競馬アプリです。 そして、外部に公開して、しかも、インターネットから見えるようにしたいと思う。これができるとまじで最高だぜへへ。 まずは構築から昔の俺が残してくれた手順に従って構築をやります。 クラスター情報 master : controle plane gamma : worker zeta : worker でやりたいと思います。ちなみにマスターのosはraspbianです。 バージョン情報 このサイト を参考にバージョンを決めた。 k8s (kubelet : kubeadm) : 1.27 containerd : 1.7.0 + なので、1.7.2でインストールする。 containerdのarmバイナリ k8sを導入するまとめ 1. containerdを導入。 k8sのv1.25以降は、コンテナエンジンにdockerエンジンを使えません。(理由は、dockerがcriを満たしていないから)。criを満たしてるcontainerdをインストールする必要があります。 containerdのインストールは、githubのリポジトリからできます。同時に、runcとcniもインストールしてださい。 ちなみに、cniは、container network interfaceで、まあ、コンテナのネットワークを操るためのapiですね。 で、そのapiを操るのが、cniプラグイン。で、cniプラグインには、calicoだったり、flannelだったりがあるわけですね。で、プラグインには、3種類のモードがあって、オーバーレイと、ルーティングと、アンダーレイですね。オーバレイを使うことで、別のホスト上にいるコンテナ同士が同じセグメントにいるようになります。 で、だけど、/etc/cni/net.dにはデフォルトのやつ、おかなくて結構です。まったく問題ありませんので、お気になさらず。ということで。 ちなみに、これにはruncも入っているので安心してインストール/ダウンロードしてください。全く問題ないです。 wget https://github.com/containerd/containerd/releases/download/v1.7.20/cri-containerd-cni-1.7.20-linux-arm64.tar.gz mkdir containerd_dir mv cri-containerd-cni containerd_dir tar xvfz cri sudo mkdir /etc/containerd 必要なものを必要なディレクトリに置いてくれるように以下のスクリプトを実行 #!/bin/bash # Define the paths to your installation directories CONTAINERD_BIN_DIR="/usr/local/bin" CONTAINERD_SBIN_DIR="/usr/local/sbin" CONTAINERD_ETC_DIR="/etc/containerd" CONTAINERD_SYSTEMD_DIR="/etc/systemd/system" CONTAINERD_OPT_DIR="/opt/" # Define the source directory where you extracted the Containerd files SOURCE_DIR="/home/ray/containerd_dir" # Move binary files to /usr/local/bin cp -r "$SOURCE_DIR/usr/local/bin/"* "$CONTAINERD_BIN_DIR/" # Move sbin files to /usr/local/sbin cp -r "$SOURCE_DIR/usr/local/sbin/"* "$CONTAINERD_SBIN_DIR/" # Move etc files to /etc/containerd cp -r "$SOURCE_DIR/etc/"* "$CONTAINERD_ETC_DIR/" # Move systemd service file to /etc/systemd/system cp "$SOURCE_DIR/etc/systemd/system/containerd.service" "$CONTAINERD_SYSTEMD_DIR/" # move cni and other utils to opt cp -r "$SOURCE_DIR/opt/containerd" "CONTAINERD_OPT_DIR" cp -r "$SOURCE_DIR/opt/cni" "CONTAINERD_OPT_DIR" # Reload systemd to recognize the new service systemctl daemon-reload echo "Containerd installed successfully." nerdctlも一緒にいんすとる ...

背景 ついにインフラエンジニアになった。インフラエンジニアになったのであれば、インフラ関係を一通りこなせないと話にならないだろう！ というお話です。ということで、クラスタ作って、クラスタがいい感じに運用できるようにいろいろとインフラを構築していこうと思う。 さらに言うと、業務でansibleを使っているので、IaC（インフラストラクチャasコード）を実現したいと思っている。これができればいつでもそのインフラが再現可能になるからね。練習も込みで。 要件 完全に独立したネットワークを構築したいと思っている。そのため、 ルータ が必要。この時、内部ネットワークから外部にアクセスする必要がないよね。だから、natでいいわけだね。 次に、サブネット内でDHCPをしつつ、アドレスの固定を一括で管理したい。 それの実現方法がDHCPを使って、macアドレスとipを対応付けるという方法。 さらに、ネットワーク内で、ipアドレスではなく、ドメイン名でアクセスができるようにしたいので、DNSサーバも立てたい。 最後、K8Sのコントロールプレーンだね。これは作りたい。 K8Sサーバに何を立てるかだけど、とりあえずechoサーバを立てて負荷試験をやってみたい。そうだね。将来的には配信サーバなどを立てられるといいのだけれど 後は、prometheus + graphanaで、負荷を可視化できるとなおいいよね。時系列でどれくらい負荷がかかっているのかが見れると最高だと思います。 各サーバにいちいち入るのは面倒くさいので一括でsshしたいと思っています。これを可能にする方法を岡田さんが考えてくれました。 msshですね。 各物理サーバ（ラズパイ）のハードウェアスペック router : raspi 5. RAM 8G. Storage 128G beta : raspi 4. RAM 1G. Storage 32G delta: raspi4. RAM 4G Storage 64G phi (f): raspi4. RAM 8G. Storage 32G gamma: raspi4. RAM 8G Storage 128G omega: raspi4. RAM 1G storage 32G zeta: raspi4. RAM 8G ここから使える奴だけ選抜する。 router, delta, phi, gamma, zeta の5台。一台は、router + dhcp + dnsの役割を持たせる。 容量的にdeltaがよさそう。そのほかは、k8sクラスタになる。頑張ってくれ。 k8sちゃんと動いてくれ！! ちなみに、 ...

背景 openVPNを使うことでsite2siteルーティングができるようになった。 しかし、そのネットワークに参加するためにはopenVPNで発行されるクライアント証明書が不可欠である。 それが面倒くさいという話だ。 実際のアプリではL7でのやり取りが多いから、L4まで権限は必要ない。 そこで、sshを使ってhttpレイヤーでトンネルを構築しようという話だ。 もうチャットGPUにききますね My Question 手元のラップトップー＞踏み台サーバー＞webサーバ があったとします。 この時、webサーバの80番ポートでhttp通信を待ち受けているサーバがいます。 手元のラップトップー＞webサーバ にアクセスしたいです。 やり方を教えてください。 chatGPTの回答 結論 ssh -L 8080:192.168.1.2:80 user@bastion.example.com 8080はローカルマシンのポート番号 192.168.1.2はWebサーバのIPアドレス 80はWebサーバのポート番号 userは踏み台サーバのユーザー名 bastion.example.comは踏み台サーバのホスト名またはIPアドレスです。 ssh -Lオプションとはなんなのか？ これは後で調べます。

GSLBとは はい、GSLB（Global Server Load Balancing）について知っています。GSLBは、複数の地理的に分散したサーバー間でネットワークトラフィックを効果的に分散するための技術です。これにより、以下のような利点が得られます。 高可用性: サーバーの障害が発生した場合でも、トラフィックを他の健全なサーバーにリダイレクトすることでサービスの継続性を確保します。 負荷分散: トラフィックを複数のサーバーに分散することで、特定のサーバーに過負荷がかかるのを防ぎます。 低遅延: ユーザーに最も近いサーバーにトラフィックをルーティングすることで、応答時間を短縮します。 災害復旧: 地理的に分散したサーバーを利用することで、特定地域での災害や障害に対する耐性を向上させます。 GSLBは、DNSベースの方法や、アプリケーション層でのルーティングを使用して実現されることが一般的です。具体的な実装方法や製品には、以下のようなものがあります。 DNSラウンドロビン: 最も基本的なGSLBの方法で、DNSサーバーが複数のIPアドレスを順番に返すことで負荷を分散します。 Anycast: 同じIPアドレスを複数の地理的に分散したサーバーに割り当て、最も近いサーバーにトラフィックをルーティングします。 商用製品: F5 NetworksのBIG-IP、CitrixのNetScaler、Amazon Web ServicesのRoute 53など、さまざまな商用ソリューションがあります。 GSLBは、大規模なWebサービスやクラウドサービスでよく利用される技術です。 僕の質問 一般ユーザはDNSを介してどのサーバにアクセスするかがきいまると思います。また、DNSは裏でGSLBと繋がっていて、一般ユーザー＞DNS -> GSLBという流れでリクエストが流れると思います。この認識は合っていますか？ chatGPTの回答 基本的な認識は合っていますが、もう少し詳細に説明すると、DNSとGSLBの関係は次のようになります。 一般ユーザーのリクエスト: 一般ユーザーがウェブサイトにアクセスしようとすると、まずDNSリクエストが発生します。このリクエストは、ユーザーが入力したドメイン名をIPアドレスに変換するためのものです。 DNSサーバーの役割: DNSサーバーは、このドメイン名に対応するIPアドレスを返します。ここで、GSLBがDNSサーバーに組み込まれているか、もしくはGSLBがDNSサーバーと連携しています。 GSLBの動作: GSLBは、複数の地理的に分散したサーバーの中から最適なサーバーを選択し、そのサーバーのIPアドレスをDNSサーバーに返します。選択基準には、サーバーの負荷、地理的な距離、ネットワークの遅延などが含まれます。 DNSの応答: DNSサーバーは、GSLBから受け取った最適なサーバーのIPアドレスをユーザーに返します。 ユーザーのアクセス: 最終的に、ユーザーのブラウザは返されたIPアドレスを使って直接サーバーにアクセスします。 この流れを図にすると以下のようになります： mermaid sequenceDiagram participant User as 一般ユーザー participant DNS as DNSサーバー participant GSLB as GSLBシステム participant Server as 最適なサーバー User->>DNS: ドメイン名の解決リクエスト DNS->>GSLB: 最適なサーバーのIPアドレスを要求 GSLB->>DNS: 最適なサーバーのIPアドレスを返す DNS->>User: IPアドレスを返す User->>Server: サーバーにアクセス このように、一般ユーザーのリクエストは最終的にはDNSを介してGSLBによって選ばれた最適なサーバーに到達します。DNSはGSLBと連携して動作し、ユーザーに最適なサーバーのIPアドレスを提供します。 ...

何の記事 vpnサーバに接続してきたvpnクライアントがいるネットワークに、vpnサーバからアクセスできるようにする方法の手順を解説 ちなみに、これはCloudflaairとかいう会社が提供しているzero trustっていうサービスと同等のことを可能にしてくれる。 初めに VPNサーバを立てて、VPNクライアントのパケット通信をVPNサーバを通すようにすることはできていた。 これによって、クライアントはサーバと同じネットワーク上にいるかのようにふるまうことができていたわけだね。 しかしこの逆ができなかったのですよ。 つまり、 サーバがクライアントのネットワークにいるかの如くふるまうように設定することがずっとできなかったんですよね。 その必要性も当時はあまりなかったからね。 だが、この度新しいおうちに引っ越して、「単一のグローバルipが与えられておりポート開放できるルータがある」環境を失ってしまった。 外からアクセスできないんですよね、今のうちのネットワーク環境だと。 家の外に借りたVPSは結構あって、そこにVPNサーバを立てることはできる。 そこで今まで試したけど挫折してきた、「隔絶されたネットワークに、そのネットワークにいるvpnクライアントを介してアクセスする方法」。 今回はそれを可能にする方法を教えます。 ちなみに、二つの異なるネットワークセグメントをvpnサーバとvpnクライアントを使って完全につなげることを、 「site to site routing」といいます。マジでかっこいいですね。あこがれちゃいます。そんな憧れを、今回、達成してしまうんです。 これによって、「remote.it」のように、ポート開放をしていない、隔絶されているネットワーク環境に、外からアクセスできるようになるんです。えぐいですねーーー。えぐい。とにかくえぐい。 参考記事 記事1 記事2 openVPN公式 site2siteに関しては二つ目がかなりいい感じにまとめてくれています。 まずはいつも通り普通にopenvpnサーバを立てる OpenVPNとeasy-rsaのインストール sudo yum install openvpn easy-rsa -y easy-rsaを使って証明書関係を作る ./easyrsa init-pki ca証明書を作成 ./easyrsa build-ca *ca証明書＝認証局(ca)証明書。 認証局(CA)とは、ウェブサイトやその他の独立した存在などに、デジタル証明書を発行する信頼できる組織。 できたら移動しておく cp pki/ca.crt /etc/openvpn diffie-helman parameterを生成 ./easyrsa gen-dh 移動しておく sudo cp pki/dh.pem /etc/openvpn Certificate Revocation List (CRL) を生成 ./easyrsa gen-crl OpenVPN Serverように証明書と秘密鍵を生成　（サーバ証明書の生成） ./easyrsa build-server-full server nopass 移動しておく sudo cp pki/issued/server.crt /etc/openvpn sudo cp pki/private/server.key /etc/openvpn クライアント証明書と秘密鍵を生成 ./easyrsa build-client-full username 各コマンドの詳しい説明 ./easyrsa build-ca ./easyrsa build-ca コマンドは、 Easy-RSAツールを使用して 新しい認証局（CA）のルート証明書と秘密鍵を生成するためのものです。 認証局は、VPN証明書を発行および署名するために使用されます。 このプロセスは通常、VPNサーバーをセットアップする最初のステップの一つです。 具体的には、このコマンドは以下の操作を行います： CAの秘密鍵の生成：認証局（CA）の秘密鍵を生成します。 この鍵は、CAによって発行される証明書に署名するために使用されます。 CAの自己署名証明書の生成：CAの自己署名証明書を生成します。 この証明書は、CA自身が正当な認証局であることを証明します。 このコマンドを実行すると、以下のファイルが生成されます： ca.crt: CAの自己署名証明書 ca.key: CAの秘密鍵 これらのファイルは、VPNサーバーの証明書発行および署名プロセスで使用されます。 具体的には、CAの秘密鍵 (ca.key) は秘密に保管されるべきであり、 CAの証明書 (ca.crt) はクライアントと共有され、 クライアントはこれを使用してサーバー証明書の有効性を検証します。 証明書には公開鍵も含まれていると考えていいです。 ./easyrsa build-server-full server nopass ./easyrsa build-server-full server nopass コマンドは、Easy-RSAツールを使用してOpenVPNサーバーの証明書と秘密鍵を生成するためのものです。このコマンドは、サーバー証明書を生成し、その秘密鍵にパスフレーズを設定せずに保存します。 具体的には、このコマンドは以下の操作を行います： サーバー証明書の生成：指定された名前（この場合は server）でサーバー証明書を生成します。この証明書はサーバーがVPNクライアントに自身を証明するために使用されます。 サーバーの秘密鍵の生成：サーバー証明書と一緒に使用される秘密鍵を生成します。この秘密鍵は、VPN接続を暗号化するために使用されます。 証明書署名要求（CSR）の作成および署名：証明書署名要求（CSR）を作成し、それを認証局（CA）で署名することで有効な証明書を生成します。 パスフレーズの省略：nopassオプションにより、生成される秘密鍵にはパスフレーズが設定されません。これにより、サーバーが起動するたびにパスフレーズを入力する必要がなくなります。 このコマンドを実行すると、通常、以下のファイルが生成されます： server.crt: サーバー証明書 server.key: サーバーの秘密鍵 server.req: 証明書署名要求（CSR） これらのファイルは、OpenVPNサーバー設定に必要なものであり、適切に保管されるべきです。特に、server.key は秘密に保つ必要があります。 ./easy gen-dh ./easyrsa gen-dh コマンドは、Easy-RSAツールを使用してDiffie-Hellman（DH）パラメータを生成するためのものです。DHパラメータは、VPNサーバーとクライアント間で安全にキー交換を行うために使用されます。これにより、セッションごとに異なる鍵が生成され、通信のセキュリティが強化されます。 具体的には、このコマンドは以下の操作を行います： Diffie-Hellmanパラメータの生成：DH鍵交換プロトコルに使用されるパラメータを生成します。これらのパラメータは、安全な通信チャネルを確立するために必要です。 生成されたファイルの保存：生成されたDHパラメータは、VPNサーバーの設定で使用されます。 このコマンドを実行すると、以下のファイルが生成されます： dh.pem: Diffie-Hellmanパラメータ ./easyrsa gen-crl ./easyrsa gen-crl コマンドは、Certificate Revocation List (CRL) を生成するためのものです。CRLは、無効または失効された証明書のリストを保持し、認証局（CA）が管理します。 具体的には、このコマンドは以下の操作を行います： CRLの生成：現在の認証局の設定に基づいて、新しいCRLファイルを生成します。このファイルには、CAによって失効された証明書のリストが含まれています。 既存の失効証明書の確認：CRLを生成する際に、すでに失効されている証明書が正しくリストに含まれていることを確認します。 CRLは、VPNサーバーやその他のサービスがクライアント証明書の有効性を確認するために使用されます。具体的には、クライアントがVPNに接続しようとする際、サーバーはそのクライアントの証明書がCRLに含まれていないことを確認することで、失効された証明書による不正アクセスを防ぎます。 生成されたCRLファイルは通常、crl.pem という名前で保存されます。このファイルは、VPNサーバーの設定に組み込まれる必要があります。例えば、OpenVPNサーバーでは、crl-verify オプションを使用してこのCRLファイルを指定します。 ./easyrsa build-client-full username このコマンドは、Easy-RSAツールを使用してOpenVPNクライアント証明書と鍵を生成するためのものです。具体的には、build-client-fullコマンドは以下の操作を行います： クライアント証明書の生成：指定されたユーザー名（この場合はusername）に対して、クライアント証明書を生成します。証明書はクライアントがVPNに接続するために必要なものであり、認証局（CA）によって署名されます。 クライアントの秘密鍵の生成：クライアント証明書と一緒に使用される秘密鍵を生成します。この鍵は、クライアント証明書とともにVPN接続を確立するために必要です。 証明書署名要求（CSR）の作成および署名：証明書署名要求（CSR）を作成し、それを認証局（CA）で署名することで有効な証明書を生成します。 このコマンドを実行すると、通常、以下のファイルが生成されます： username.crt: クライアント証明書 username.key: クライアントの秘密鍵 username.req: 証明書署名要求（CSR） これらのファイルは、VPNクライアント設定に必要なものであり、適切に保管されるべきです。クライアントはこれらの証明書と鍵を使用してOpenVPNサーバーに接続し、暗号化された通信を確立します。 以上の鍵が生成される順番と、これらのカギを使って実際にクライアントがサーバとコネクションを張り暗号化された通信をするまでの流れ 1. 接続の確立 クライアントがVPNサーバーに接続を試みます クライアントはVPNサーバーに接続リクエストを送信します。 2. サーバーの証明書を検証 クライアントはサーバーから送られてきた証明書 (server.crt) を検証します。 クライアントは自身のCA証明書 (ca.crt) を使用して、 サーバー証明書がCAによって署名されていることを確認します。 この検証により、 クライアントは接続しようとしているサーバーが信頼できるものであることを確信します。 3. クライアントの証明書を検証 サーバーもクライアントから送られてきた証明書 (username.crt) を検証します。 サーバーは自身のCA証明書 (ca.crt) を使用して、 クライアント証明書がCAによって署名されていることを確認します。 サーバーはさらに、クライアント証明書が失効していないことをCRL (crl.pem) を用いて確認します。 4. 秘密鍵の使用 クライアントとサーバーのそれぞれの秘密鍵（username.key と server.key）は、相手の証明書と合わせて使用され、相互認証を実施します。 サーバーの秘密鍵（server.key）は、サーバーが送信するデータのデジタル署名と暗号化に使用されます。 クライアントの秘密鍵（username.key）は、クライアントが送信するデータのデジタル署名と暗号化に使用されます。 5. 鍵交換とセッションの確立 Diffie-Hellman鍵交換プロトコルの使用 クライアントとサーバーは、Diffie-Hellman鍵交換プロトコルを使用して、セッション鍵を安全に交換します。 このプロセスでは、サーバーの dh.pem ファイルが使用されます。 セッション鍵の生成 Diffie-Hellman鍵交換によって生成されたセッション鍵を使用して、クライアントとサーバー間で安全な通信チャネルを確立します。 これにより、以降の通信が暗号化されます。 暗号化された通信の開始 暗号化された通信の開始 セッション鍵が確立された後、クライアントとサーバー間の通信は暗号化されます。 以降のデータは、このセッション鍵を使用して暗号化・復号化されます。 各通信データは、相手側の公開鍵で暗号化され、自身の秘密鍵で復号化されます。 VPNサーバの起動 sudo systemctl stop openvpn サーバがうまく起動できないとき こっちで試してみるのもありかもしれない。 ...

事始め 例のシステムで、tcコマンドでネットワークレイテンシーを増加させたんですけどね。 そしたら、たったの100msの遅延だったんですけど、64MiBのデータを送信するときに、 アプリから見た時の遅延の時間がなんと1sくらいまで伸びてしまったんですよね。これ、めちゃめちゃ面白い話で、深堀りする価値があるんです。 もしかしたら、ロングファットパイプ問題についても、わかるかもしれないね。 まず、TCPの基礎、どうやって動いているのかを理解する必要がある。 が、せっかくなので、もう一回上からやろうか。 アプリケーションレイヤーから、どうやってデータが通信相手まで伝わるのか、ってのをもう一回確認して、 本題のTCPレイヤーのMTU,MSS,windowサイズについて話した後、tcpダンプの使い方を調べ、最後に実際にTCPダンプをして、 例のシステムにおいて、サーバ・クライアント間で100msの遅延が生じているときのデータのやり取りについてみてみましょう。 OSIモデル、プロトコルスタックについて確認 まず、プロトコルスタックとは「コンピュータネットワーク用のプロトコルの階層」のことです。 OSIモデル(7層) で見ていくのが大事そうですね。上から、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、物理層。 アプリケーション層では、具体的なサービスを提供。HTTPとか、websocketとか、FTPとか、SSHとか、その他いろいろ。 プレゼンテーション層は、データのフォーマットを定義する？そうですね。エンコードの方法とか。これはおそらくまだOSレイヤーの話ではない。 ここからがOSの世界の話。 セッション層は、connect(sockdrp,IP)で、コネクションを確立したときに、コネクションの相手を覚えておく層、だと思っていい。 つまり、ソケットのことです。ソケットが通信相手の情報を覚えておきます。 ソケットは、OSによってプログラムのされ方が違うらしいです。それでも異なるOS同士ど通信ができるのは、トランスポート層で規定されているプロトコルにすべてのOSが準拠しているからです。 トランスポート層 (L4) が、TCP / UDP です。TCPでは、アプリケーションからもらったデータを小分けにして、通し番号を付けて、 小分けにしたデータをちょっとづつ送ります。小分けにされたデータが、いわゆる「パケット」です。 再送とかもする。信頼性が高いのです。その代わりスループットは悪くなります。 一方、UDPはデータを投げっぱなしにします。信頼性は低いですが、スループットは高くなります。VoIPなどに使われますね。 L4ではまだ、IPは指定しません。 その下、ネットワーク層が、IPです。ルーティングを決めてくれます。 その下、データリンク層が、イーサネットですね。L2TPとかをするVPN、ありますよね。あれはね、このレイヤーで動いているんですよね。 その下、もう物理層です。L1です。 L4、トランスポート層のTCPについてもう少し詳しく見ていく まずは、TCPヘッダーのフォーマットを見てみましょう。 送信元ポート番号：16bit 送信先ポート番号：16bit シーケンス番号：32bit ACK番号：32bit データオフセット：4bit 未使用：6bit コントロールビット：6bit ウインドウ：16bit チェックサム：16bit 緊急ポインタ：16bit オプション：可変長 いろいろありますが、ここでまず注目したいのは、通信相手のIPアドレスがないってことですね。 なぜなら、それはL3が担当するからです。 その他、自分的にまだ理解が完ぺきではないけど大事そうなのは、シーケンス番号、ACK番号、コントロールビット、 ウィンドウの、４つですね。それぞれについて説明していきます。 シーケンス番号 「このパケットの先頭のデータが送信データの何バイト目にあたるのか送信側から受信側に伝えるためのもの」 TCPではデータを小分けにして送りますね。パケットです。で、何バイト目か？って話ですね。32bitしかないってことは、 2^32/1024/1024/1024 = 4GiBしか一回で送れないってこと？まじ？？まあいいや。そんなことはないと思うけどね。 ACK番号 「データが何バイト目まで受信側に届いたのか、受信側から送信側に伝えるためのもの。」だそうです。 コントロールビット URG:緊急ポインタ ACK:データが正しく受信側に届いたことを意味する PSH:FLUSH動作によって送信されたデータである RST:接続を強制的に終了：異常終了 SYN:送信側と受信側で連番を確認しあう。これで接続どうさを表す FIN:切断 ウィンドウ 「受信側から、送信側にウィンドウサイズ (受信確認を待たずにまとめて送信可能なデータ量) を通知するために使う。」 これが16bitであるのが、もんだいなんですよ！！ 以上を念頭に次に進みます。 TCPが接続を開始して、データを送信し、切断するまで はい。一言でいうと、 「TCPはスループットを犠牲に、信頼性を高めた通信プロトコル」です。 信頼性を高めるために、されている工夫が２つあるんですね。それが、 3ウェイハンドシェイクと、パケット送信時の受け取り確認です。 （UDPはスリーウェイハンドシェイクも、受け取り確認もしない） ...

Squidについて Squidはプロキシやリバースプロキシの機能を提供するソフトウェアです。 プロキシを置く理由 主に、サービスの利用者向けのソフトウェアですね。 リバースプロキシを置く理由 リバースプロキシサーバーをバックエンドサーバーの前段に置く理由は、主に以下の５つです。 キャッシュサーバーとして利用 レスポンスを圧縮 (レスポンスの転送を高速化) SSL ターミネーション (暗号化や復号化の処理をリバースプロキシにオフロード) セキュリティの向上 (リバースプロキシでフィルタリング、バックエンドサーバーを隠蔽) 拡張性 (クライアントはリバースプロキシと通信するので、バックエンドサーバーを変更可能) こっちは主に、サービスの提供者側向けのソフトですね。 僕がやりたいこと 全部の通信が、Torみたいに、複数のサーバを介して行われる感じにしたいんですよね。んで、最終目的地はデータベースです。ユーてこれって、openvpnとかでじっそうできるのかな？いやできないか。 ネットワークの通信、頑張って自分で作れたりするのかな。いけそうな気もするな。

やりたいこと webアプリケーションを家のサーバで動かすとなるとセキュリティーの観点からして怖いじゃないですか。やっぱり自宅のipさらしたくないじゃないですか。 だからAWSなどのVPSを借りてそのうえでアプリを動かすんだと思います。 ただね、VPSでは二次記憶で使えるデータ量が決まっているんですね。しかもそのデータ量が結構限られています。例えば僕が契約しているサーバは二次記憶の容量が30GBです。つまり、大規模なデータベースを展開するには、大幅な課金が必要になるわけです。しかもさ、データベースを移植するのって結構面倒だからさ、一回構築したやつを長く使いたいんです。だからね、データベースだけは自宅においておき、アプリケーションが自宅のDBにデータをとりにきたり、おきに来たりすればいいのでは？と今思っているわけです。DBクライアントがデータを取ってくる時の通信量も考えるとどっちが安いかはまだわからないんですけどね。 じゃあ、自宅のルータをポート開放して、ポートフォワードすればいいんじゃねーの？って思うよね。でもね、データベース用のポートを開放しておくのもなんか怖いんですよ。ブルートフォースとか受けて、破られることもあるわけじゃないですか。ということで、vpnを介して自宅のネットワークにアクセスできるようにしておけばいいのではないか？というのが僕の考えです。 vpnクライアントのインストール sudo apt update sudo apt install openvpn vpnクライアント、設定ファイルのインポート config.ovpnをサーバに配置 sudo openvpn --config /path/to/my/ovpn/file パスワードを入力してトンネル完了 openvpnを介して自宅のmysqlサーバに接続 mysql -u ray -h 192.168.3.10 -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 473 Server version: 8.0.33-0ubuntu0.20.04.2 (Ubuntu) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> いけてしまっている…これはマジで感動！！ネットワークはやはり面白い。仕組みとかはもっと勉強しないといけませんが。 いやー－－、実際これはすごいです。マジですごいですわ！！感動ですわ。 ...

やりたいこと webアプリケーションを家のサーバで動かすとなるとセキュリティーの観点からして怖いじゃないですか。やっぱり自宅のipさらしたくないじゃないですか。 だからAWSなどのVPSを借りてそのうえでアプリを動かすんだと思います。 ただね、VPSでは二次記憶で使えるデータ量が決まっているんですね。しかもそのデータ量が結構限られています。例えば僕が契約しているサーバは二次記憶の容量が30GBです。つまり、大規模なデータベースを展開するには、大幅な課金が必要になるわけです。しかもさ、データベースを移植するのって結構面倒だからさ、一回構築したやつを長く使いたいんです。だからね、データベースだけは自宅においておき、アプリケーションが自宅のDBにデータをとりにきたり、おきに来たりすればいいのでは？と今思っているわけです。DBクライアントがデータを取ってくる時の通信量も考えるとどっちが安いかはまだわからないんですけどね。 じゃあ、自宅のルータをポート開放して、ポートフォワードすればいいんじゃねーの？って思うよね。でもね、データベース用のポートを開放しておくのもなんか怖いんですよ。ブルートフォースとか受けて、破られることもあるわけじゃないですか。ということで、vpnを介して自宅のネットワークにアクセスできるようにしておけばいいのではないか？というのが僕の考えです。 vpnクライアントのインストール sudo apt update sudo apt install openvpn vpnクライアント、設定ファイルのインポート config.ovpnをサーバに配置 sudo openvpn --config /path/to/my/ovpn/file パスワードを入力してトンネル完了 openvpnを介して自宅のmysqlサーバに接続 mysql -u ray -h 192.168.3.10 -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 473 Server version: 8.0.33-0ubuntu0.20.04.2 (Ubuntu) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> いけてしまっている…これはマジで感動！！ネットワークはやはり面白い。仕組みとかはもっと勉強しないといけませんが。 いやー－－、実際これはすごいです。マジですごいですわ！！感動ですわ。 ...

まあ便利なこと。無料でSSL証明書が発行できるなんて！！ ということでね、Let’s encryptを使って期限が切れたSSL証明書を再発行していきたいと思います。 参考サイトは以下のとおりです。 ref step1 クライアントソフトのインストール sudo apt install certbot python3-certbot-nginx step2 443のポート開放 & ファイアウォールの設定 step3 SSL証明書の発行 sudo certbot certonly これでインタラクティブに設定できる。聞かれたことを書けばいいだけです。 Saving debug log to /var/log/letsencrypt/letsencrypt.log How would you like to authenticate with the ACME CA? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Plugins selected: Authenticator webroot, Installer None Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): ingenboy.com Obtaining a new certificate IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/ingenboy.com-0001/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/ingenboy.com-0001/privkey.pem Your cert will expire on 2023-08-22. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le step4 nginx or apacheの設定を変更する。 nginxが証明書にアクセスできるようにパスをnginx.confに書き込むわけですね。はい、以上。 ...