Networking

事始め 会社ではL7プロキシの運用・開発をしている。 複数のEP（ドメイン）を持っている。 複数のドメインをひとつのL7プロキシ（単一のIP）でさばいている。 さて、これはいったいどの様に実現しているのか？というのが今回の議題。 IPアドレスはDNSによって単一のドメインと紐づけられる。と自分は認識していたが、これが誤りだった。 そして、自分は、会社に入るまでホストヘッダーという概念を全く分かっていなかった。 HTTPにはホストヘッダーというものがあり、これによって単一IP上に複数のドメインを保持することができるようになる。 そして、ポイントはやはり、HTTPはL7レイヤーであり、IPはL3レイヤーであるというところに落ち着くと思う。 前提 DNSでのIPアドレスとドメインの紐づけは一対一ではなく、一対多であった。ここがすごく大事なところでした。 そして、自分はホストヘッダーについて理解していなかった。 nginxを使ってバーチャルサーバを立てる chatgptから 単一の物理サーバー上で複数のウェブサイトやアプリケーションをホストするために使用される機能です。それぞれのバーチャルサーバーは、異なるドメイン名やサブドメインに対応して、個別に設定されたリソース（例えばウェブページやアプリケーションのファイル、SSL証明書、ログファイルなど）にアクセスを提供します。 Nginxでは、これらのバーチャルサーバーを「サーバーブロック」として設定ファイルに記述します。以下は、Nginxでのバーチャルサーバー設定の基本的な例です： server { listen 80; server_name example.com www.example.com; location / { root /var/www/example.com/html; index index.html index.htm; } error_page 404 /404.html; location = /404.html { root /var/www/example.com/html; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/example.com/html; } } ホストヘッダーの役割 chatgptより HTTPのホストヘッダーは、HTTPリクエストを送信する際に非常に重要な役割を果たします。このヘッダーは、クライアントがリクエストを送信する際に、どのホスト（ドメイン名またはIPアドレス）とポートに対してリクエストが意図されているかを指定するために使用されます。特に、一つのサーバーが複数のドメインをホスティングしている場合（仮想ホスティング）、ホストヘッダーがないとサーバーはリクエストがどのウェブサイトに対してなのか判断できません。 HTTP/1.1ではホストヘッダーは必須とされています。これは、HTTP/1.0と異なり、サーバーが複数のドメインをホストしている状況が一般的になったためです。リクエストにホストヘッダーが含まれていない場合、サーバーは400 Bad Requestのエラーを返すことが多いです。 DNSのAレコード 複数のサブドメインが同じサーバーのリソースを指す場合、それら全てに同じIPアドレスを割り当てることが一般的です。 例えば、次のように設定することができます： www.example.com → 192.0.2.1 mail.example.com → 192.0.2.1 ftp.example.com → 192.0.2.1 これらのサブドメイン全てに同じAレコードのIPアドレス（192.0.2.1）を指定することで、一つのサーバーが異なるサービス（ウェブ、メール、FTPなど）を提供することができます。これは特に、ホスティングサービスが複数のウェブサイトを単一の物理サーバーで管理する場合などに便利です。また、メンテナンスやアップグレードが必要な場合にも、一箇所で変更を行うだけで済むため効率的です。 ...

Real world httpに書いてあることを殴り書きしていきます 開発環境 の前に、lanのipアドレスを書いておきたいです。 100.64.1.27 : alpha 100.64.1.61 : evn 100.64.1.48 : delta (K8SクラスタへのGWです) deltaの役割 前に、DHCPサーバとルータを作成する記事を書いた。 こちらの記事だね。 で、deltaはDHCPサーバ兼ルータという立ち位置です。

LBのあれこれ 参考文献 https://qiita.com/masaozi3/items/838060d7339aef01bc2e

TCP/IP & ネットワークコマンド入門の大事なところをメモっていく ncコマンドについて 個人的に、最近ncコマンド使う機会が増えてきて、この本でも結構語られているので、使い方くらいはメモっておきたい ncコマンドはTCPもしくはUDPのコネクションを貼ってくれるコマンド。送信するビット列は完全に自分で選ぶことができる。 以下のコマンドでサーバをTCPで起動できる。　-l はlistenの略で、リッスンしている、つまりサーバです nc -l 55555 以下のコマンドで、ncサーバとコネクションを貼ることができる nc <ip addr> <port> よくあるncコマンドの使用例 使用例としては、あるサービスのクライアントがどんな感じでbit列を送ってくるのかをサーバ側から可視化するときに使うイメージが強いな。 例えばUDP通信の代表例であるDNS resolutionね。こんな感じです。 ローカルホストで以下のncサーバを立てる # nc -u -l 1053 > query_packet.txt こいつは、1053万ポートでUDP通信を待ち受けている。で、受け取ったパケットをquery_packet.txtにリダイレクトしている。 このサーバに対して、以下のdigコマンドを送ることで、DNSクライアントがどのようなパケットを送信しているかがわかる。 dig +retry=0 -p 1053 @127.0.0.1 +noedns google.com ここからは、追加での遊びですが、こんな感じで、ncサーバで受け取ったパケットを今度はncクライアントに流し込んで読み込ませることもできると。おもろいっすね。 nc -u 8.8.8.8 53 < query_packet.txt > response_packet.txt ちなみに、以下のコマンドでhexでパケットの中身が見られるようになります。 hexdump -C query_packet.txt sshクライアントの動きをncサーバをたててみてみる nc -l 10022 > clien_packet.txt ssh localhost -p 10022 ray@delta:~$ hexdump -C clien_packet.txt 00000000 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f |SSH-2.0-OpenSSH_| 00000010 38 2e 39 70 31 20 55 62 75 6e 74 75 2d 33 75 62 |8.9p1 Ubuntu-3ub| 00000020 75 6e 74 75 30 2e 31 30 0d 0a |untu0.10..| 0000002a みたいな感じで見られてりして、マジで面白いわけですね。はい。ってことで、ncコマンドはガチで便利だし、知っておいた方がいいって話です。 ...

