More than 1 year has passed since last update.

IBM Cloud: Transit VPCの構成例

Last updated at 2023-11-01Posted at 2023-01-30

1. はじめに

IBM Cloud VPCでTransit VPCを構成してみた。Transit VPCを利用することで、オンプレミスのユーザーは対象のVPCに直接接続するのではなく、中継のVPC（Transit VPC, Hub VPC, Landing Zone VPC, Edge VPCなど色々な呼ばれ方がある)を必ず経由し、そこで一旦セキュリティーチェックなどを実施してから転送される、といった構成が可能となる。今回はPower Systems Virtual Server(AIX)をオンプレミス相当と見做して接続を試行する（今回の例は単純化のためにALBなどは利用していない）。今回の構成では、NGFWとしてはPalo AltoやCheckPointのような途中経路でIPアドレスを変更しない透過型Firewallを想定している。

なお、以下のリンクが参考になる。

2. VPC(Spoke)のVSIに接続する構成例

2-1. 構成のポイント

on-premiseとTransit VPC(Hub)はDirect Linkで接続する。その際に、Transit VPC(Hub)にはSpoke側のVPCを包括するようなaddress prefix(この例では172.17.0.0/16)を構成する。このaddress prefixにはsubnetを定義してはいけない。あくまでオンプレミスにSpoke宛の経路をBGP広告をするためのダミーのaddress prefixである。これにより、例えば上図の172.17.0.5宛の経路は、Direct Link経由でオンプレミスに広告されるため、Transit VPC(Hub)にパケットは到達可能となる。
このSpoke宛のパケットは、Custom route table(Ingress)を使って、NGFWである10.0.0.10に転送する。
NGFWに到達したパケットは、セキュリティーチェックを実施した後、再度宛先である172.17.0.5への転送が行われる。パケットのsourceは192.168.50.223、destinationは172.17.0.5のままである。
- 今回は、透過型ファイアウォールのNGFWに見立てて、/proc/sys/net/ipv4/ip_forwardを1にしたLinuxサーバーを利用している。
- NGFWが保持していないIPアドレスに対しての送受信が行われるので、Allow IP Spoofingを有効にする。
IBM Cloud: Transit Gatewayに接続するVPC間で、prefixが重複している際の挙動でも解説した通り、VPC間でaddress prefixが重複していても接続先のVSI側にあるVPCのaddress prefix長の方が短く、しかも接続対象のVSIのsubnetを接続元VPC側で保持していないのであれば、Prefix Filteringの設定なしでTransit Gateway経由で接続可能である。そのため、VPC2(Spoke)のVSI(172.17.0.5)にパケットは到達可能である。
戻りのパケットもTransit VPC経由で返ってほしいため、オンプレミス宛のパケットはTransit VPCのNFGWを経由するようにVPC2(Spoke)側のCustom route table(Egress)で、next hopがNGFWになるように構成する。

2-2. 構成の画面キャプチャー（一部）

Transit VPC(Hub VPC): NGFWにおけるIP Spoofingの構成
Transit VPC(Hub VPC): NGFWにおけるIP Forwardingの構成

NGFWでIP Forwardingを有効にする（この設定は再起動したら無効になるが、今回はテストなのでこのように構成する）

[root@syasuda-ngfw-transit1 ~]# echo 1 > /proc/sys/net/ipv4/ip_forward

Transit VPC(Hub VPC): Custom Route table(Ingress)
Spoke VPC: Custom Route table(Egress)

2-3. 接続テスト

Power Systems Vitual Server(192.168.50.223)からのping

bash-4.3# ping 172.17.0.5
PING 172.17.0.5 (172.17.0.5): 56 data bytes
64 bytes from 172.17.0.5: icmp_seq=0 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=1 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=2 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=3 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=4 ttl=54 time=2 ms
64 bytes from 172.17.0.5: icmp_seq=5 ttl=54 time=2 ms

NGFW(10.0.0.10)でのtcpdump

