80 | | ||-A INPUT||says the rule should be appended to Chain INPUT|| |
81 | | ||-s 10.104.100.167||the source of the packet is the machine found at 10.104.100.167|| |
82 | | ||-d 10.104.100.168||means the destination machine is 10.104.100.168|| |
83 | | ||-p tcp||means the rule is concerned with the tcp protocol (so a udp packet coming in on port 8023 wouldn't be addressed by this rule)|| |
84 | | ||-m tcp||this means load the rules that match the listed protocol, in this case tcp. Although this isn't strictly necessary since we've specified the protocol with the -p option, it's considered good form to use it, and our ISP does use it, so we should too.|| |
85 | | ||--dport 8023||This rule concerns itself with packets destined for port 8023.|| |
86 | | ||-j ACCEPT||if a packet matches the rules above, then "jump" to the ACCEPT command, in other words, accept the packet.|| |
| 80 | ||-A INPUT||says the rule should be appended to Chain INPUT|| |
| 81 | ||-s 10.104.100.167||the source of the packet is the machine found at 10.104.100.167|| |
| 82 | ||-d 10.104.100.168||means the destination machine is 10.104.100.168|| |
| 83 | ||-p tcp||means the rule is concerned with the tcp protocol (so a udp packet coming in on port 8023 wouldn't be addressed by this rule)|| |
| 84 | ||-m tcp||this means load the rules that match the listed protocol, in this case tcp. Although this isn't strictly necessary since we've specified the protocol with the -p option, it's considered good form to use it, and our ISP does use it, so we should too.|| |
| 85 | ||--dport 8023||This rule concerns itself with packets destined for port 8023.|| |
| 86 | ||-j ACCEPT||if a packet matches the rules above, then "jump" to the ACCEPT command, in other words, accept the packet.|| |
| 123 | The easiest way to ensure a port is open is to use nmap. |
| 124 | |
| 125 | '''NOTE:''' although nmap is a valid networking diagnotic tool, it's also a very controversial tool. '''PLEASE''' use with discretion! |
| 126 | |
| 127 | You can test the status of a port by running the following command from another machine: |
| 128 | {{{ |
| 129 | sudo nmap 10.0.0.1 -sS -p 5432 |
| 130 | }}} |
| 131 | |
| 132 | The command above tests the 5432 port on computer 10.0.0.1. The return is something like: |
| 133 | {{{ |
| 134 | Interesting ports on 10.0.0.1: |
| 135 | PORT STATE SERVICE |
| 136 | 5432/tcp open postgresql |
| 137 | |
| 138 | Nmap done: 1 IP address (1 host up) scanned in 0.169 seconds |
| 139 | }}} |
| 140 | |
| 141 | The output above lists the port as STATE: open. This means the iptables rules are working properly. If STATE returns "filered" or "closed", the port isn't open and you need to revisit your iptalbe rules. |
| 142 | |
| 143 | '''NOTE:''' if the port returns "open" but you still can't get a connection from the service you want (ie port 5432 is open but you still can't get a connection to postgres from another machine) then be sure to check that another service isn't running on the port: |
| 144 | |
| 145 | {{{ |
| 146 | netstat -an | grep 5432 |
| 147 | }}} |
| 148 | |
| 149 | Things to check in the output include: |
| 150 | || |