Difference between revisions of "OPS335 Lab 2b"

From CDOT Wiki
Jump to: navigation, search
Line 15: Line 15:
  
  
= iptables troubleshooting procedure =
+
==INVESTIGATION 1: IPTABLES TROUBLESHOOTING CHECKLIST==
  
 
By now you've probably figured out that a simple mistake in your iptables rules can have very serious and unexpected consequences for not just your services but any network connectivity. There's a process you can follow to figure out what's wrong.
 
By now you've probably figured out that a simple mistake in your iptables rules can have very serious and unexpected consequences for not just your services but any network connectivity. There's a process you can follow to figure out what's wrong.

Revision as of 09:00, 29 January 2016

ADDITIONAL IPTABLES TROUBLESHOOTING

Purpose

This lab will provide more hands-on experience with troubleshooting iptables issues.

IPTABLES and Routing Troubleshooting Resources

Some articles that you can use as a reference if you are still experiencing problems with iptables:


INVESTIGATION 1: IPTABLES TROUBLESHOOTING CHECKLIST

By now you've probably figured out that a simple mistake in your iptables rules can have very serious and unexpected consequences for not just your services but any network connectivity. There's a process you can follow to figure out what's wrong.

  1. First figure out if you network is set up correctly. You can use the steps in lab 1 as a guide, but keep in mind the firewall may be blocking pings and DNS requests.
  2. See if the service you're trying to connect to is actually running. You should learn to read the output of netstat -atnp and netstat -aunp to complement the systemctl status command.
  3. If you have no idea what's going on and need to confirm that you're still sane - clear all the iptables rules and check your configuration then. Keep in mind that the iptables -F command will delete all your rules but will not set the deafult policies to ACCEPT. This will tell you for sure whether your problem was (or was not) caused by iptables.
    • If you do this - have a ready way to restore the rules you just deleted. Restarting the iptables service is usually a good start and a script to add your custom rules is a reasonable next step.
  4. Follow a packet's path as you understand it should follow. Keep in mind the diagram from the lecture last week. What chain applies first on which machine? What's the first rule that matches the packet? What happens if no rules match the packet?
    • Don't forget that even if you're tracing the path of outgoing traffic - the INPUT chain on your mahchine still applies (for the response that comes back to your request).
  5. At this point you should be able to understand any iptables rules you'll see in this course, including the default ones in CentOS. If you see a rule you don't understand - you can delete it and see what happens. But if you do that - spend some time figuring out what that rule did and why you needed to delete it. It was likely there for a good reason.

Practice script

Download and run this script: http://scs.senecacollege.ca/~andrew.smith/ops335/labcheck_network_backup.sh

It will print out a menu of exercises. You can pick any of them in any order. The script will first reset the firewall settings to CentOS defaults and then make some modifications from those defaults.

Don't cheat. The point of the exercises is for you to find the problem using regular troubleshooting tools, not to reverse-engineer the lab.

Finish the exercises, and record any information you feel you'll need to remember to solve problems like this in the future (e.g. in a practical test).

COMPLETING THE LAB

Students should be prepared with all required commands (system information) displayed in a terminal (or multiple terminals) prior to calling the instructor for signoff.

Arrange evidence (command output) for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:

x.


EXPLORATION QUESTIONS

  1. x