[root@syasuda-ngfw-transit1 ~]# tcpdump -i any icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
02:15:20.369549 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 0, length 64
02:15:20.369575 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 0, length 64
02:15:20.370200 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 0, length 64
02:15:20.370205 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 0, length 64
02:15:21.369498 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 1, length 64
02:15:21.369521 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 1, length 64
02:15:21.370165 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 1, length 64
02:15:21.370169 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 1, length 64
02:15:22.369610 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 2, length 64
02:15:22.369635 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 2, length 64
02:15:22.370399 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 2, length 64
02:15:22.370403 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 2, length 64
02:15:23.369607 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 3, length 64
02:15:23.369630 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 3, length 64
02:15:23.370318 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 3, length 64
02:15:23.370323 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 3, length 64
02:15:24.369651 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 4, length 64
02:15:24.369674 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 4, length 64
02:15:24.370298 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 4, length 64
02:15:24.370303 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 4, length 64
02:15:25.369706 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 5, length 64
02:15:25.369729 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 5, length 64
02:15:25.370344 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 5, length 64
02:15:25.370349 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 5, length 64

接続先VSI(172.17.0.5)でのtcpdump

[root@syasuda-spoke-target1 ~]# tcpdump -i any icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
02:15:20.369793 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 0, length 64
02:15:20.369822 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 0, length 64
02:15:21.369756 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 1, length 64
02:15:21.369787 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 1, length 64
02:15:22.370027 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 2, length 64
02:15:22.370055 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 2, length 64
02:15:23.369946 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 3, length 64
02:15:23.369978 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 3, length 64
02:15:24.369924 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 4, length 64
02:15:24.369956 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 4, length 64
02:15:25.369963 IP 192.168.50.223 > 172.17.0.5: ICMP echo request, id 260, seq 5, length 64
02:15:25.369992 IP 172.17.0.5 > 192.168.50.223: ICMP echo reply, id 260, seq 5, length 64

3. VPC(Spoke)のALB/NLBに接続する構成例

docsでの例にあるように、以下のように構成することも可能。これは、オンプレミスから見た接続先VSIがALB/NLBに変わっただけなので、上記構成と本質的には構成は変わらない。

3-1. Spoke側にALBを配置する場合

ALBが172.17.0.0/24に配置されていれば、特に追加設定なしで通信可能。ALBのバックエンドサーバーがどのAZに配置されていても良い。

VPC(hub)でALB利用時のテスト結果

bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo1-web1
bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo2-web1

3-2. Spoke側にNLBを配置する場合

NLBが172.17.0.0/24に配置されていれば、そのバックエンドサーバーがどのAZに配置されていても、そのAZからのcustom route（egress)でのオンプレミス宛（192.168.50.0/24)へのnext hopがNGFW(10.0.0.10)に設定されていれば、通信可能（NLB はDirect Server Returnになることに注意）。

VPC(hub)でNLBのテスト結果

bash-4.3# curl http://172.17.0.8
tokyo1-web1
bash-4.3# curl http://172.17.0.8
tokyo2-web1

4. VPC(hub)におけるNGFWを冗長化した構成例

既存の構成では、NGFWがSingle Point of Failure(SPOF)になっているため、冗長化したい。そのためには、NFGWを2台配置し、NLB(route mode)を利用する。
以下に構成図を記載する。

4-1. 構成のポイント

単にNLBを利用すると、DNATが発生してしまうため、透過型Firewallとしての体をなさない。NLB(route mode)を利用することで、パケットの宛先・送信元を変更することなく、ActiveなNGFWに転送が可能である。
NLB(route mode)の詳細については、IBM Cloud: VPCで透過的ファイアーウォールを作る方法(2)を参照のこと。
on-premiseからのパケットはNGFWに転送するのではなく、NLB(route mode)に転送する必要がある。そのためVPC(hub)のIngress route tableにおける、172.17.0.0/24宛のパケットはNLB(route mode)をnext hopとしている。同様の理由で、VPC(spoke)においても、next hopはNLB(route mode)である。
VPC(hub)のIngress route tableにも、新たにVPC(Spoke)のEgress route tableと全く同じ内容が追加されているのが特徴。これがなくても一見稼働するように見えるが、実はNLB(route mode)のメンテナンス時の挙動を考慮すると必要な設定である。
- 普通のNLBはVIPが割り当てられているが、NLB(route mode)はActive/Standbyそれぞれに別のIPアドレスが割り当てられている。
- NLB(route mode)を利用しているVPC内で、NLB(route mode)のActive側のIPアドレスをnext hopとするようなCustom Routeを構成した場合に、もしそのNLB(route mode)にメンテナンスが発生した場合はどうなるだろうか？実は、NLB(route mode)にメンテナンスが発生した場合は、新たにActiveとなる方のIPアドレスがnext hopになるように、既存のcustom routeが自動的に更新される仕組みになっている。
- よって、VPC(hub)側だけであればNLB(route mode)にメンテナンスが発生しても利用可能だが、このroute tableの更新はVPC(hub)のroute tableに対してのみしか行われないことに注意が必要である。つまり、VPC(spoke)側のroute tableは更新されないため、その手当てが別途必要になる。この設定をVPC(hub)のingress route tableに追加することにより、VPC(spoke)側のroute tableが更新されなくてもActiveなNLB(route mode)にパケットが転送されるようになる。

