In a networking job you'll always get into a situation wherein somebody's going to complain about not being able to browse a site or some specific sites. It could be customers of your company or even users within the organization. What do you do when this happens? typically you would browse them by yourself (hopefully your not behind a proxy), then you find out your are able to browse the site. You ask them what troubleshooting steps has been done; where you able to ping the site? have your tried to do an nslookup? changed dns servers? have you tried browsing by IP address? used a public proxy server? tried changing your IP address, etc etc..but most likely, 99% of the time you'll ask them to perform a traceroute to the website. Generally a traceroute will be your most effective troubleshooting tool in these scenarios. It's like the basic swiss knife of troubleshooting routing issues and the likes. Though i know of a bit better one called 'pathping' (Windows only) but most of the time a traceroute will do the work. You'll see every hop, latency on each hop, and the path towards the destination. Probably the best thing you have to keep in mind in using this is that it's only the forward path to the destination. You don't ever see the reverse path unless you do a trace the other way..from the destination to the source. To make that even more challenging is that reverse paths can vary per hop. Imagine that every router always has their own best way around the Internet, and it is normal that every hop/router on the traceroute will have a different path back to the source of the traceroute, and that you don't see unless there something wrong with the trace like a huge spike on the latency where its not expected to.
As a start, traceroutes have different types. They vary on which type of packet they use. These are the most common ones i know: UDP, TCP and ICMP based traceroutes. UDP is the default for Linux, ICMP is the one that's used in Windows and TCP is a another variant which comes by default in Linux but is available for Windows as well as a free download over the net. Now these variants are pretty straight forward. In Linux, the default traceroute uses UDP packets. Most of the time this is fine however there are times that you will encounter target machines that just don't respond to UDP. Honestly there are a lot of them out there!
$traceroute hostname/IP address
Another variant is the ICMP based traceroute. In windows this is the default however it is more known as 'tracert'. By the name ICMP you would immediately know that it uses PING or echo requests as it goes through each hop along the path. So typically if you can ping it then it would respond, with some rare exceptions ofcourse due to firewalls and security policies put in place by organizations.
in Linux:
$traceroute -I hostname/IP address
in Windows:
C:\>tracert hostname/IP address
So basic stuff isn't it? Yes but the trick is knowing how and when to use them. Now probably the best one that I myself prefer. The TCP traceroute almost always does the job when finding out if you can really reach a site. The problem with ICMP and UDP is that not all routers respond to these type of packets. Specially ICMP since most modems nowadays are distributed with ICMP replies disabled as an anti denial of service mechanism. Some do respond but will drop packets every certain interval to prevent against ping floods. Many of them are just turned off since by just turning it on makes you vulnerable to OS fingerprinting. Each OS vendor has their own little tweak on their TCP/IP stack making them identifiable from each other. Redhat has their own, Windows has their own so you know which is which. Therefore attackers would already have a clue on how to attack. Knowing what type of OS and which version is it then what programs are installed, all these would be very important information for hackers around the net. So watch out for that ICMP unless there's nothing really important on your machine and you don't really care. LOL
A lot of times you will see that traceroutes will stop just right before the target machine. Most people will think - Oops there's a problem, i'm not able to reach the site i'm trying to access. Maybe that's why i can't browse that website.
Trust me this isn't always the case. Most of the time the target machine just doesn't respond to your requests. Since your trying to access a website. . hmmm.
http. .which is TCP port 80, then it would just make sense if you will use TCP packets to probe if the websites http port is accessible.
$tcptraceroute hostname/IP address [80]
Specifying the port is optional. The default is 80 and you may specify other ports e.g. SMTP, FTP, and so on. You'll now then see the target machine respond since you know that it's listening on TCP port 80. Almost every time you'll see a traceroute complete by using this. But there are times that servers/routers are just so secure they just don't respond to anything! even TCP. Maybe due to TCP SYN attacks? who knows. The point is they just stay stealth mode:)
These are the times that you may want to access the server head on. Try telnetting into the server.
$telnet hostname/IP addess 80
Yes trying to get inside the server to make sure you can access it. For secured sites use port 443. Now if it tells you your connected then that's it you proved that you can access the site. But wait. .sometimes there are underlying issues we must not fall for. These are the times that you would like to mimic your browser and send some server requests just to make sure you are indeed able to download the webpages. Why even bother? I was able to access the site via command line.
Since your already in the server why not try to see if you are able to download the page.
$telnet www.somesite.com 80
Connected to www.somesite.com.
HEAD / HTTP/1.0
press Enter/Return twice!
Texts in bold are the ones you will type.
example:
Passing a HEAD command to the server is sending an http request to download a resource (in this case '/') without actually downloading it. HTTP/1.0 is telling the server its an HTTP 1.0 request. Press Enter to end the request then you may type in some optional request headers then press Enter again to end. In our example we didn't so we just press Enter twice.
note: If you get the code "200 OK" that means it's all good! Also notice that the server told us that its using HTTP 1.1, you may also make your request as HTTP1.1 by using 1.1 instead of 1.0. See how much stuff you can get by this? It even tells you what type of web server it's using and what version. ASP.NET and what version, useful stuff for some:)
To actually download the webpage then you issue the GET command.
$telnet www.somesite.com 80
Connected to www.somesite.com.
GET / HTTP/1.0
press Enter/Return twice!
This is like actually doing what your browser is doing on the background when you're browsing a website. You will see the source of the page your trying to download by issuing this command. HTML stuff and javascript are common.
sample output:
All you will be able to catch really is just the end of the page because it just blurts it all out on you until it reaches that closing tag of the web page. But you wouldn't really mind because all that matters for us is to know its working!
Now question is why go all the way in doing this? Like what I said there are times that there are issues we do not see or might overlook. Doing these steps would make our troubleshooting much more concrete and will bring us to more accurate conclusions. What if there was an MTU issue along the path? How do you detect that? You send large pings as you can? Even if you do so on the direct gateway of the user its still not guaranteed he/she will be able to browse with the maximum mtu the end device is allowed to. Nothing beats the view from the source device so its always recommended to trust the tests more on their end rather than the tests you do from the middle of the network.
Now if there are routing issues everything i said in this post will be basically useless. Sometimes the source address can be blocked on the target site but that you will detect if traceroutes and telnet fails.
Surprisingly there is always a huge chance the destinaton hop would not be seen in a traceroute, but hey..as long as you are able to reach the last hop router then you can already guarantee there's no problem on your end. Remember that it's the last hop router's responsibility to route to that destination and that it must be a directly connected interface anyway so you're sure its going to route for that unless it's down. If it's not the last hop router then that's where you investigate for blocking or routing issues.
So then watch out for those browsing issues as they're always gonna be around. Understanding how they work and having the knowledge on how to troubleshoot them if they are not accessible through the browser will make things a lot easier for you:)
As a start, traceroutes have different types. They vary on which type of packet they use. These are the most common ones i know: UDP, TCP and ICMP based traceroutes. UDP is the default for Linux, ICMP is the one that's used in Windows and TCP is a another variant which comes by default in Linux but is available for Windows as well as a free download over the net. Now these variants are pretty straight forward. In Linux, the default traceroute uses UDP packets. Most of the time this is fine however there are times that you will encounter target machines that just don't respond to UDP. Honestly there are a lot of them out there!
$traceroute hostname/IP address
Another variant is the ICMP based traceroute. In windows this is the default however it is more known as 'tracert'. By the name ICMP you would immediately know that it uses PING or echo requests as it goes through each hop along the path. So typically if you can ping it then it would respond, with some rare exceptions ofcourse due to firewalls and security policies put in place by organizations.
in Linux:
$traceroute -I hostname/IP address
in Windows:
C:\>tracert hostname/IP address
So basic stuff isn't it? Yes but the trick is knowing how and when to use them. Now probably the best one that I myself prefer. The TCP traceroute almost always does the job when finding out if you can really reach a site. The problem with ICMP and UDP is that not all routers respond to these type of packets. Specially ICMP since most modems nowadays are distributed with ICMP replies disabled as an anti denial of service mechanism. Some do respond but will drop packets every certain interval to prevent against ping floods. Many of them are just turned off since by just turning it on makes you vulnerable to OS fingerprinting. Each OS vendor has their own little tweak on their TCP/IP stack making them identifiable from each other. Redhat has their own, Windows has their own so you know which is which. Therefore attackers would already have a clue on how to attack. Knowing what type of OS and which version is it then what programs are installed, all these would be very important information for hackers around the net. So watch out for that ICMP unless there's nothing really important on your machine and you don't really care. LOL
A lot of times you will see that traceroutes will stop just right before the target machine. Most people will think - Oops there's a problem, i'm not able to reach the site i'm trying to access. Maybe that's why i can't browse that website.
Trust me this isn't always the case. Most of the time the target machine just doesn't respond to your requests. Since your trying to access a website. . hmmm.
http. .which is TCP port 80, then it would just make sense if you will use TCP packets to probe if the websites http port is accessible.
$tcptraceroute
Specifying the port is optional. The default is 80 and you may specify other ports e.g. SMTP, FTP, and so on. You'll now then see the target machine respond since you know that it's listening on TCP port 80. Almost every time you'll see a traceroute complete by using this. But there are times that servers/routers are just so secure they just don't respond to anything! even TCP. Maybe due to TCP SYN attacks? who knows. The point is they just stay stealth mode:)
These are the times that you may want to access the server head on. Try telnetting into the server.
$telnet hostname/IP addess
Yes trying to get inside the server to make sure you can access it. For secured sites use port 443. Now if it tells you your connected then that's it you proved that you can access the site. But wait. .sometimes there are underlying issues we must not fall for. These are the times that you would like to mimic your browser and send some server requests just to make sure you are indeed able to download the webpages. Why even bother? I was able to access the site via command line.
Since your already in the server why not try to see if you are able to download the page.
$telnet www.somesite.com 80
Connected to www.somesite.com.
HEAD / HTTP/1.0
press Enter/Return twice!
Texts in bold are the ones you will type.
example:
Passing a HEAD command to the server is sending an http request to download a resource (in this case '/') without actually downloading it. HTTP/1.0 is telling the server its an HTTP 1.0 request. Press Enter to end the request then you may type in some optional request headers then press Enter again to end. In our example we didn't so we just press Enter twice.
note: If you get the code "200 OK" that means it's all good! Also notice that the server told us that its using HTTP 1.1, you may also make your request as HTTP1.1 by using 1.1 instead of 1.0. See how much stuff you can get by this? It even tells you what type of web server it's using and what version. ASP.NET and what version, useful stuff for some:)
To actually download the webpage then you issue the GET command.
$telnet www.somesite.com 80
Connected to www.somesite.com.
GET / HTTP/1.0
press Enter/Return twice!
This is like actually doing what your browser is doing on the background when you're browsing a website. You will see the source of the page your trying to download by issuing this command. HTML stuff and javascript are common.
sample output:
All you will be able to catch really is just the end of the page because it just blurts it all out on you until it reaches that closing tag of the web page. But you wouldn't really mind because all that matters for us is to know its working!
Now question is why go all the way in doing this? Like what I said there are times that there are issues we do not see or might overlook. Doing these steps would make our troubleshooting much more concrete and will bring us to more accurate conclusions. What if there was an MTU issue along the path? How do you detect that? You send large pings as you can? Even if you do so on the direct gateway of the user its still not guaranteed he/she will be able to browse with the maximum mtu the end device is allowed to. Nothing beats the view from the source device so its always recommended to trust the tests more on their end rather than the tests you do from the middle of the network.
Now if there are routing issues everything i said in this post will be basically useless. Sometimes the source address can be blocked on the target site but that you will detect if traceroutes and telnet fails.
Surprisingly there is always a huge chance the destinaton hop would not be seen in a traceroute, but hey..as long as you are able to reach the last hop router then you can already guarantee there's no problem on your end. Remember that it's the last hop router's responsibility to route to that destination and that it must be a directly connected interface anyway so you're sure its going to route for that unless it's down. If it's not the last hop router then that's where you investigate for blocking or routing issues.
So then watch out for those browsing issues as they're always gonna be around. Understanding how they work and having the knowledge on how to troubleshoot them if they are not accessible through the browser will make things a lot easier for you:)
No comments:
Post a Comment