ネットワーク技術入門のメモ 自分の解釈なので間違っている部分は含まれていると思います。
ハロゲン学習方針
何が大事なのかわからないから、とりあえず机上の学習を進め、実践に入った後に大事なものをまとめる方針でいく。
L2スイッチ
ポートに接続されたLANケーブルからMACアドレスを把握し、流れてきたデータを目的のMACアドレスにデータを送る役割。
インターネット
インターネットとは世界中に存在するルーターが接続し合うことで構成されている。
OSI参照モデル
ネットワーク層
IPヘッダが乗っている状態
この時IPパケットという。
データリンク層
L2スイッチ、同じネットワーク領域にいるコンピュータをmacアドレスによって識別し、適切にデータを送り届ける。
主なプロトコルはWiFiかイーサネット
イーサネットヘッダが乗っている状態をイーサネットフレームという。
イーサネットフレームフォーマットはイーサネット2規格が有名
プリアンブル
これからイーサネットフレームが届くんだなと知る。
宛先、送信元MACアドレス
MACアドレスは同じネットワーク空間上の端末を識別するID
送信者する場合
送信元のMACアドレスと、送信先のMACアドレスをセットしてイーサネットフレームを送信する
受信する場合
宛先MACアドレスが一致しない場合、イーサネットフレームを破棄する
また送信元MACアドレスを見てどこのMACアドレスから来たイーサネットフレームなのか判別
タイプ
使用するプロトコルを記録
イーサネットペイロード
イーサネットヘッダをの除いたデータ群(IPパケット)のことを指す
FCS(Frame Check Sequense)
イーサネットフレームが壊れていないかチェックする。
宛先MACアドレス、送信元MACアドレス、イーサネットペイロード、タイプをチェックサム計算してイーサネットフレームに含める。
そして受信側でも同様に計算しイーサネットフレームに含まれるFCSと一致するか確認する。
MACアドレス
特に宛先MACアドレス、送信元MACアドレスがイーサネットフレームの中でも重要である。
ビット列のなかでもI/Gビット、U/Lビットの二つが特別な意味を持つ。
I/Gビットは通信方法を表していて、U/Lは運用管理方法を表している。
MACアドレスの後ろから処理していくので、通信方法を表す、I/GからNICで処理していき次にU/Lで処理していくことになる。
物理層
電気信号と**「0,1」のデジタルデータ**を相互変換する役割を持つ。
基本的なコマンド
検証環境の構築
-cでyaml形式のファイルを読み込み、パイプでshellを実行する「sh -x」
設定ファイルからコンテナを作成する。
tinet up -c /mnt/c/tinet/spec_01.yaml | sh -x
tinet upで建てられたコンテナにIPアドレスを付与されたりして検証環境の構築が完了する。
tinet conf
コンテナにログイン
tinet経由でイメージをダウンロード→作成(tinet up)→起動(tinet up)→設定(tinet up)
ここで設定したコンテナにログインする。
docker exec -it cl1 /bin/bash
docker execでコンテナにログイン
ホスト名がUBUNTUからcl1になる。
cl1はコンテナの名前またはID
/bin/bash
コンテナ内で使用するシェルを指定
イーサネットフレームをみてみよう
主なツール
tcpdump、
Wireshark(ワイヤーシャーク)
tcpdumpでパケットを取得しWiresharkでパケットを解析
取得したパケットを/root/ethernet.pcapngに保存。
tcpdump -i net0 -w /root/ethernet.pcapng ether host 02:42:ac:01:10:01
イーサネットフレームを生成するためにpingコマンド利用
pingコマンドはネットワークの疎通ができているか確認するコマンド
multipass delete --purge UBUNTU
versionを変更してうまくいってたのに「Couldn't change ownership of savefile」が再発する場合
原因 macを再起動した時に起きる
multipass restart UBUNTU
su
tinet up -c /mnt/c/tinet/spec_02.yaml | sh -x
tinet conf -c /mnt/c/tinet/spec_02.yaml | sh -x
…
tcpdump -i net1 -w /tmp/tinet/arp.pcap arp
ARP
IPアドレスはOSに組み込まれる識別番号で、MACアドレスはNICに組み込まれる識別番号である。
MACアドレスはデータリンク層で動作し、IPアドレスはネットワーク層で動作するがそれぞれが独立して処理するとデータの整合性を保つことが難しくなる。そこでARPという技術を使ってIPとMACアドレスの相互変換を実現し、ネットワーク層とデータリンク層の架け橋を築く
IPパケットをイーサネットフレームとしてカプセル化するには、宛先MACアドレスの情報を含める必要がある。通信する相手のNICのアドレスを取得するには宛先IPを利用する必要がある。
通信を送る前に先んじて、宛先IPアドレスを利用して、MACアドレスのアドレスを把握することをアドレス解決という。
より詳しく見ると
IPアドレスはOSで設定する論理的なアドレスで
MACアドレスはNICに書き込まれる物理的なアドレス
ARPによるアドレス解決の流れ
ARPお仕事はIPアドレスとMACアドレスを紐づけること
ARPフレームのパケットキャプチャ
| ifconfig | |
|---|---|
| inet | ipアドレス |
| ether | macアドレス |
ifconfig
ip neigh
arpテーブルの表示
arpテーブルとはarpでアドレス解決したipとmacアドレスを紐づけて管理しておくテーブル
送信元のipアドレス、macアドレスを入れる(相手先のアドレスのこと)
tcpdump -i net1 -w /tmp/tinet/arp.pcap arp
ping 192.168.11.254 -c 2
L2スイッチング
L2スイッチング
送信元のMACアドレスからイーサネットフレームの転送先を決定することをL２スイッチングという
MACアドレステーブル
イーサネットフレームの送信元MACアドレスと受け取ったポート番号を管理するテーブル
macアドレステーブル
- cl1がイーサネットフレームをcl2に送る時、sw1(l2スイッチ)がまずそれを受け取る
- sw1側でフレームを受け取ったポート番号と送信元macアドレスをmacアドレステーブルに登録する
- sw1はcl2がどこに接続されているかわからないから、cl1のイーサネットフレームのコピーを作成し、cl1のポート以外に送信する。
- コピーフレームを受けとったcl2は、リプライパケットをcl2に送る。
- sw1でリプライパケットを受け取ったポート番号と送信元（cl2）のmacアドレスをmacアドレステーブルに追加する。
これによりmacアドレステーブルによってイーサネットフレームをl2スイッチング(転送先を切り替える)が可能になる
ip linkコマンド
macアドレスを手動で操作する時に利用
nicの情報を表示したり、nicを操作したりする時に利用する。
ip link set net0 addressでmacアドレスをcl2と同じものにしたが、こうするとmacアドレステーブルをもとにしてl2スイッチングの挙動が不安定になる。
VLAN(Virtual LAN)
L2スイッチを仮想的に複数のLANスイッチとして利用することができる
VLANを実現するための技術として、ポートVLANとタグVLANがある。
VLANの仕組み
ポートにVLAN IDを付与して異なるVLAN ID同士ではイーサネットフレームを送信できないようにし、ネットワークを区切ることを実現する
一般的なLAN環境では、運用やセキュリティのために利用される。例えば、部署ごとに通信を制限したりする時に利用される。
ポートVLAN
ポートVLANは1つのポートに対して、1つのVLANを割りあてる技術で異なるVLANでの通信ができなくなります。
タグVLAN
タグVLANを使うことで、1つのポートに複数のVLANを付与することが可能になる。
ここでVLANを単純に増やしてもVLANを識別することはできません。
そこでタグを付与することでVLANを増やし、識別が可能になるので一つのポートで複数のVLANが利用できるようになるのです。このタグがタグVLANです。
イーサネットフレームにVLAN情報をタグVLANとして付与する形で使用します。
タグVLANを利用することで、VLANが識別できるようになり1つのポートで複数のVLANからのイーサネットフレームを処理することができる。
そうすることで1つのポートで様々なネットワーク通信が可能になる。
オンプレミス環境では、ポートが有限なのでポートを増やすことなく効率的に扱うことができる
タグVLANで複数のVLANを作ったので、ここでは１つのポートを用意するだけで良くなる。￥￥
ネイティブVLAN
タグVLANとポートVLANだけではVLANのついていない純粋なイーサネットフレームを受けとった時にどの渡せばいいかという点で問題が生じます。
ハロゲン見ずにMACアドレステーブル作成までの流れをアウトプット
前提cl1、cl2はmacアドレスとipアドレスを備えています。
- cl1がcl2に対して、イーサネットフレーム(リクエストパケット)を送信する
- ポートがイーサネットフレームを受信する
- sw1（L2スイッチ）で送信元のMACアドレスと、受信したポート番号を紐付けてMACアドレステーブルに追加する。
- L2スイッチは宛先がわかっているが、どのインターフェースに接続されているのかわからない(イーサネットフレームをどこに流せばいいかわからない)ため、とりあえず全部のポートに流す(フラッディング)
- 全体に流して無事宛先に一致したMACアドレスに届いたら、cl2はイーサネットフレームを受け取る
- イーサネットフレームを受け取ったcl2はイーサネットフレーム(リプライパケット)を送信する。ここでもcl1のインターフェースがどこにあるかわからないのでフラッディングする。
- cl2のイーサネットフレームをポートが受信する
- L2スイッチでMACアドレステーブルに送信元の
MACアドレスと受信したポート番号を紐づけて追加する。 - これでcl1とcl2はそれぞれのどのインターフェースに接続されているのか判明したので以降フラッディングする必要がなくなります。
- MACアドレステーブルは一定時間通信しなくなると削除される。Ciscoはデフォルトで5分
ハロゲンARP(Address Resolution Protcol)の処理の流れ
ARPとはMAC、IPアドレスを相互に変換する技術のことである。
宛先MAC、宛先IPアドレスを何かしらの方法で結びつける必要がある。これを実現するのがARPである。
さらに具体的に説明すると宛先IPアドレスから宛先MACアドレスを求めることである(アドレス解決)
URLはDNSによって名前解決が行われるから、IPアドレスは未然にわかる状態でありMACアドレスがレイヤーが違うのでわからない。
疑問
- なぜお互いを認識しないのか
- どうやってお互いを認識するようになるのか
なぜお互いを認識しないのか
プロトコル(レイヤー)が異なるから
どうやってお互いを認識するようになるのか
MACアドレスとIPアドレスは一対一で対応しているが、プロトコルが異なるのでお互いを認識できない状況。そこでARPに、「宛先IPアドレスに対応するMACアドレス特定してくれない？」という形でお願い(ARPリクエスト)する。
同じネットワーク間での処理です。
- ネットワーク層から受け取ったパケットの中から、宛先IPアドレスを見て、自身のARPテーブルを一致するものがあるか探す。初めての通信なので次の処理へ
- データ通信に先立って、まずARPリクエストが飛ばされる
- どの宛先のMACアドレスがわからないから、ブロードキャストアドレスを使用してネットワーク内のすべてのデバイスに送信される。全てのデバイスにARPリクエストされる。
- ARPリクエストを
受け取ったデバイスは自身のIPと宛先IPが一致するか確認し、一致しなければ破棄、一致していればARPリプライを返す。 - 送信元のMACアドレスとIPアドレスをARPテーブルに書き込む
- ARPリプライに、リクエストの送信元が求めていたMACアドレスとIPアドレスが対応して書き込まれているので受信し、ARPテーブルに書き込む。]
参考
ハロゲンレイヤー3プロトコルを知る
rt1
インターネットとLANを繋げるブロードバンドルーター
さらにはNAT機能もある。
PCやタブレットにネットワークに関する設定を配布したり(DHCP機能)
rt2,rt3
インターネットルーター
インターネットを構成するルーター
インターネットとは世界中に点在するインターネットルーターが相互に接続されることによって構成されています。
ネットワーク層
データリンク層で接続できているネットワーク層をつなぎ合わせて、大きなネットワークを作ることを可能にする
ネットワーク層でのプロトコルはIPとICMPで、データのやり取りはIP、トラブルシューティングはICMP
IP
IPによってカプセル化されたパケットのことをIPパケット
IPパケットは色々な制御情報がセットされているIPヘッダー、データそのものを表すIPペイロード
IPヘッダーのフィールド
TTL(Time To Live)
IPパケットの寿命を表すフィールド
この寿命は経由するルーターの数で表す
TTLの値はルーターを経由するたびに(ネットワークを経由するたびに)減らされる
IPパケットを破棄したルーターは、破棄したことをICMPパケットで送信元端末に返す
IPアドレスとサブネットマスク
IPアドレスとは、IPネットワークに接続された端末を識別するID
(macアドレスはネットワーク機器を識別するためのIDで隣接する機器の通信を可能にする)
IPアドレスはネットワーク部とホスト部に分かれている。
ネットワーク部は「どのネットワークにいるのか」を表し、ホスト部は「どの端末なのか」を表す。
サブネットマスク
この二つを区切る目印のようなもの
IPアドレスとサブネットマスクを組み合わせることで、「どのIPネットワークにいるのかと、どの端末なのか」を識別できる
AWSでもサブネットという単語が出てくるが、ネットワークを区切るものとして利用されているからこの表現なのかと思う
ループバックアドレス
第一オクテッドが「127」から始まるアドレスのことで、それ以降の値はなんでもいいとされているが基本的には「127.0.0.1/8」を使用するのが一般的。
windows os、mac os、ubuntuでも通信で使用するIPアドレスとは別に自動的に「127.0.0.1/8」が設定されている
ループバックインターフェースが上
他の端末とやりとりするインターフェースが下
これを編集してわかりやすくする。後々見方を学習する必要はある
tcpdump -i net0 host 192.168.11.1 -w /tmp/tinet/ip.pcapng
ICMP(Internet Control Message Protcol)
縁の下の力持ち的な存在
IPレベルの通信を確認しラリ、色々なエラーを通知したりと、IPネットワークにおいて、なくてはならない非常に重要な役割を担っている。
pingではパケットをICMPパケットとして送信することができるのでネットワークの診断が可能になっている。
ICMPはその名の通り、InternetをControlするMessageのプロトコル
IPプロトコルを拡張したプロトコルであり、RFC792ではIPとICMPはどんな端末でもセットで実装されていなければならないというほどのもの
ICMPのパケットフォーマットのフィールドとして特に重要なのがタイプとコード
IPレベルの通信状態を確認したり、エラーを通知したりできる
IPレベルの通信状態を確認するときに使用されるICMPパケットが「echo request」、「echo reply」です。
タイプが8,コードが0のリクエストが送信される。
タイプが0,コードが0のリプライを受け取る
ルーターが異なるネットワークにいる端末にIPパケットを送信することをルーティングという
tcpdump -i net0 -w /tmp/tinet/icmp.pcapng cimp[7] == 1
実際にICMPのリクエストがタイプ8、コードが0
リプライがタイプ、コード0とパケットキャプチャから確認できた。
ネットワーク技術を知ろう
IPのネットワークはIPアドレスありきである。
宛先端末のIPアドレスがどのルーターの先にあるか、整理しながら学習を進めると効率的
IPで活躍する機器はルーター
ルーティング
ルーターは「IPパケットの宛先IPアドレスからなる宛先ネットワーク」と「IPパケットを転送すべき機器のIPアドレスを表すネクストホップ」という二つの情報を管理することでIPパケットの転送先を切り替えている。
ルーティングの動作
ルータはどのようにしてルーティングしているか
各地のルーターからルーティングを繰り返して、最終的な目的地に辿り着く
ルーティングテーブル
ルーティングの動作を制御するのがルーティングテーブル
ルーティングエントリ（行）
ルーティングエントリの作り方は二つある。
- 静的ルーティング
- 動的ルーティング
ルーターアプリケーション「FRR」
シェルに入ることで設定したり情報を見たりできる。
root@rt1:/# vtysh
Hello, this is FRRouting (version 9.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
ルーティングテーブルを見ると直接接続されている機器のipアドレスしかない
デフォルトゲートウェイがない状態でルーティングテーブルにないIPアドレスがくるとパケットを破棄されてしまう。
rt1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 10.1.1.244/30 is directly connected, net0, 00:00:35
C>* 192.168.11.0/24 is directly connected, net1, 00:00:35
ルーティングテーブルに検索でヒットしない時はrt2(10.1.1.246)へパケットを送信してねと言う感じができるようにエントリを追加
rt1# configure terminal
rt1(config)# ip route 0.0.0.0/0 10.1.1.246
rt1(config)# exit
rt1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
デフォルトゲートウェイを設定したので、rt1からfw1へpingができたがfw1からのreplayが返ってきていない
root@rt1:/# ping 10.1.1.253 -c 2
PING 10.1.1.253 (10.1.1.253) 56(84) bytes of data.
--- 10.1.1.253 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1026ms
rt2のルーティングテーブルを見てみる。
10.1.1.252/30というエントリはfw1(10.1.1.253)に含まれるものなので問題なくネクストホップ(fw1へパケットを転送)できる。
root@rt2:/# vtysh
Hello, this is FRRouting (version 9.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
rt2# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 10.1.1.244/30 is directly connected, net0, 00:35:32
C>* 10.1.1.248/30 is directly connected, net1, 00:35:32
C>* 10.1.1.252/30 is directly connected, net2, 00:35:32
fw1のルーティングテーブル
rt1の宛先ipアドレスがエントリに登録されていないことでecho replayが返せない。
root@fw1:/# vtysh
Hello, this is FRRouting (version 9.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
fw1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 10.1.1.252/30 is directly connected, net0, 00:42:18
C>* 172.16.1.0/24 is directly connected, net1, 00:42:18
rt1へのエントリを追加する
fw1(config)# ip route 0.0.0.0/0 10.1.1.254
fw1(config)# exit
fw1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
fw1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
**S>* 0.0.0.0/0 [1/0] via 10.1.1.254, net0, weight 1, 00:00:16 //追加したエントリ**
C>* 10.1.1.252/30 is directly connected, net0, 01:09:06
C>* 172.16.1.0/24 is directly connected, net1, 01:09:06
icmp echo request
| 宛先IP | 送信元IP |
|---|---|
| 10.1.1.253(fw1) | 10.1.1.245(rt1) |
icmp echo replay
| 宛先IP | 送信元IP |
|---|---|
| 10.1.1.245(rt1) | 10.1.1.253(fw1) |
再度pingを打つと成功する
root@rt1:/# ping 10.1.1.253 -c 2
PING 10.1.1.253 (10.1.1.253) 56(84) bytes of data.
64 bytes from 10.1.1.253: icmp_seq=1 ttl=63 time=0.162 ms
64 bytes from 10.1.1.253: icmp_seq=2 ttl=63 time=0.273 ms
--- 10.1.1.253 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1040ms
rtt min/avg/max/mdev = 0.162/0.217/0.273/0.055 ms