（参考1） https://cloud.ibm.com/docs/vpc?topic=vpc-config-custom-routes&locale=en

If the NLB fails over to the other node, the custom routes are automatically updated to hop to the new NLB IP address.

（参考2） https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vnf&interface=ui&locale=en

NLB route mode has two IP addresses (Active/Standby).

NLB route mode is designed to be transparent. When a failover occurs, route mode updates all routing rules created under the same VPC with the next_hop of the Standby appliance IP. As a result, both IPs may be used during the lifetime of your NLB with route mode.

In the case of a Transit VPC configuration, you may want to deploy the NLB in vpc-hub and configure the egress route in vpc-spoke. This will force data back to the NLB with route mode in vpc-hub. Ensure that you also add the equivalent ingress rules of the vpc-spoke egress rules to vpc-hub so that the egress rules do not need to be changed. Once the traffic reaches vpc-hub, the ingress routing rule will overwrite the next_hop and send it to the primary appliance.

4-2. 構成の画面キャプチャー（一部）

VPC(hub)のingress route table
VPC(spoke)のegress route table
NLB(route mode)

4-3. 接続テスト

Power Systems Vitual Server(192.168.50.223)からのテスト結果

bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo1-web1
bash-4.3# curl http://xxxxxxxx-jp-tok.lb.appdomain.cloud
tokyo2-web1

VPC(hub)におけるNGFWでのtcpdump

[root@syasuda-ngfw-transit1 ~]# tcpdump -i any port 80 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
05:05:17.164404 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [S], seq 766707901, win 65535, options [mss 8960,nop,wscale 3,nop,nop,TS val 1720349635 ecr 0], length 0
05:05:17.164425 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [S], seq 766707901, win 65535, options [mss 8960,nop,wscale 3,nop,nop,TS val 1720349635 ecr 0], length 0
05:05:17.165161 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [S.], seq 3780808846, ack 766707902, win 31856, options [mss 1460,nop,nop,TS val 3321979038 ecr 1720349635,nop,wscale 9], length 0
05:05:17.165166 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [S.], seq 3780808846, ack 766707902, win 31856, options [mss 1460,nop,nop,TS val 3321979038 ecr 1720349635,nop,wscale 9], length 0
05:05:17.166748 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 0
05:05:17.166752 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 0
05:05:17.166759 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [P.], seq 1:99, ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 98: HTTP: GET / HTTP/1.1
05:05:17.166761 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [P.], seq 1:99, ack 1, win 32761, options [nop,nop,TS val 1720349635 ecr 3321979038], length 98: HTTP: GET / HTTP/1.1
05:05:17.177312 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [P.], seq 1:273, ack 99, win 63, options [nop,nop,TS val 3321979050 ecr 1720349635], length 272: HTTP: HTTP/1.1 200 OK
05:05:17.177315 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [P.], seq 1:273, ack 99, win 63, options [nop,nop,TS val 3321979050 ecr 1720349635], length 272: HTTP: HTTP/1.1 200 OK
05:05:17.179074 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [F.], seq 99, ack 273, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979050], length 0
05:05:17.179083 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [F.], seq 99, ack 273, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979050], length 0
05:05:17.179713 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [F.], seq 273, ack 100, win 63, options [nop,nop,TS val 3321979053 ecr 1720349636], length 0
05:05:17.179717 IP 172.17.0.7.80 > 192.168.50.223.49152: Flags [F.], seq 273, ack 100, win 63, options [nop,nop,TS val 3321979053 ecr 1720349636], length 0
05:05:17.181143 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 274, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979053], length 0
05:05:17.181146 IP 192.168.50.223.49152 > 172.17.0.7.80: Flags [.], ack 274, win 32761, options [nop,nop,TS val 1720349636 ecr 3321979053], length 0

