 Okay, we'll move to the next session. It's going to be a lightning talk by Leon. It's TCP dumping your pods using cube SNF and Wireshock. Leon Nune is a technical support engineer at solo.io, next enthusiast with a knack for blogging. Welcome, Leon. Hi, everyone. Good afternoon. Hope the lunch was good. So yeah, my talk is going to be about TCP dumping on Kubernetes and Wireshock. So the agenda, so about me, I'm a technical support engineer at solo.io. So most of my work and most of my talks are use cases. So day-to-day I'm solving queries with customers on our products and we have to use Kubernetes. So most of these tools that I'm going to show today was a use case. So we had to sort of troubleshoot a proxy connection and we weren't able to figure out why the connection was breaking. So this is the quick agenda. So I'm going to just talk about quickly what traffic analysis is, a quick introduction to TCP dump, understanding how these can help you. And lastly, I'm going to show two tools. One is case SNF and one is cube shark. So what is traffic analysis? So in general, traffic analysis can be a lot of things. It could be monitoring your network for performance, seeing network packets, how they flow in your network and catching things like latency and all these things. So in Kubernetes, there are a lot of tools. So this use case is more of the underlying level. So when everything like troubleshooting time, we do a lot of things. We go to logs, we go through different tools. But at the end of the day, it's all network. You have to see how packets move from application A to application B. And with proxies, it's a very different thing. So these are the use cases for traffic analysis, there is network troubleshooting, there is curl command works, but your app doesn't. It's a very fair use case I have seen working with proxies. Proxies work in a different way compared to your curl command. Some are RFC based, some are not. So you have to be very careful while troubleshooting this. Each proxy works in a different way. So you can do performance analysis, you can do network forensics, like if your packet is not reaching a destination, where has it gone, right? So you can also check things like this using tools like TCP dump and all. But these were used mostly during the VM era of things, right? Not much during Kubernetes. I've never heard people using TCP dump on Kubernetes. You may use it on a node or something like that, but never in the cluster. So TCP dump is a network analyzer, I'm pretty sure everybody has heard of it. If not, it's basically something that can monitor your traffic. And if you put it into a promise case mode, you can even monitor your entire network, right? Just from one node. It has to be just, just has to be capable of monitoring the entire node. So you can filter traffic based on conditions, like you can export it to a pcap file. And then you can use that pcap file to visualize data in something called as wireshark, right? Wireshark is a very popular tool I am sure everyone who has had their hand in hacking has heard about Wireshark. It's a very good tool. It helps you visualize networks. You can read network traffic. You can also follow a packet. So if you have one packet and you want to see where that packet is going, you can just follow it using the HTTP stream or the TCP stream. Yeah, so these are the terms that are frequently seen in a Wireshark output. There is a syn or a synchronous message that is sent. There's an act, meaning you send a syn, you get an acknowledgement, there's a finish. And then there's also a last thing called as RHD. So RHD is mostly errors. If I send a connection and I get a connection reset, basically that's like an RHD, right? So you can think of things like for RHD is where people try to troubleshoot the issue. Because most of the times you will get a connection reset or timeout. Timeout is mostly viable, but connection reset is something dropping the packet, basically. Yeah, so the following tools are mostly used. T-Shark is a terminal Wireshark and TCP dump, Wireshark and Cystic. Cystic is popular pretty much, a very good tool, I'd say. So in this demo, I'm going to be using something called as Glue Edge. That is the product that I work with. Along with that, there will be CubeSniff and CubeShark. So CubeShark is an additional thing. So to set the context for what the demo is, is basically we have a use case where we have to connect this Glue Edge, which is an API gateway, to something called as a proxy that is outside of the cluster. So the use case that was there, we had to troubleshoot why the connection wasn't going to a proxy. So a proxy is just a normal thing. You have two types of proxies, a reverse proxy or a forward proxy. This one was a forward proxy. So whatever host you sent it, it would send it to the destination. It wouldn't do anything. It wouldn't do things like TLS termination or anything as such. So yeah, that's it for the demo. So there are two proxies here. One is a squared proxy, one is an NGINX proxy. I don't know if it's visible, it's a video, so I can't zoom in. But yeah, so okay, all right, so here we have the Kubernetes cluster. The gateway proxy is something that is the entry point into the cluster. It's not an ingress, it's a load balancer type service. And this is where the connection will come through. So yeah, so this is a simple virtual service that we have to create. So anyone familiar with Apache, Apache server, Apache web server? So you all know what a virtual host is, right, where you define your connections and you let the traffic come in. So similar to that, you have a virtual service. You define a header type proxy and whichever value, it will route it to the upstream. And in our case, upstream could be anything. It can be a virtual machine on a different server. It can be a proxy in this case or it can be just a Kubernetes service, right? So yeah, so this is how we are probably doing a proxy connection. So this 192 is something that's on my machine and it's running on this port. And this is HTTP bun that we are going to sort of reach out to. So this is a static upstream. So you have to mention where you want to go to. And it's all static. I'm not sure it's stuck in between. Okay. So yeah, so the first connection that is there up is the one that went to proxy squared. And you can see we got a response, but the second one. So glue edge is based on on why. So this is a typical on why error message that says connect error, disconnect reset before headers. And we see a TLS error, which is because NGNX doesn't support the connect protocol. So the way proxies work is you have to send a connect request like a bi-directional tunnel. So once you send a connect request is when you can then, you know, establish like a tunnel and then the next data is sent, for example, things like the header or the host name that you want to forward to NGNX does not support that. And the use case was another proxy, but similar to NGNX. So we couldn't sort of, you know, figure out why the connection did not work because we did not have access to anything apart from the Kubernetes cluster. So yeah. So this is how you can run case sniff. So it's a bit hidden, but so that's the kubectl case sniff command. What it does is it will create a privilege board in your cluster and then it will launch the traffic. It will launch a stream to Viasha. But one thing is there that this is not production ready. So it's just a tool. There is another tool, CubeShark, like I said, right? So CubeShark is something that is, I think, production ready. It's also got like a paid thing with it. So this is how you will get a Viasha interface, right? And you'll see like a lot of traffic that is going through the gateway proxy. And for example, just to see, yeah, so if you notice here, there's a connect request and then you can see this bad request. So this isn't visible, to be honest, unless you inspect the network traffic to see what happened between your cluster and the proxy. So this is one way of sort of troubleshooting network traffic. So you can see a lot of details here. And if you right-click on that, you should be able to go through the TCP stream also. I don't remember if I have taken that also in the video. So yeah, this is CubeShark. So case-niff, just as Viasha, CubeShark gives you a web interface sort of. So if you notice here, you will get like a web interface. It is a bit limited compared to Viasha, I would say. But then again, Viasha is quite mature, it's as old as me. It just had its birthday a few days ago. So yeah, in CubeShark, you can see something like this, like a web browser page. And then if you filter out the data, you can then see the similar request, but you cannot follow request here. So if you compare it to Viasha, which is a very mature tool, it is still a very new tool, but it's a useful tool for network analysis. And you can do a lot of things. There is also something called as a service map here. So if you're using a service mesh, it also helps in that case. So that's it. Thank you. I don't think so. Any questions? Any questions? We'll take the questions offline for lightning sessions. Thank you. One minute, Leon. We'd like to give a small token of appreciation to Leon.