Skip to content

Commit

Permalink
Added some clarifications to scenario 3
Browse files Browse the repository at this point in the history
added information about iproute 2
  • Loading branch information
ftasnetamot committed Aug 5, 2024
1 parent 316e9a1 commit 910f09e
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 3 deletions.
4 changes: 3 additions & 1 deletion doc/scenarios-for-simple-transparent-proxy.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
![Simple Transparent Proxy Examples](./sslh-examples-v3.png)

## Introduction ##
The first example is the configuration, which was described in the previousd document. I omitted the loopback interface "lo" in those diagrams, trying not no overload the picture.
The first example is the configuration, which was described in the previous document. I omitted the loopback interface "lo" in those diagrams, trying not no overload the picture.
The connections have two different endings, showing the direction of the opening connection (SYN flag) and the answer connection (SYN-ACK flags). This is important, as the traffic in the transparent proxy setup flows somewhat unexpected.

## Example 1 ##
Expand Down Expand Up @@ -41,6 +41,8 @@ ip route add default via SERVER1_ETH1_IP dev eth0 table sslh_routeback
```
This is setting up a default route for all traffic, originating from the ip address sshd (or any other service) is using, back to the host, hosting sslh. On that host, those packets will be deflected again with the same rule from scenario 2.

Be aware, that scenario 3 can look very different and the picture above shows only one of those setups. Each configuration, where packets from the target system can find their way back, without beeing forcibly routed through the sslh hosting system, belongs into this category. This are e.g. virtual machines or containers, having interfaces in the same network, like the sslh hosting system. Even, when they look in some drawings embedded in their host, as soon, as they have network interfaces, allowing a direct connection to the client, it is scenario 3!

## Modifications ##
Now you can think about many modifications, but the tools will be the same, for all other thinkable scenarios. You must always make sure, that packets from foreign hosts, will find their way back to the sslh host. So if the chain consists of three or four servers, all need the deflection rules.

Expand Down
6 changes: 4 additions & 2 deletions doc/simple_transparent_proxy.md
Original file line number Diff line number Diff line change
Expand Up @@ -68,9 +68,11 @@ To do so go to _**/etc/iproute2/rt_tables**_ and add a line
```
111 sslh
```
With newer versions of iproute2 the /etc/iproute2 directory with the embedded templates got no longer installed. The cause maybe, that the example names, which were not used in any configuration, generated confusion. However, once you need those files, generate them and they will be honoured. You still can use just numbers for your routing table. But doing this, and having more than one routing table, you need a list, which numer belongs to which configuration.
And seeing in the output from `ip route list table all ` the tables names instead just numbers is worth creating the file.

### Dummy Interface ###
Now we configure our dedicatet interface.
Now we configure our dedicated interface.
In the file _**/etc/network/interfaces**_, we place this entry:
```
auto dummy0
Expand All @@ -91,7 +93,7 @@ If you are updating a older current configuration, make sure, that you have no l
sysctl net.ipv4.conf.default.route_localnet
sysctl net.ipv4.conf.all.route_localnet
```
should both report "0"!
should both report "0"!


### Explanation Of The Routing Rules ###
Expand Down

0 comments on commit 910f09e

Please sign in to comment.