5. VPC(Spoke)のVPEに接続する構成例

ここでは、VPC(Spoke)に存在するIBM Cloud Databases for PostgreSQLへの接続を試みてみる。VPEは、172.17.0.0/24内のIPアドレスを利用する。
どのようにVPC(Spoke)におけるFQDNをオンプレミス側から名前解決させるのかというDNS構成上の検討が別途必要なのだが、それは既に解決されているという前提とする。

上記構成前の接続試行。名前解決はできている。

[root@power-rhel8 ~]# ping xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud
PING xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud (172.17.0.10) 56(84) bytes of data.
^C
--- xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

5-1. 構成のポイント

特に上記4の構成から変更なく、以下のような構成でもアクセスできそうなものだが、実は接続できない。

Power Systems Virutal Servers(192.168.50.224)からのPostgreSQL接続

[root@power-rhel8 ~]# PGPASSWORD=${PGPASSWORD} PGSSLROOTCERT=631b75c3-4296-4ce9-b0f2-426423c5b0e6 psql "host=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud port=31269 dbname=ibmclouddb user=admin sslmode=verify-full"
（失敗）

NGFWでのパケットキャプチャー

[root@syasuda-ngfw-transit1 ~]# tcpdump -i any port 31269 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:21:03.574212 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606330792 ecr 0,nop,wscale 10], length 0
00:21:03.574238 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606330792 ecr 0,nop,wscale 10], length 0
00:21:04.635689 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606331854 ecr 0,nop,wscale 10], length 0
00:21:04.635710 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606331854 ecr 0,nop,wscale 10], length 0
00:21:06.715791 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606333934 ecr 0,nop,wscale 10], length 0
00:21:06.715813 IP 192.168.50.224.49682 > 172.17.0.10.31269: Flags [S], seq 1957999281, win 26880, options [mss 8960,sackOK,TS val 3606333934 ecr 0,nop,wscale 10], length 0

上記のように、NGFWまではちゃんと届いており、VPEへの送信までは行われているが、返りのパケットがNGFWに届いていないことがわかる。実は、VPEではegress route tableが使われないという制約が現時点で存在する。そのため、戻りのパケットがVPC(hub)に返ってきていないのである。
暫定の回避策としては、on-premise(Power Systems Virtual Server)への経路がVPC(hub)に戻るようにVPC(hub)にオンプレミス用のダミーのaddress prefixを構成することである。しかし、この方法ではVPC(hub)のどれか1つのゾーンにしかパケットを戻せないという制約が残ることに注意。なお、VPC(hub)にさえパケットが戻ってこれば、その後はIngress route tableでNLB(route mode)に転送できる。

5-2. 構成の画面キャプチャー（一部）

新規に追加したダミーのAddress Prefix

5-3. 接続テスト

Power Systems Virutal ServersからのPostgreSQL接続

[root@power-rhel8 ~]# PGPASSWORD=${PGPASSWORD} PGSSLROOTCERT=631b75c3-4296-4ce9-b0f2-426423c5b0e6 psql "host=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxx.private.databases.appdomain.cloud port=31269 dbname=ibmclouddb user=admin sslmode=verify-full"
psql (12.12, server 12.11)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

ibmclouddb=>

NGFWでのパケットキャプチャー

