IPプロトコル番号はIPv4 headerのProtocol fieldやIPv6のNext Headerで上位protocolを識別する番号です。TCPは6、UDPは17、ICMPは1です。port番号はTCP/UDP header内でapplication endpointを識別するため、同じ『番号』でも見るlayerと位置が違います。
暗記不要⚠️
だけど
ネットワークエンジニアが
ACL設定する時とかオプションで
プロトコル番号を指定することがあるから
プロトコルに番号がそもそもあんのか
って事を知ってると役立つやつ!🖐️✅ICMP(1)
ネットワーク診断やエラー通知に使われるプロトコル。ping✅IGMP(2)… pic.twitter.com/OOt3O0nXhQ
— けんと@設計構築チャンネル (@yeiquer12) 2024年12月1日
ACLなどで指定するIPプロトコル番号は、TCP・UDPのポート番号とは別物だと説明したポスト。
IPプロトコル番号とは?
先に答えると、IPプロトコル番号はIPv4 headerのProtocol fieldやIPv6のNext Headerで上位protocolを識別する番号です。TCPは6、UDPは17、ICMPは1です。port番号はTCP/UDP header内でapplication endpointを識別するため、同じ『番号』でも見るlayerと位置が違います。
ポート番号とは何が違う?
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| IP protocol 1 | ICMP | ICMPにはTCP/UDP portなし |
| IP protocol 6 | TCP | source/destination portあり |
| IP protocol 17 | UDP | source/destination portあり |
| TCP port 443 | HTTPSでよく使うdestination port | protocol 6のheader内 |
Ethernet | IPv4 Protocol=6 | TCP src=51500 dst=443 | TLS data
Ethernet | IPv4 Protocol=1 | ICMP type=8 code=0 | Echo Request
ACLではprotocolとportをどう指定する?
ACLではprotocolとportをどう指定する?では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 通信要件からL3 protocolを特定 | ICMP/TCP/UDP/他 |
| 2 | TCP/UDPの場合だけportを特定 | source/destinationを分ける |
| 3 | ACLのvendor syntaxへ変換 | object名の中身も確認 |
| 4 | captureとcounterで実packetを照合 | 想定headerと一致 |
ip access-list extended SAMPLE
10 permit icmp 192.0.2.0 0.0.0.255 host 203.0.113.10 echo
20 permit tcp 192.0.2.0 0.0.0.255 host 203.0.113.10 eq 443
30 permit udp 192.0.2.0 0.0.0.255 host 203.0.113.53 eq 53
show ip access-lists SAMPLE
IPv4 Protocol: TCP (6)
Transmission Control Protocol
Source Port: 51500
Destination Port: 443
Wiresharkでどのfieldを見る?
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| protocol 443と書く | protocol numberとportを混同 | TCP 6 + destination port 443 |
| ICMPへportを指定 | header構造誤認 | type/codeを確認 |
| UDP DNSだけ許可 | TCP DNS等の要件漏れ | service要件を確認 |
| application名だけでrule作成 | 実protocol不明 | capture/official service仕様 |
設定ミスをどう防ぐ?
ACL reviewでは『HTTPSだから443』で止めず、packetがTCPか、宛先portか、戻り通信をstatefulに扱うかを確認します。IANA registryは番号の正本ですが、実applicationがそのportだけを使う保証ではありません。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ:protocol fieldとTCP/UDP port fieldを別layerとして読む
protocol fieldとTCP/UDP port fieldを別layerとして読むことが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
