domicmeia

domicmeia/[Networking]ping google.com

Created Tue, 26 Mar 2024 19:15:49 +0900 Modified Mon, 01 Apr 2024 14:58:58 +0900
1475 Words 7 min
Networking Troubleshooting

This post was written for studying. There maybe a lot wrong going on.

목차

What happend when you enter google.com?

1. 브라우저는 캐싱된 DNS 기록이 있는지 체크하고, 만약 캐시가 있다면 캐시의 정보를 이용하고 없다면 DNS 서버에 정보를 요청해야 한다.
2. 클라이언트는 DHCP Request를 UDP 패킷에 담고, UDP 패킷을 IP 데이터크램에 담고, IP 데이터그램을 프레임에 담는다. 이 프레임은 LAN에서 브로드캐스트 되어 DHCP Server에 도달한다. 
3. DHCP Server는 DHCP Request를 받고 DHCP ACK를 보낸다. DHCP ACK는 클라이언트의 IP주소, 1st-hop 라우터(가장 가까운 라우터)의 IP 주소, DNS server의 IP주소를 포함한다. 따라서 클라이언트는 가장 가까운 라우터의 IP주소 및 DNS 서버의 IP주소를 알게되었다. 
4. 하지만 클라이언트는 아직 1st-hop라우터의 MAC주소를 알지 못한다. 클라이언트는 ARP query를 브로드캐스트하고 1st-hop라우터는 ARP reply를 통해 자신의 MAC주소를 전달한다. 
5. 드디어 클라이언트는 DNS 서버에 DNS query를 보낼 수 있게 되었다. 클라이언트는 DNS query를 ip 데이터그램에 담아 1st-hop 라우터에 보낸다. 1st-hop 라우터는 RIP, OSPF, IS-IS, BGP 등의 프로콜로 생성된 Routing Table과 Forwarding Table을 참고하여 DNS query를 DNS 서버에 전송한다. DNS query를 받은 DNS 서버는 www.google.com의 IP 주소를 클라이언트로 전송한다. 드디어 클라이언트는 구글의 IP 주소를 알게 되었다! 
6. 클라이언트는 TCP 소켓을 열고 구글 서버와 3-way handshake를 통해 TCP connection을 설립한다. 이후 TCP 소켓을 통해 HTTP Request를 구글 서버에 보내고, 구글 서버는 HTTP Reply를 클라이언트에 보낸다.
7. 드디어 사용자는 구글의 첫 화면을 모니터에서 보게된다!
  1. The browser checks for cached DNS records, and if there is a cache, it uses that information. If not, it needs to request information from the DNS server.
  2. The client encapsulates the DHCP Request in a UDP packet, then encapsulates the UDP packet in an IP datagram, and finally encapsulates the IP datagram in a frame. This frame is broadcasted on the LAN and reaches the DHCP Server.
  3. The DHCP Server receives the DHCP Request and sends a DHCP ACK. The DHCP ACK includes the client’s IP address, the IP address of the 1st-hop router (closest router), and the IP address of the DNS server. Thus, the client learns the IP address of the closest router and the DNS server.
  4. However, the client still doesn’t know the MAC address of the 1st-hop router. The client broadcasts an ARP query, and the 1st-hop router responds with an ARP reply, providing its MAC address.
  5. Finally, the client can send a DNS query to the DNS server. The client encapsulates the DNS query in an IP datagram and sends it to the 1st-hop router. The 1st-hop router, based on Routing Table and Forwarding Table generated by protocols like RIP, OSPF, IS-IS, BGP, forwards the DNS query to the DNS server. Upon receiving the DNS query, the DNS server sends back the IP address of www.google.com to the client. Now, the client finally knows the IP address of Google!
  6. The client opens a TCP socket and establishes a TCP connection with the Google server via a 3-way handshake. Subsequently, the client sends an HTTP Request to the Google server through the TCP socket, and the Google server responds with an HTTP Reply to the client.
  7. Finally, the user sees Google’s homepage on the monitor!

Troubleshooting

Why can’t i ping Google?

If we can reach something by IP but not by name, then something’s wrong with DNS lookup:

Things that could cause this:

  • DNS server down
  • Misconfigured of /etc/resolv.conf
  • Misconfigured of /etc/nsswitch.conf

And probably others, but the first two are the most typical.

  • What’s the nameserver in your network? Find out its name and IP address.
  • Can you ping it by IP address? If you cannot then it’s down.
  • Is the nameserver correct in /etc/resolv.conf? If not then you need to add a line for it, for example: nameserver THE_IP
  • Is the nameserver dynamically set by DHCP in your network? If yes then you shouldn’t mess with /etc/resolv.conf, it should be all automatic, and it looks like something’s wrong at your provider’s end.

Not being able to ping a certain host, does not mean, in any way, that it’s not abailable. It‘s perfectly normal for many websites to be unpingable. It has nothing to do with IPv4, IPv6, DNS or anything like that. The simple answer is that many (but not all) webservers are behind firewalls that drop ICMP ECHO (that‘s what a ping is actually called in professional jargon), while letting HTTP, HTTPS etc. through. You do that to ensure that only the services you want to offer are reachable, but it is more complicated to verify there is a server running or use ICMP for attacks.

Let me try to explain it in a (quite simplified) way: ICMP (Internet Control Message Protocol) is a low level part of TCP/IP, but is generally handled like a stand alone protocol. It is not used to actually tranfer any data, like the transport protocols TCP and UDP do, instead it is used for low level connection relevant stuff inside networks, like advertise routers, echo/ping hosts, initiate DNS requests, traceroute etc.. As it works on a relativly low layer, it can also be used for quite a range of attacks like for example DDOS or even the simple ping of death, which was a quite easy way to down a web server in the early 2000. For that reason ICMP is often completely blocked by firewalls on the service providers side, and that‘s why you can not ping many webservers over the internet, while you can still use their offered services (http(s), ssh, smtp etc.), which are handled by the transport protocols TCP & UDP.

IPv6 uses a similar protocol for that stuff, called ICMPv6. As it is possible to block one in a firewall, while letting the other one pass, it can happen that a distinct server may be pingable via IPv6 but not via IPv4 ICMP echo. The only reason for that happening is an indecisive firewall administrator or a simple oversight.

References