[root@syasuda-ngfw-transit1 ~]# tcpdump -i any port 31269 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:57:02.382159 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [S], seq 4193277481, win 26880, options [mss 8960,sackOK,TS val 3608489600 ecr 0,nop,wscale 10], length 0
00:57:02.382185 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [S], seq 4193277481, win 26880, options [mss 8960,sackOK,TS val 3608489600 ecr 0,nop,wscale 10], length 0
00:57:02.400770 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [S.], seq 3058133977, ack 4193277482, win 65535, options [mss 1440,sackOK,TS val 4173787318 ecr 3608489600,nop,wscale 9], length 0
00:57:02.400790 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [S.], seq 3058133977, ack 4193277482, win 65535, options [mss 1440,sackOK,TS val 4173787318 ecr 3608489600,nop,wscale 9], length 0
00:57:02.402331 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 1, win 27, options [nop,nop,TS val 3608489620 ecr 4173787318], length 0
00:57:02.402336 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 1, win 27, options [nop,nop,TS val 3608489620 ecr 4173787318], length 0
00:57:02.407389 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 1:9, ack 1, win 27, options [nop,nop,TS val 3608489625 ecr 4173787318], length 8
00:57:02.407398 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 1:9, ack 1, win 27, options [nop,nop,TS val 3608489625 ecr 4173787318], length 8
00:57:02.412749 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [.], ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 0
00:57:02.412759 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [.], ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 0
00:57:02.412768 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 1:2, ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 1
00:57:02.412771 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 1:2, ack 9, win 128, options [nop,nop,TS val 4173787329 ecr 3608489625], length 1
00:57:02.414582 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2, win 27, options [nop,nop,TS val 3608489632 ecr 4173787329], length 0
00:57:02.414591 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2, win 27, options [nop,nop,TS val 3608489632 ecr 4173787329], length 0
00:57:02.417008 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 9:298, ack 2, win 27, options [nop,nop,TS val 3608489635 ecr 4173787329], length 289
00:57:02.417016 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 9:298, ack 2, win 27, options [nop,nop,TS val 3608489635 ecr 4173787329], length 289
00:57:02.420253 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2:101, ack 298, win 131, options [nop,nop,TS val 4173787339 ecr 3608489635], length 99
00:57:02.420262 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2:101, ack 298, win 131, options [nop,nop,TS val 4173787339 ecr 3608489635], length 99
00:57:02.422126 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 298:626, ack 101, win 27, options [nop,nop,TS val 3608489640 ecr 4173787339], length 328
00:57:02.422135 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 298:626, ack 101, win 27, options [nop,nop,TS val 3608489640 ecr 4173787339], length 328
00:57:02.433719 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 101:2928, ack 626, win 133, options [nop,nop,TS val 4173787352 ecr 3608489640], length 2827
00:57:02.433738 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 101:2928, ack 626, win 133, options [nop,nop,TS val 4173787352 ecr 3608489640], length 2827
00:57:02.435381 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2928, win 32, options [nop,nop,TS val 3608489653 ecr 4173787352], length 0
00:57:02.435385 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 2928, win 32, options [nop,nop,TS val 3608489653 ecr 4173787352], length 0
00:57:02.435732 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 626:700, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 74
00:57:02.435735 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 626:700, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 74
00:57:02.435758 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 700:810, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 110
00:57:02.435759 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 700:810, ack 2928, win 32, options [nop,nop,TS val 3608489654 ecr 4173787352], length 110
00:57:02.442131 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2928:3007, ack 810, win 133, options [nop,nop,TS val 4173787360 ecr 3608489654], length 79
00:57:02.442134 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 2928:3007, ack 810, win 133, options [nop,nop,TS val 4173787360 ecr 3608489654], length 79
00:57:02.442140 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3007:3086, ack 810, win 133, options [nop,nop,TS val 4173787361 ecr 3608489654], length 79
00:57:02.442142 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3007:3086, ack 810, win 133, options [nop,nop,TS val 4173787361 ecr 3608489654], length 79
00:57:02.443762 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3086, win 32, options [nop,nop,TS val 3608489662 ecr 4173787360], length 0
00:57:02.443765 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3086, win 32, options [nop,nop,TS val 3608489662 ecr 4173787360], length 0
00:57:02.445113 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3086:3121, ack 810, win 133, options [nop,nop,TS val 4173787363 ecr 3608489654], length 35
00:57:02.445120 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3086:3121, ack 810, win 133, options [nop,nop,TS val 4173787363 ecr 3608489654], length 35
00:57:02.446850 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 810:873, ack 3121, win 32, options [nop,nop,TS val 3608489665 ecr 4173787363], length 63
00:57:02.446858 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [P.], seq 810:873, ack 3121, win 32, options [nop,nop,TS val 3608489665 ecr 4173787363], length 63
00:57:02.451053 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3121:3468, ack 873, win 133, options [nop,nop,TS val 4173787370 ecr 3608489665], length 347
00:57:02.451061 IP 172.17.0.10.31269 > 192.168.50.224.50280: Flags [P.], seq 3121:3468, ack 873, win 133, options [nop,nop,TS val 4173787370 ecr 3608489665], length 347
00:57:02.495809 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3468, win 35, options [nop,nop,TS val 3608489714 ecr 4173787370], length 0
00:57:02.495827 IP 192.168.50.224.50280 > 172.17.0.10.31269: Flags [.], ack 3468, win 35, options [nop,nop,TS val 3608489714 ecr 4173787370], length 0

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up