iptables:share_an_ip_address_between_clients
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
iptables:share_an_ip_address_between_clients [2016/07/07 15:31] – created peter | iptables:share_an_ip_address_between_clients [2019/11/29 17:45] (current) – removed peter | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== IPTables - Share an IP address between clients ====== | ||
- | |||
- | To share a public IP address between two or more clients using iptables. | ||
- | |||
- | ===== Scenario ===== | ||
- | |||
- | Suppose that you have three machines that need access to the public Internet, but only one public IP address. | ||
- | |||
- | ===== Prerequisities ===== | ||
- | |||
- | These instructions assume that: | ||
- | |||
- | * you have a working installation of iptables and some means of persisting the ruleset; | ||
- | * you have enabled forwarding of IPv4 network packets. [todo] | ||
- | |||
- | |||
- | ===== Method ===== | ||
- | |||
- | For outbound traffic to the public Internet there are two things which iptables must do: | ||
- | |||
- | * Ensure that the source address is 203.0.113.1 (the external address of the router). | ||
- | * Ensure that the source port number is not already being used by another connection. | ||
- | |||
- | The SNAT target performs both of these tasks. | ||
- | |||
- | <code bash> | ||
- | iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to 203.0.113.1 | ||
- | </ | ||
- | |||
- | Only the first packet of a connection traverses the POSTROUTING table: subsequent packets are automatically redirected. | ||
- | |||
- | You should not use the SNAT target if you have a dynamic IP address. | ||
- | |||
- | |||
- | ===== Testing ===== | ||
- | |||
- | Testing must be done from a machine on the internal side of the router, which in this case is the local area network. | ||
- | |||
- | * Use a numeric IP address as opposed to a domain name, to avoid any dependence on the DNS. | ||
- | * If the test fails when executed on the client then check that it succeeds when executed on the router. | ||
- | |||
- | |||
- | ===== Troubleshooting ===== | ||
- | |||
- | Use **tcpdump** or a similar tool to answer the following questions, stopping at the first one for which the answer is no: | ||
- | |||
- | - Does the outbound connection request reach the router? | ||
- | - Does the router forward the request on to the external network? | ||
- | - When the request leaves the router does it have an unchanged destination address, and a source address equal to the external address of the | ||
- | - Does the response reach the router? | ||
- | - Does the router forward the response on to the internal network? | ||
- | - When the response leaves the router does it have an unchanged source address, and a destination address equal to that of the test machine? | ||
- | - Does the response reach the test machine? | ||
- | |||
- | A failure at step 1, 4 or 7 indicates an issue that is unconnected with iptables or NAT, and which will need to be addressed before you can test further. | ||
- | |||
- | A failure at step 2 could indicate that: | ||
- | |||
- | * forwarding has not been enabled, or | ||
- | * the traffic is not being routed to the correct interface, or | ||
- | * the traffic is being filtered. | ||
- | |||
- | A failure at step 3 could indicate that: | ||
- | |||
- | * the SNAT rule is not being invoked, or | ||
- | * the SNAT target address is wrong, or | ||
- | * the traffic is being NATted twice (for example by a second iptables rule or by iproute2). | ||
- | |||
- | A failure at step 5 could indicate that: | ||
- | |||
- | * the traffic is not being routed to the correct interface, or | ||
- | * the traffic is being filtered, or | ||
- | * there is a serious problem with connection tracking. | ||
- | |||
- | Finally, a failure at step 6 could indicate that: | ||
- | |||
- | * the traffic is being NATted twice. | ||
- | |||
- | Further information about how to investigate these issues can be found in the troubleshooting guides for iptables and routing. | ||
- | |||
- | |||
- | ===== Variations ===== | ||
- | |||
- | ==== SNAT with a dynamic IP address ==== | ||
- | |||
- | **iptables** provides an alternative to the SNAT target called MASQUERADE that is specifically intended for use with dynamic IP addresses. | ||
- | |||
- | * It automatically tracks the address of the interface, therefore there is no need to update the rule when the address changes. | ||
- | * Connections are forgotten whenever the interface goes down. This is the appropriate behaviour because connections established before an address change are not usable afterwards. | ||
- | * | ||
- | If in the scenario above the public IP address had been assigned dynamically then an appropriate rule would be: | ||
- | |||
- | <code bash> | ||
- | iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE | ||
- | </ | ||
- | |||
- | |||
- | ==== Traffic selection using IP addresses ==== | ||
- | |||
- | The recommendation above was to make the SNAT rule specific to the external interface of the router. | ||
- | |||
- | * the interface name may be more likely to change than the IP address, or | ||
- | * the ruleset may already be dependent on the IP address, but not yet on the interface name. | ||
- | |||
- | There will usually be at least two address ranges that need to be excluded, therefore this cannot be done with a single rule. A solution that scales to any number of ranges is to remove them from the chain using the ACCEPT target: | ||
- | |||
- | <code bash> | ||
- | iptables -t nat -A POSTROUTING -d 127.0.0.0/8 -j ACCEPT | ||
- | iptables -t nat -A POSTROUTING -d 192.168.0.0/ | ||
- | iptables -t nat -A POSTROUTING -j SNAT --to 203.0.113.1 | ||
- | </ | ||
- | |||
iptables/share_an_ip_address_between_clients.1467905464.txt.gz · Last modified: 2020/07/15 09:30 (external edit)