データ通信工学 2024年度前期(1年)

今日、やったこと [確認テスト]ネットワーク接続機器 ファイアウォール 今日のホワイトボード ファイアウォールとは 通常、インターネットとLANの間に設置し、インターネットからLANへのパケットをチェックする。あらかじめフィルタリングルールを作っておき、通過するパケットをルールに従って処理する。 図　ファイアウォール 基本情報レベルでのファイアウォール 基本情報レベルでのファイアウォールはフィルタリングルールを IPヘッダの宛先・送信元IPアドレス TCP、UDPヘッダの宛先・送信元ポート番号 と使い、 インターネット側->LAN側 LAN側->インターネット側 の両方向で作成するケースが多い。 〇フィルタリングルールのチェック 上から順にチェックしていく。条件が一致するルールのアクション(許可、破棄）を行い、それ以降のルールはチェックしない。 〇送信元・宛先IPアドレスが192.168.10.10/32 /32なので、32ビット目までが/左側(192.168.10.10)と一致するPCが対象。IPアドレスは32ビット長なので、IPアドレスが192.168.10.10のPCが対象になる。 〇送信元・宛先IPアドレスが192.168.10.0/24 /24なので、24ビット目までが/左側(192.168.10.0)と一致するPCが対象。IPアドレスが192.168.10.xxのPCが対象になる。 図　フィルタリングルールの例 練習問題 問１ 簡単なフィルタリングルール作成の問題。 問題文を読めばできる。 図　[ファイアウォール]練習問題　問１ 問２ 問1と同じ。 図　[ファイアウォール]練習問題　問２ 問３ 条件が一致するフィルタリングルールを探す問題。 *の意味（要はチェックしない）と、上から順にチェックし、一致すればそれ以降はチェックしない（問題に書いてある）が分かればできる。 図　[ファイアウォール]練習問題　問３ DMZ ファイアウォールは接続されるネットワークを WAN（インターネット） LAN DMZ(DeMillitazized Zone) に分ける。 WAN(インターネット)は危険なPC等があるゾーン。 LANはF/Wが守るべきゾーンで、インターネットからの直接アクセスを拒否。 DMZはインターネットから直接アクセスを一部許可するゾーン。 ...

今日、やったこと [確認テスト]HTTP OSI基本参照モデル ネットワーク接続機器 今日のホワイトボード OSI基本参照モデルとネットワーク接続機器 OSI基本参照モデルはTCP/IPをさらに細分化した7階層のプロトコル階層。 世の中にはOSI基本参照モデルをベースに作られたプロトコル群はないが、いろいろなケースで登場する。とくにネットワーク接続機器を分類する際によく使われる。  図　OSI基本参照モデルとネットワーク接続機器 [ネットワーク接続機器]ハブ OSI基本参照モデルの第1層（物理層）の機能を持つ。 物理層なので、ポートから電気信号が入力されると認識している。 入力された電気信号を増幅・整形して、ほかの全ポートへ出力する。タイミングが悪いと、パケット同士の衝突が発生してしまう。 図　ハブ [ネットワーク接続機器]スイッチ OSI基本参照モデルの第2層（データリンク層）までの機能を持つ。 物理層＋データリンク層＝イーサネットなので、ポートにはイーサネットフレームが入力されると認識できる。 入力されたイーサネットフレームのイーサネットヘッダから 送信元MACアドレスを使ってポートごとの接続PCのMACアドレス一覧表をつくる 宛先MACアドレスとポート別接続PCMACアドレス一覧から送出ポートを決定する のようにパケットのフィルタリングを行う。 ※不要なポートへの出力はしない。 図　スイッチ [ネットワーク接続機器]ルーター ルーターはIP層までの機能を持つため、ルーティングができる。入力パケットのIPヘッダを確認して、ルーティングテーブルを使ってパケットをルーティングする。 [ネットワーク接続機器]ゲートウェイ ファイアウォールが一例。 入力パケットのアプリケーション層まで確認することができるため、Webのやり取りやメールやり取りで怪しいデータがないかチェックすることができる。 次回は テストをします。 ファイアウォールをやります。

今日、やったこと http 今日のホワイトボード HTTP HTTP(Hyper Text Transfer Protocol)ホームページデータのやり取りのためのプロトコル。 TCPの80ポートを利用。 図　プロトコル階層中のHTTP ホームページはHTMLで書かれている ホームページはHTML(Hyper Text Markup Language)で書かれている。 HTMLは言語だが、実態は役割が決めれたタグがいろいろと定義されているだけ。 見せ方やデータ内容に応じてタグを指定する。 図　HTMLのタグ ホームページデータのやり取り クライアント(PCやスマホ、タブレットなど)はWebブラウザを使う。 WebブラウザがWebサーバーにホームページをリクエストすれば、Webサーバーからホームページのデータが返信される。 この リクエスト、レスポンスの手順を決めたのがHTTP 。 図　ホームページデータのやり取りの手順はHTTPで決められている URL URL(Uniform Resource Locator)はホームページをリクエストする際のプロトコルやサーバー、ページ名、送信データのフォーマット。URLのフォーマットに従ってリクエストする。 図　URL クライアント->Webサーバー クライアントからWebサーバーにホームページをリクエストする際、HTTPでは下図のようなフォーマットでリクエストするように定められている。 図　クライアント->Webサーバーにリクエスト メソッドのGET、POSTは今後いろいろな局面で登場するので、覚えておいてください。 Webサーバー->クライアント Webサーバーがクライアントからのリクエストに対する応答(ホームページデータ)は下図のようにHTTPでフォーマとが定められている。 図　Webサーバー->クライアントにレスポンス 次回は HTTPのテストをします。

今日、やったこと DNS [確認テスト]DNS 今日のホワイトボード DNSによる名前解決の流れ ルートドメインのネームサーバーから順に下位ドメインのDNSサーバーを辿って名前解決する流れを確認。 DNSサーバーに問い合わせ可能な内容 DNSは名前解決(aレコード）やドメインのDNSサーバー問い合わせ(nsレコード)以外に、コンピュータ名からIPアドレスを取得する逆問い合わせ(ptrレコード)、ドメイン名からメールサーバーの問い合わせ(mxレコード)が可能。 nslookupコマンドでDNSサーバーに問い合わせる際は、setコマンドで問い合わせ内容を切り替えることができる。 図　nslookupのオプション 次回は HTTPをやります。  

今日、やったこと DNS 今日のホワイトボード DNSサーバー 各ドメインには少なくとも1台のDNSサーバーがある。 DNSサーバーは 自ドメインのコンピュータのIPアドレス 直下のドメインのDNSサーバーのIPアドレス を知っている。   図　各ドメインのDNSサーバーは 各ドメインのDNSサーバーを使って名前解決 まずはルートドメインのDNSサーバーに問い合わせ。 しかし、ルートドメインのDNSサーバーが教えてくれるのは直下のドメインのDNSサーバーのIPアドレス。 教えてもらった直下のドメインのDNSサーバーに再度問い合わせを行う。 これを繰り返して名前解決を行う。 図　DNSサーバーを使って名前解決 ルートドメインのDNSサーバーから順に問い合わせを行うことを反復問い合わせと呼ぶ。 用語について 〇コンテンツサーバー 各ドメインのDNSサーバーはコンテンツサーバーと呼ぶ。コンテンツサーバーは自ドメイン+直下のドメインの情報を持っている。 〇キャッシュサーバー コンテンツサーバーに問い合わせを行うDNSサーバーをキャッシュサーバーと呼ぶ。 キャッシュサーバーはPC等から問い合わせを受けて、名前解決を行う。 過去に調べた情報を一時保存(キャッシュ)する。だからキャッシュサーバー。 コンテンツサーバーはキャッシュサーバーから問い合わせされる側。 キャッシュサーバーはコンテンツサーバーに問い合わせする側。 〇反復問い合わせ ルートドメインから順に各ドメインのDNSサーバーに問い合わせ。 〇再帰問い合わせ PCとキャッシュサーバーのあいだの問い合わせ。 次回は DNSの演習をやってもらいます。そのあとDNSのテストします。

今日、やったこと [確認テスト]TCPのシーケンス番号、確認応答番号、ウィンドウサイズ TCPとUDPの違い 第4層のプロトコルの特徴 名前解決 DNS 今日のホワイトボード TCPとUDPの違い TCP、UDPはともに第3層のプロトコル。２つは両極端な特徴を持つ。 図　TCPとUDPの違い 第4層のプロトコルがTCP、UDPを選択する。  第4層のプロトコル 第4層には利用目的に特化したプロトコルがたくさんある。 ホームページにはホームページの特徴にあったデータのやり取り方法がある。メールにはメールにあったデータのやり取り方法がある。そのため、第4層には利用目的に特化したプロトコルがある。 図　第4層のプロトコル 名前解決 GoogleのWebサイトにアクセスするさい、普通はブラウザのアドレス入力欄に、 　https://www.google.co.jp と入力してアクセスする。(現実ではブラウザのデフォルトページがGoogleのサイトになっており、検索して各Webサイトにアクセスするけど） インターネットではTCP/IPを使って通信をしているため、Googleのサイト=GoogleのWebサーバーにはIPアドレスが付与されており、このIPアドレスでアクセスする必要がある。 しかしながら、Googleのサイトにアクセスする際、IPアドレスを意識することはなく、https://www.google.co.jpでアクセスできる。 これはwww.google.co.jpからIPアドレスに変換する仕組みのお陰。 www.google.co.jpのような文字列(コンピュータ名)からIPアドレスに変換することを 名前解決 と呼び 、インターネットではDNSが使われる。 図　名前解決 DNS インターネットでの名前解決はDNSが利用されている。 Googleのサーバーの名前www.google.co.jpはDNSの命名規則に従っている。 DNSはドメインツリーと呼ばれるルートドメインを頂点とした木構造のモデル がある。 各ドメインにはDNSサーバーがあり、そのドメインの情報を管理している 。 図　DNSの階層と名前の関係 次回は テストはしません。 DNSの続きです。

 今日、やったこと TCPヘッダのウィンドウサイズ スライディングウィンドウ 今日のホワイトボード TCPヘッダのウィンドウサイズ 受信データは一旦バッファに保存され、順に処理される。 この バッファの空き容量を伝えることで、相手はバッファの空き容量までは受信応答を待たずにデータ送信ができる 。 バッファの空き容量を伝えるのが、TCPヘッダのウィンドウサイズ。 図　相手のウィンドウサイズまでは受信応答なしで送信可能 キャプチャした実際のパケットで確認① 図　相手のウィンドウサイズまでは受信応答なしで送信可能　実際のパケット① ②で172.16.8.11のバッファの空きサイズは5840バイトと通知。 これを受信することで、172.16.4.253は5840バイトまでは受信応答なしで連続してデータ送信が可能と判断。 ④、⑤でそれぞれ1460バイト、171バイトと受信応答なしで連続してデータを送信。 キャプチャした実際のパケットで確認② 　相手のウィンドウサイズまでは受信応答なしで送信可能　実際のパケット② ⑧で172.16.8.11は空きバッファサイズを11680バイトと通知。 ⑨で172.16.8.11は723バイトのデータを受信。これで空きバッファサイズは 　空きバッファサイズ = 11680 - 723 = 110957バイト と推測できる。 が、⑩で172.16.8.11はウィンドウサイズが14600バイトと通知。 172.16.8.11はバッファのデータを処理＋バッファサイズの拡大をしている。 始めはバッファサイズを少なめに通知して、大量にデータが送信されることを防ぐこともある。で、ちょっとずつバッファを拡大していく。 172.16.8.11はこの方式を取り入れている模様。 スライディングウィンドウ データを送信する際、「相手のウィンドウサイズはxxxバイトで、今はxxxバイトを送信したから、あとxxxxバイト送信できる」と計算をしながら送信するのはめんどくさい。 スライディングウィンドウと呼ばれる仕組みで簡単に、かつ間違いなく送っている。 図　スライディングウィンドウ 受信した確認応答番号から同じく受信したウィンドウサイズ分のエリアが送信可能なデータ 。このエリアに窓を作るイメージ。窓の空いているデータを送信する。 データを送信すると、受信応答が返っ...

今日、やったこと パケットからTCPの処理のながれを確認　その２ 今日のホワイトボード パケットからTCPの処理のながれを確認　その２ 前回配布したTCPパケットキャプチャ結果を使って、パケットのやり取りを特にTCPに注目して確認。 コネクション確立 ①172.164.253->172.16.8.11 コネクション確立1 シーケンス番号が0でない点に注目。 シーケンス番号は0でスタートしません。乱数生成した値を使います。 172.16.4.253のシーケンス番号0相当の値は70668です。 ②172.16.8.11->172.16.4.253 コネクション確立2 こちらもシーケンス番号が0でない点に注目。 172.16.8.11のシーケンス番号0相当の値は92019です。 ③172.16.4.253->172.16.8.11 コネクション確立3 ここまでがコネクション確立です。   図　①～③　コネクション確立 データ連続送信 ④172.16.4.253->172.16.8.11 データ送信 1460バイトのデータ(1バイト目～1460バイト目)を送信。 ①、②のコネクション確立でMSSを通知し、1460より大きなデータは1460バイトに分割して送信することになりました。 シーケンス番号70669から送信元のシーケンス番号初期値を引くと1。1バイト目のデータです。1バイト目から1460バイト目までの1460バイトのデータを送信。 ⑤172.16.4.253->172.16.8.1 データ送信 シーケンス番号72129から送信元のシーケンス番号初期値を引くと1461。1461バイト目のデータです。1461バイト目から1631バイト目までの171バイトのデータを送信。 ④の続きと思われます。 図　④、⑤　データ送信 ④、⑤と連続してデータを送信していますが、これはTCPの基本動作(データ送信->受信応答受信->データ送信)と異なります。大丈夫なんでしょうか？ 受信応答 ⑥172.16.8.11->172.16.4.253 ④の受信応答 確認応答番号72129から宛先のシーケンス番号初期値を引くと1461。これは1461バイト目をリクエストしています。 ④(1～1460バイト目まで)受信で1460バイト目まで受信して...

今日、やったこと パケットからTCPの処理のながれを確認 今日のホワイトボード パケットからTCPの処理のながれを確認 前回からのつづき。 前回は以下のパケットを確認しました。 No.6～8　コネクション確立 No.9　データ(ホームページリクエスト)送信 No.10　No.9の受信応答 今日は、No.11以降のパケットです。 ⑥No.11、⑦No.12、⑧No.17　172.16.8.10->172.16.14.160 データ送信 No.9で172.16.14.160から172.16.8.10へリクエストしたホームページのデータ。 データサイズがMSSの1460バイトより大きいため、1460バイトで区切って送信。 図　⑥N.11、⑦No.12～⑧No.17のパケット 受信応答を受け取らずに、連続して送信しているところが謎。 （次回やります） ⑨No.18 172.16.14.160->172.16.8.10 No.11～17の受信応答 確認応答番号からバイトまでは受信できていることが分かる。 ＝　No.17まのでパケットが受信できた 図　⑨No.18のパケット 次回は 新たにTCPのやり取りにフォーカスしたパケットキャプチャ結果を配布しました。 パケットキャプチャ結果を解析し、入力してもらったデータをもとに話をします。  

今日、やったこと [確認テスト　解説] シーケンス番号・確認応答番号2 パケットからTCPの処理のながれを確認 今日のホワイトボード [確認テスト　解説] シーケンス番号・確認応答番号2 基本は 　データ送信 -> (受信したら)受信応答返信 -> (受信したら)次のデータを送信 です。 データや受信応答が受信できない場合 　データ送信 -> 受信できず -> 受信応答が受信できない -> データを再送 　データ送信 -> 受信応答返信 -> 受信できず -> データを再送 です。 問１ Aは①送信後、受信応答が来ないので②で再送。 Bは④送信後、受信応答が来ないので⑤で再送。 図　問1 問２ Aは①送信後、受信応答が来ない(Bは②で送信しているものの、Aは受信できず)ため、③で再送。 しかし、③をBが受信できないため、Aは再び④で再送。 ④に対してBは⑤で受信応答を返信しているものの、Aは受信できず。よって、Aは⑥で再送。 図　問2 パケットからTCPの処理のながれを確認 前回、パケットキャプチャツールの画面からパケットの内容を確認してもらいました。 パケットを順に解説します。 ①No.6　172.16.14.160->172.16.8.10 コネクション確立1 TCPヘッダのコントロールフラグのSYN=1よりコネクション確立要求。 SYN=1のパケットは単にコネクション確立を行うだけでなく、 シーケンス番号の初期値 MSS を伝えます。 ②No.7　172.16.8.10->172.16.14.160 コネクション確立2 No.6を受信して、今度は172.16.8.10からコネクション確立要求です。 このパケットのコントロールフラグはACK=1になっています。これは”確認応答番号を見てね”です。受信した172.16.14.160は次はシーケンス番号1のパケットを送信します。 図　①No.6、②No.7のパケット ③No.8 172.16.14.160->172.16.8.10 コネクション確立3 No.6～No.8でコネクション確立です。 このパケットのTCPヘッダにはオプションはありません。（ヘッダ長=20バイトより) 図　③No.8のパケット ④No.9 172.16.14.160->1...