fault_tolerant_router 1.0.0 → 1.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +78 -51
- data/fault_tolerant_router.gemspec +1 -1
- data/lib/fault_tolerant_router/generate_config.rb +20 -9
- data/lib/fault_tolerant_router/generate_iptables.rb +6 -6
- data/lib/fault_tolerant_router/monitor.rb +3 -0
- data/lib/fault_tolerant_router/version.rb +1 -1
- metadata +12 -12
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 2c619776dd495528564bc6177a684c7ab5f1da84
|
|
4
|
+
data.tar.gz: 6b0434ab1d89c616f0e63e22600ffcb6c6f818cd
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 102eb31be1f36deb2a01c195280aebb8d13b371c24c9e538845604be7dc310b54772926abe3c0f2e029983c1bdbd09a383157dbfaf7fcf59c9374d321d73b499
|
|
7
|
+
data.tar.gz: 713419088384c7486c4994cfb21afa6272a110258cf067cb5ec9d7c441017cf3d2ccf0f6327d04e2f1eef5d738f0dbeb04137a945db60e070644e82fc8e025b3
|
data/README.md
CHANGED
|
@@ -1,35 +1,56 @@
|
|
|
1
1
|
# Fault Tolerant Router
|
|
2
2
|
|
|
3
|
+
[](http://badge.fury.io/rb/fault_tolerant_router)
|
|
4
|
+
[](https://gemnasium.com/drsound/fault_tolerant_router)
|
|
5
|
+
[](https://codeclimate.com/github/drsound/fault_tolerant_router)
|
|
6
|
+
|
|
7
|
+
[](https://www.gratipay.com/Alessandro%20Zarrilli/ "Donate weekly to this project using Gratipay")
|
|
8
|
+
[](https://flattr.com/submit/auto?user_id=alessandro.zarrilli&url=https%3A%2F%2Fgithub.com%2Fdrsound%2Ffault_tolerant_router&title=Fault%20Tolerant%20Router&tags=github&category=software "Donate monthly to this project using Flattr")
|
|
9
|
+
[](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=96LFVQRFGRPFW&lc=GB&item_name=Alessandro%20Zarrilli&item_number=fault_tolerant_router¤cy_code=EUR&bn=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted "Donate once-off to this project using Paypal")
|
|
10
|
+
[](https://www.coinbase.com/checkouts/c7e9ea74ce43357eeabb0db81e93f303 "Donate once-off to this project using BitCoin")
|
|
11
|
+
|
|
12
|
+
## In brief
|
|
13
|
+
|
|
14
|
+
Do you have multiple internet connections (uplinks) with several providers? Do you want to transparently use all of the available bandwidth? Do you want to remain online even if some of the uplinks goes down? This tool may help you!
|
|
15
|
+
|
|
16
|
+
## A more formal description
|
|
17
|
+
|
|
3
18
|
Fault Tolerant Router is a daemon, running in background on a Linux router or firewall, monitoring the state of multiple internet uplinks/providers and changing the routing accordingly. LAN/DMZ internet traffic (outgoing connections) is load balanced between the uplinks using Linux *multipath routing*. The daemon monitors the state of the uplinks by routinely pinging well known IP addresses (Google public DNS servers, etc.) through each outgoing interface: once an uplink goes down, it is excluded from the *multipath routing*, when it comes back up, it is included again. All of the routing changes are notified to the administrator by email.
|
|
4
19
|
|
|
5
20
|
Fault Tolerant Router is well tested and has been used in production for several years, in several sites.
|
|
6
21
|
|
|
22
|
+
## Alternatives
|
|
23
|
+
|
|
24
|
+
Fault Tolerant Router has been featured on Slashdot, see [article](http://linux.slashdot.org/story/15/03/03/1910206/linux-and-multiple-internet-uplinks-a-new-tool) comments for interesting hints and alternatives.
|
|
25
|
+
|
|
7
26
|
## Interaction between *multipath routing*, *iptables* and *ip policy routing*
|
|
27
|
+
|
|
8
28
|
The system is based on the interaction between Linux *multipath routing*, *iptables* and *ip policy routing*. Outgoing (from LAN/DMZ to WAN) and incoming (from WAN to LAN/DMZ) connections have a different behaviour:
|
|
9
29
|
* **Outgoing connections (from LAN/DMZ to WAN)**:
|
|
10
30
|
* **New connections**:
|
|
11
|
-
The outgoing interface (uplink) is decided by the Linux *multipath routing*, in a round-robin fashion. Then, just before the packet leaves the router (in the *iptables* POSTROUTING chain), *iptables* marks the connection with the outgoing interface id, so that all subsequent connection packets will be sent through the same interface.
|
|
12
|
-
NB: all the packets of the same connection should be originating from the same IP address, otherwise the server you are connecting to would refuse them
|
|
31
|
+
The outgoing interface (uplink) is decided by the Linux *multipath routing*, in a round-robin fashion. Then, just before the packet leaves the router (in the *iptables* POSTROUTING chain), *iptables* marks the connection with the outgoing interface id, so that all subsequent connection packets will be sent through the same interface.
|
|
32
|
+
NB: all the packets of the same connection should be originating from the same IP address, otherwise the server you are connecting to would refuse them, unless you are using specific protocols.
|
|
13
33
|
* **Established connections**:
|
|
14
34
|
Before the packet is routed (in the *iptables* PREROUTING chain), *iptables* marks it with the outgoing interface id that was previously assigned to the connection. This way, thanks to *ip policy routing*, the packet will pass through a specific routing table directing it to the connection outgoing interface.
|
|
15
35
|
* **Incoming connections (from WAN to LAN/DMZ)**:
|
|
16
|
-
The incoming interface is obviously decided by the connecting host, connecting to one of the IP addresses assigned to an uplink interface. Just after the packet enters the router (in the *iptables* PREROUTING chain), *iptables* marks the connection with the incoming interface id. Then the packet reaches the LAN or DMZ, a return packet is generated by the receiving host and sent back to the connecting host. Once this return packet hits the router, before it is actually routed (in the *iptables* PREROUTING chain), *iptables* marks it with the outgoing interface id that was previously assigned to that connection. This way, thanks to *ip policy routing*, the return packet will pass through a specific routing table directing it to the connection outgoing interface.
|
|
36
|
+
The incoming interface is obviously decided by the connecting host, connecting to one of the IP addresses assigned to an uplink interface. Just after the packet enters the router (in the *iptables* PREROUTING chain), *iptables* marks the connection with the incoming interface id. Then, when the packet reaches the LAN or DMZ, a return packet is generated by the receiving host and sent back to the connecting host. Once this return packet hits the router, before it is actually routed (in the *iptables* PREROUTING chain), *iptables* marks it with the outgoing interface id that was previously assigned to that connection. This way, thanks to *ip policy routing*, the return packet will pass through a specific routing table directing it to the connection outgoing interface.
|
|
17
37
|
|
|
18
38
|
## The uplink monitor daemon
|
|
19
39
|
|
|
20
|
-
The daemon monitors the state of the uplinks by pinging well known IP addresses through each uplink: if enough pings are successful the uplink is considered up, if not it's considered down. If an uplink state change is detected, the default *multipath routing* table (used for LAN/DMZ to WAN new connections) is changed accordingly and the administrator is notified by email.
|
|
40
|
+
The daemon monitors the state of the uplinks by routinely pinging well known IP addresses through each uplink: if enough pings are successful the uplink is considered up, if not it's considered down. If an uplink state change is detected, the default *multipath routing* table (used for LAN/DMZ to WAN new connections) is changed accordingly and the administrator is notified by email.
|
|
21
41
|
|
|
22
|
-
The IP addresses to ping and the number of required successful pings
|
|
23
|
-
* Some ping packets can randomly get lost along the way
|
|
24
|
-
* Some of the hosts you are pinging (*tests/ips* configuration parameter) may be temporarily down.
|
|
25
|
-
* It's better not to ping too near hosts (for example your provider routers), because your provider could be temporarily disconnected from the rest of the internet (it happened...), so
|
|
26
|
-
* Sometimes an uplink can be not completely up or
|
|
42
|
+
The IP addresses to ping and the number of required successful pings are configurable. Here are some things to consider in order not to get false positives or negatives:
|
|
43
|
+
* Some ping packets can randomly get lost along the way: don't require 100% of the pings to be successful!
|
|
44
|
+
* Some of the hosts you are pinging (see *tests/ips* configuration parameter) may be temporarily down.
|
|
45
|
+
* It's better not to ping too near hosts (for example your provider routers), because your provider could be temporarily disconnected from the rest of the internet (it happened...), so the uplink would result as up while it's actually unusable.
|
|
46
|
+
* Sometimes an uplink can be not completely up or down, it can be just "disturbed", losing a high percentage of packets and being almost unusable: it's better to consider such uplink as down, so don't require too few successful pings, otherwise it may be considered up, because a few pings may pass through a "disturbed" link.
|
|
27
47
|
|
|
28
|
-
The order of IP addresses in *tests/ips* configuration parameter is not important, because the list is shuffled before every uplink check.
|
|
48
|
+
The order of IP addresses listed in *tests/ips* configuration parameter is not important, because the list is shuffled before every uplink check.
|
|
29
49
|
|
|
30
50
|
If no uplink is up, all of them are added to the default *multipath routing* table, to get some bandwidth as soon as one uplink comes back up.
|
|
31
51
|
|
|
32
52
|
## Requirements
|
|
53
|
+
|
|
33
54
|
* [Ruby](https://www.ruby-lang.org)
|
|
34
55
|
* A Linux kernel with the following compiled in options (they are standard in mainstream Linux distributions):
|
|
35
56
|
* CONFIG_IP_ADVANCED_ROUTER
|
|
@@ -37,10 +58,14 @@ If no uplink is up, all of them are added to the default *multipath routing* tab
|
|
|
37
58
|
* CONFIG_IP_ROUTE_MULTIPATH
|
|
38
59
|
|
|
39
60
|
## Installation
|
|
61
|
+
|
|
40
62
|
`$ gem install fault_tolerant_router`
|
|
41
63
|
|
|
42
64
|
## Usage
|
|
43
|
-
|
|
65
|
+
|
|
66
|
+
Fault Tolerant Router should be run **as root**, or as an high privileges user, able to modify routing, etc.
|
|
67
|
+
|
|
68
|
+
1. Configure your router interfaces as usual, with every uplink connected to it's own physical interface. An interface may have more than one IP address if needed (from the same uplink of course). **Don't** set any default route.
|
|
44
69
|
2. Save an example configuration file in /etc/fault_tolerant_router.conf (use the `--config` option to set another location):
|
|
45
70
|
`$ fault_tolerant_router generate_config`
|
|
46
71
|
3. Edit /etc/fault_tolerant_router.conf
|
|
@@ -57,40 +82,42 @@ If you want a quick and dirty way to run the program in background, just add an
|
|
|
57
82
|
`$ fault_tolerant_router monitor &`
|
|
58
83
|
|
|
59
84
|
## Configuration file
|
|
85
|
+
|
|
60
86
|
The fault_tolerant_router.conf configuration file is in [YAML](http://en.wikipedia.org/wiki/YAML) format. Here is the explanation of the options:
|
|
61
|
-
* **uplinks**:
|
|
62
|
-
* **interface**:
|
|
63
|
-
* **ip**:
|
|
64
|
-
* **gateway**:
|
|
65
|
-
* **description**: used in
|
|
66
|
-
* **weight**:
|
|
67
|
-
* **default_route**:
|
|
68
|
-
* Want to reserve an uplink for incoming connections only, excluding it from outgoing LAN internet traffic. Tipically you may want this because you have a mail server, web server, etc. listening on
|
|
69
|
-
* Temporarily force all of the outgoing LAN internet traffic to pass through the other uplinks, to stress test
|
|
70
|
-
* Temporarily exclude
|
|
87
|
+
* **uplinks**: Array of uplinks. The example configuration has 3 uplinks, but you can have from 2 to as many as you wish.
|
|
88
|
+
* **interface**: The network interface where the uplink is connected. Until today Fault Tolerant Router has always been used with each uplink on it's own physical interface, never tried it with VLAN interfaces (it's in the to do list).
|
|
89
|
+
* **ip**: Primary IP address of the network interface. You can have more than one IP address assigned to the interface, just specify here the primary one that will be used as standard SNAT source.
|
|
90
|
+
* **gateway**: The uplink gateway, usually the provider's router IP address.
|
|
91
|
+
* **description**: Uplink name, used in notifications.
|
|
92
|
+
* **weight**: Optional parameter, it's the preference to assign to this uplink when choosing one for a new outgoing connection. Use when you have uplinks with different bandwidths. See http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH05.web.html
|
|
93
|
+
* **default_route**: Optional parameter, default value is *true*. If set to *false* the uplink is excluded from the *multipath routing*, i.e. the uplink will never be selected when choosing one for a new outgoing connection. There's an exception to this if some kind of outgoing connection is forced to pass through this uplink, see [Iptables rules](#iptables-rules) section. Note this parameter only affects outgoing connections, even if set to *false* incoming connections are still possible. Use cases to set it to *false*:
|
|
94
|
+
* Want to reserve an uplink for incoming connections only, excluding it from outgoing LAN internet traffic. Tipically you may want this because you have a mail server, web server, VPN server, etc. listening on an uplink.
|
|
95
|
+
* Temporarily force all of the outgoing LAN internet traffic to pass through the other uplinks, to stress test them and determine their bandwidth.
|
|
96
|
+
* Temporarily exclude an uplink to reconfigure it, for example because of and internet provider change.
|
|
71
97
|
* **downlinks**
|
|
72
98
|
* **lan**: LAN interface
|
|
73
99
|
* **dmz**: DMZ interface, leave blank if you have no DMZ
|
|
74
100
|
* **tests**
|
|
75
|
-
* **ips**:
|
|
76
|
-
* **required_successful**:
|
|
77
|
-
* **ping_retries**:
|
|
78
|
-
* **interval**:
|
|
101
|
+
* **ips**: An array of IP addresses to ping to verify the uplinks state. You can add as many as you wish. Predefined ones are Google DNS, OpenDNS DNS, other public DNS. Every time an uplink is tested the IP addresses are shuffled, so listing order is not important.
|
|
102
|
+
* **required_successful**: Number of successfully pinged IP addresses to consider an uplink to be functional
|
|
103
|
+
* **ping_retries**: Number of ping retries before giving up on an IP
|
|
104
|
+
* **interval**: Seconds between a check of the uplinks and the next one
|
|
79
105
|
* **log**
|
|
80
|
-
* **file**:
|
|
81
|
-
* **max_size**:
|
|
82
|
-
* **old_files**:
|
|
106
|
+
* **file**: Log file path
|
|
107
|
+
* **max_size**: Maximum log file size (in bytes). Once reached this size, the log file will be rotated.
|
|
108
|
+
* **old_files**: Number of old rotated files to keep
|
|
83
109
|
* **email**
|
|
84
|
-
* **send**:
|
|
85
|
-
* **sender**:
|
|
86
|
-
* **recipients**:
|
|
87
|
-
* **smtp_parameters**:
|
|
88
|
-
* **base_table**: just need to change if you are already using [multiple routing tables](http://lartc.org/howto/lartc.rpdb.html), to avoid overlapping
|
|
89
|
-
* **base_priority**:
|
|
90
|
-
* **base_fwmark**:
|
|
110
|
+
* **send**: Set to *true* or *false* to enable or disable email notification
|
|
111
|
+
* **sender**: Email sender
|
|
112
|
+
* **recipients**: An array of email recipients
|
|
113
|
+
* **smtp_parameters**: See http://ruby-doc.org/stdlib-2.2.0/libdoc/net/smtp/rdoc/Net/SMTP.html
|
|
114
|
+
* **base_table**: Base IP route table number, just need to change if you are already using [multiple routing tables](http://lartc.org/howto/lartc.rpdb.html), to avoid overlapping.
|
|
115
|
+
* **base_priority**: Just need to change if you are already using [ip policy routing](http://lartc.org/howto/lartc.rpdb.html), to avoid overlapping. Must be higher than 32767 (default priority, see `ip rule` command output).
|
|
116
|
+
* **base_fwmark**: Just need to change if you are already using packet marking, to avoid overlapping.
|
|
91
117
|
|
|
92
118
|
## *Iptables* rules
|
|
93
|
-
|
|
119
|
+
|
|
120
|
+
*Iptables* rules are generated with the command:
|
|
94
121
|
`$ fault_tolerant_router generate_iptables`
|
|
95
122
|
Rules are in [iptables-save](http://manned.org/iptables-save.8) format, you should integrate them with your existing ones.
|
|
96
123
|
Documentation is included as comments in the output, here is a dump using the standard example configuration:
|
|
@@ -116,11 +143,11 @@ Documentation is included as comments in the output, here is a dump using the st
|
|
|
116
143
|
# --sport, etc.
|
|
117
144
|
|
|
118
145
|
#Example Provider 1
|
|
119
|
-
#[0:0] -A PREROUTING -i eth0 -m
|
|
146
|
+
#[0:0] -A PREROUTING -i eth0 -m conntrack --ctstate NEW -p tcp --dport XXX -j CONNMARK --set-mark 1
|
|
120
147
|
#Example Provider 2
|
|
121
|
-
#[0:0] -A PREROUTING -i eth0 -m
|
|
148
|
+
#[0:0] -A PREROUTING -i eth0 -m conntrack --ctstate NEW -p tcp --dport XXX -j CONNMARK --set-mark 2
|
|
122
149
|
#Example Provider 3
|
|
123
|
-
#[0:0] -A PREROUTING -i eth0 -m
|
|
150
|
+
#[0:0] -A PREROUTING -i eth0 -m conntrack --ctstate NEW -p tcp --dport XXX -j CONNMARK --set-mark 3
|
|
124
151
|
|
|
125
152
|
#Mark packets with the outgoing interface:
|
|
126
153
|
#
|
|
@@ -138,21 +165,21 @@ Documentation is included as comments in the output, here is a dump using the st
|
|
|
138
165
|
#New inbound connections: mark the connection with the incoming interface.
|
|
139
166
|
|
|
140
167
|
#Example Provider 1
|
|
141
|
-
[0:0] -A PREROUTING -i eth1 -m
|
|
168
|
+
[0:0] -A PREROUTING -i eth1 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1
|
|
142
169
|
#Example Provider 2
|
|
143
|
-
[0:0] -A PREROUTING -i eth2 -m
|
|
170
|
+
[0:0] -A PREROUTING -i eth2 -m conntrack --ctstate NEW -j CONNMARK --set-mark 2
|
|
144
171
|
#Example Provider 3
|
|
145
|
-
[0:0] -A PREROUTING -i eth3 -m
|
|
172
|
+
[0:0] -A PREROUTING -i eth3 -m conntrack --ctstate NEW -j CONNMARK --set-mark 3
|
|
146
173
|
|
|
147
174
|
#New outbound connections: mark the connection with the outgoing interface
|
|
148
175
|
#(chosen by the multipath routing).
|
|
149
176
|
|
|
150
177
|
#Example Provider 1
|
|
151
|
-
[0:0] -A POSTROUTING -o eth1 -m
|
|
178
|
+
[0:0] -A POSTROUTING -o eth1 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1
|
|
152
179
|
#Example Provider 2
|
|
153
|
-
[0:0] -A POSTROUTING -o eth2 -m
|
|
180
|
+
[0:0] -A POSTROUTING -o eth2 -m conntrack --ctstate NEW -j CONNMARK --set-mark 2
|
|
154
181
|
#Example Provider 3
|
|
155
|
-
[0:0] -A POSTROUTING -o eth3 -m
|
|
182
|
+
[0:0] -A POSTROUTING -o eth3 -m conntrack --ctstate NEW -j CONNMARK --set-mark 3
|
|
156
183
|
|
|
157
184
|
COMMIT
|
|
158
185
|
|
|
@@ -218,9 +245,9 @@ COMMIT
|
|
|
218
245
|
#This is just a very basic example, add your own rules for the INPUT chain.
|
|
219
246
|
|
|
220
247
|
[0:0] -A INPUT -i lo -j ACCEPT
|
|
221
|
-
[0:0] -A INPUT -m
|
|
248
|
+
[0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
|
|
222
249
|
|
|
223
|
-
[0:0] -A FORWARD -m
|
|
250
|
+
[0:0] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
|
|
224
251
|
|
|
225
252
|
[0:0] -A FORWARD -i eth0 -o eth1 -j LAN_WAN
|
|
226
253
|
[0:0] -A FORWARD -i eth0 -o eth2 -j LAN_WAN
|
|
@@ -238,14 +265,14 @@ COMMIT
|
|
|
238
265
|
```
|
|
239
266
|
|
|
240
267
|
## To do
|
|
241
|
-
|
|
242
|
-
|
|
243
|
-
* i18n
|
|
244
|
-
* If no uplinks are up, set tests/interval configuration option to 0, to get bandwidth as soon as an uplink comes back up
|
|
268
|
+
|
|
269
|
+
See [issues](https://github.com/drsound/fault_tolerant_router/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement) tagged as *enhancement* on GitHub.
|
|
245
270
|
|
|
246
271
|
## License
|
|
272
|
+
|
|
247
273
|
GNU General Public License v2.0, see LICENSE file
|
|
248
274
|
|
|
249
275
|
## Author
|
|
276
|
+
|
|
250
277
|
Alessandro Zarrilli (Poggibonsi - Italy)
|
|
251
278
|
alessandro@zarrilli.net
|
|
@@ -9,7 +9,7 @@ Gem::Specification.new do |spec|
|
|
|
9
9
|
spec.authors = ['Alessandro Zarrilli']
|
|
10
10
|
spec.email = ['alessandro@zarrilli.net']
|
|
11
11
|
spec.summary = %q{Multiple uplinks Linux routing supervising daemon}
|
|
12
|
-
spec.description = %q{
|
|
12
|
+
spec.description = %q{A daemon, running in background on a Linux router or firewall, monitoring the state of multiple internet uplinks/providers and changing the routing accordingly. LAN/DMZ internet traffic (outgoing connections) is load balanced between the uplinks using Linux multipath routing. The daemon monitors the state of the uplinks by routinely pinging well known IP addresses (Google public DNS servers, etc.) through each outgoing interface: once an uplink goes down, it is excluded from the multipath routing, when it comes back up, it is included again. All of the routing changes are notified to the administrator by email. Fault Tolerant Router is well tested and has been used in production for several years, in several sites. See https://github.com/drsound/fault_tolerant_router for full documentation.}
|
|
13
13
|
spec.homepage = 'https://github.com/drsound/fault_tolerant_router'
|
|
14
14
|
spec.license = 'GPL-2'
|
|
15
15
|
|
|
@@ -6,6 +6,9 @@ def generate_config(file_path)
|
|
|
6
6
|
begin
|
|
7
7
|
open(file_path, 'w') do |file|
|
|
8
8
|
file.puts <<END
|
|
9
|
+
#see https://github.com/drsound/fault_tolerant_router for a complete parameter
|
|
10
|
+
#description
|
|
11
|
+
|
|
9
12
|
#add as many uplinks as needed
|
|
10
13
|
uplinks:
|
|
11
14
|
- interface: eth1
|
|
@@ -39,8 +42,10 @@ downlinks:
|
|
|
39
42
|
dmz:
|
|
40
43
|
|
|
41
44
|
tests:
|
|
42
|
-
#
|
|
43
|
-
#
|
|
45
|
+
#an array of IP addresses to ping to verify the uplinks state. You can add as
|
|
46
|
+
#many as you wish. Predefined ones are Google DNS, OpenDNS DNS, other public
|
|
47
|
+
#DNS. Every time an uplink is tested the IP addresses are shuffled, so listing
|
|
48
|
+
#order is not important.
|
|
44
49
|
ips:
|
|
45
50
|
- 8.8.8.8
|
|
46
51
|
- 8.8.4.4
|
|
@@ -48,9 +53,10 @@ tests:
|
|
|
48
53
|
- 208.67.220.220
|
|
49
54
|
- 4.2.2.2
|
|
50
55
|
- 4.2.2.3
|
|
51
|
-
#number of
|
|
56
|
+
#number of successfully pinged IP addresses to consider an uplink to be
|
|
57
|
+
#functional
|
|
52
58
|
required_successful: 4
|
|
53
|
-
#ping retries
|
|
59
|
+
#number of ping retries before giving up on an IP
|
|
54
60
|
ping_retries: 1
|
|
55
61
|
#seconds between a check of the uplinks and the next one
|
|
56
62
|
interval: 60
|
|
@@ -58,9 +64,10 @@ tests:
|
|
|
58
64
|
log:
|
|
59
65
|
#file: "/var/log/fault_tolerant_router.log"
|
|
60
66
|
file: "/tmp/fault_tolerant_router.log"
|
|
61
|
-
#
|
|
67
|
+
#maximum log file size (in bytes). Once reached this size, the log file will
|
|
68
|
+
#be rotated.
|
|
62
69
|
max_size: 1024000
|
|
63
|
-
#number of old
|
|
70
|
+
#number of old rotated files to keep
|
|
64
71
|
old_files: 10
|
|
65
72
|
|
|
66
73
|
email:
|
|
@@ -80,13 +87,17 @@ email:
|
|
|
80
87
|
user_name: user@gmail.com
|
|
81
88
|
password: secret-password
|
|
82
89
|
|
|
83
|
-
#base
|
|
90
|
+
#base IP route table number, just need to change if you are already using
|
|
91
|
+
#multiple routing tables
|
|
84
92
|
base_table: 1
|
|
85
93
|
|
|
86
|
-
#
|
|
94
|
+
#just need to change if you are already using ip policy routing, to avoid
|
|
95
|
+
#overlapping, must be higher than 32767 (default priority, see output of
|
|
96
|
+
#"ip rule" command)
|
|
87
97
|
base_priority: 40000
|
|
88
98
|
|
|
89
|
-
#
|
|
99
|
+
#just need to change if you are already using packet marking, to avoid
|
|
100
|
+
#overlapping
|
|
90
101
|
base_fwmark: 1
|
|
91
102
|
END
|
|
92
103
|
end
|
|
@@ -23,8 +23,8 @@ def generate_iptables
|
|
|
23
23
|
END
|
|
24
24
|
UPLINKS.each_with_index do |uplink, i|
|
|
25
25
|
puts "##{uplink[:description]}"
|
|
26
|
-
puts "#[0:0] -A PREROUTING -i #{LAN_INTERFACE} -m
|
|
27
|
-
puts "#[0:0] -A PREROUTING -i #{DMZ_INTERFACE} -m
|
|
26
|
+
puts "#[0:0] -A PREROUTING -i #{LAN_INTERFACE} -m conntrack --ctstate NEW -p tcp --dport XXX -j CONNMARK --set-mark #{BASE_FWMARK + i}"
|
|
27
|
+
puts "#[0:0] -A PREROUTING -i #{DMZ_INTERFACE} -m conntrack --ctstate NEW -p tcp --dport XXX -j CONNMARK --set-mark #{BASE_FWMARK + i}" if DMZ_INTERFACE
|
|
28
28
|
end
|
|
29
29
|
puts <<END
|
|
30
30
|
|
|
@@ -49,7 +49,7 @@ END
|
|
|
49
49
|
END
|
|
50
50
|
UPLINKS.each_with_index do |uplink, i|
|
|
51
51
|
puts "##{uplink[:description]}"
|
|
52
|
-
puts "[0:0] -A PREROUTING -i #{uplink[:interface]} -m
|
|
52
|
+
puts "[0:0] -A PREROUTING -i #{uplink[:interface]} -m conntrack --ctstate NEW -j CONNMARK --set-mark #{BASE_FWMARK + i}"
|
|
53
53
|
end
|
|
54
54
|
puts <<END
|
|
55
55
|
|
|
@@ -59,7 +59,7 @@ END
|
|
|
59
59
|
END
|
|
60
60
|
UPLINKS.each_with_index do |uplink, i|
|
|
61
61
|
puts "##{uplink[:description]}"
|
|
62
|
-
puts "[0:0] -A POSTROUTING -o #{uplink[:interface]} -m
|
|
62
|
+
puts "[0:0] -A POSTROUTING -o #{uplink[:interface]} -m conntrack --ctstate NEW -j CONNMARK --set-mark #{BASE_FWMARK + i}"
|
|
63
63
|
end
|
|
64
64
|
puts <<END
|
|
65
65
|
|
|
@@ -135,9 +135,9 @@ END
|
|
|
135
135
|
#This is just a very basic example, add your own rules for the INPUT chain.
|
|
136
136
|
|
|
137
137
|
[0:0] -A INPUT -i lo -j ACCEPT
|
|
138
|
-
[0:0] -A INPUT -m
|
|
138
|
+
[0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
|
|
139
139
|
|
|
140
|
-
[0:0] -A FORWARD -m
|
|
140
|
+
[0:0] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
|
|
141
141
|
|
|
142
142
|
END
|
|
143
143
|
UPLINKS.each do |uplink|
|
|
@@ -62,6 +62,9 @@ def monitor
|
|
|
62
62
|
command "ip route del table #{BASE_TABLE + i} &> /dev/null"
|
|
63
63
|
end
|
|
64
64
|
|
|
65
|
+
#enable IP forwarding
|
|
66
|
+
command 'echo 1 > /proc/sys/net/ipv4/ip_forward'
|
|
67
|
+
|
|
65
68
|
#disable "reverse path filtering" on the uplink interfaces
|
|
66
69
|
command 'echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter'
|
|
67
70
|
UPLINKS.each do |uplink|
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: fault_tolerant_router
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.1
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Alessandro Zarrilli
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2015-
|
|
11
|
+
date: 2015-03-10 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: bundler
|
|
@@ -52,16 +52,16 @@ dependencies:
|
|
|
52
52
|
- - "~>"
|
|
53
53
|
- !ruby/object:Gem::Version
|
|
54
54
|
version: '2.6'
|
|
55
|
-
description: '
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
55
|
+
description: 'A daemon, running in background on a Linux router or firewall, monitoring
|
|
56
|
+
the state of multiple internet uplinks/providers and changing the routing accordingly.
|
|
57
|
+
LAN/DMZ internet traffic (outgoing connections) is load balanced between the uplinks
|
|
58
|
+
using Linux multipath routing. The daemon monitors the state of the uplinks by routinely
|
|
59
|
+
pinging well known IP addresses (Google public DNS servers, etc.) through each outgoing
|
|
60
|
+
interface: once an uplink goes down, it is excluded from the multipath routing,
|
|
61
|
+
when it comes back up, it is included again. All of the routing changes are notified
|
|
62
|
+
to the administrator by email. Fault Tolerant Router is well tested and has been
|
|
63
|
+
used in production for several years, in several sites. See https://github.com/drsound/fault_tolerant_router
|
|
64
|
+
for full documentation.'
|
|
65
65
|
email:
|
|
66
66
|
- alessandro@zarrilli.net
|
|
67
67
|
executables:
|