大人気K8Sシリーズ。 今回でなんと第４回目 まずは、過去の振り返りをやっていきましょう。 振り返り 過去の奮闘記録。 構築日記その１ 構築日記その２ 構築日記その3 第１回目と第二回目はインフラ構築を頑張っていた感じです。引っ越しとかあって、K8Sの勉強は飛び飛びになっている感じでね。 そして、第３回にして、やっと色々とインフラ構築をスムーズにできて、さまざまな概念についても理解できてきた、という感じです。 はい、サービスね。これが大事な概念だった。POD間で通信をするためには、Serviceが必要だったのではないか？とね。ServiceでPODをcoreDNSに登録することができる。 そして、基本的に一つのサービス内での通信はしない。サービス間の通信はあるが。なので、docker composeのようにはいかないという話だな。 そして、今回の第４回目では、K8Sの使い方をもっと詳しく理解していきましょう、という回になっています。 具体的には、「つくって、こわして、直して学ぶkubernetes入門」という本に従って色々と進めていきたいと思っています。はい。 そして、第５回目に、私が開発した競馬システムをついにデプロイする、という感じに持っていきたいと思っています。よろしくお願いします。 まずは、harborにログインしておく の前にロボットアカウントを作らないといけない感じ？ docker login 100.64.1.61:20080 -u username -p password server nerdctlを使っているので、buildを使うためにbuildkitをインストールする必要がある。 しかも、buildkitdというのを走らせておく必要がある。 テストでgoで簡易サーバを作って走らせる package main import ( "fmt" "log" "net/http" ) func main() { http.HandleFunc("/",func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w,"Hellow, wordl!") }) log.Println("starting server on port 8880") err := http.ListenAndServe(":8880", nil) if err != nil { log.Fatal(err) } } dockerfile FROM golang:1.23 AS builder WORKDIR /app COPY . . ENV CGO_ENABLED=0 RUN go mod tidy RUN go build -o hello . FROM scratch COPY --from=builder /app/hello /hello ENTRYPOINT ["/hello"] go.modを入れるのを忘れずに。 go mod init github.com/hogehoge とかで問題ない。 ...

DNSはrequestとresponseが同じ系形式のUDPパケットでやり取りされるプロトコルである。 で、実はdigがdnsプロトコルのパケット内容を忠実に再現しているのです。だから、これマスターするDNSがほぼ分かったということになります。 関連ドキュメント ハンズオンの ハンズオンを紹介しているやつ rfsの読み方を説明している資料 ルートDNSの場所 digコマンドでの遊び方 digでの遊び方 dnsの全体像 dig関連 digの基本的なオプション +noedns : tcpで問い合わせ +norec : 非再起問い合わせを強制する。 qr : queryレスポンス rd : recursion desired : 再起問い合わせ要求。（Set by the sender of the request if the server should attempt to resolve the query recursively if it does not have an answer readily available.） ra : recursion available : 再起問い合わせ対応が可能か？（Set by the server to indicate whether or not recursive queries are allowed.） 基本的に、名前解決と言ったら8.8.8.8などのDNSキャッシュサーバが再起問い合わが実行して返してくれる。 しかし、権威DNSは再起問い合わせができないからね。 rdがついてもraがなかったら非再起問い合わせができないということになります。いくつかみてみましょうか？ いくつかDNSレコードを送ってみましょうか？ dig @1.1.1.1 +norec blog.ingenboy.com ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @1.1.1.1 +norec blog.ingenboy.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21079 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;blog.ingenboy.com. IN A ;; Query time: 1 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Thu Aug 22 09:05:47 JST 2024 ;; MSG SIZE rcvd: 46 +norecをつけたのでDNSサーバは非再起問い合わせで名前解決ができません。そのため、answer sectionがないわけですね。 つまり、名前解決できなかったわけです。それにもかかわらずGot answerって書いているのはタチが悪いよね。 ...

リンクレイヤー MACアドレスですねー。実際に通信をする相手を指定するときはMACアドレスを指定しますね。 Network deviceがMACアドレスを持っていて、OSはIPとMACの対応表をARPテーブルに持っているんですね。 IPからMACを知ることをARP (address resolution protocol) って言いますね。 脆弱性 正直、ARPは脆弱性まみれに見える。 というのも完全に性善説に基づいているから。 「xxのIPアドレスを持っている機器はどこにありますかーー？？」に対して、「おれですー」ってやってくるやつが、本当にそうだと信じてしまう。 だからARP spoofingが簡単にできてしまうということだ。ちょっと実験してみたいよね。 kickthemout LAN内のほかのノードを締め出すツール 実験していましょうか。 sudo apt install git git clone https://github.com/k4m4/kickthemout.git sudo apt install nmap cd kickthemout sudo apt install pip sudo -H pip3 install -r requirements.txt arpspoof こっちの方が簡単だね。 arpspoof

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オプションとはなんなのか？ これは後で調べます。