From 18a9a882f5474d6defee64b383282b1cb2067b75 Mon Sep 17 00:00:00 2001 From: ftasnetamot Date: Mon, 5 Aug 2024 21:29:37 +0200 Subject: [PATCH] Added some clarifications to scenario 3 added information about iproute 2 --- doc/scenarios-for-simple-transparent-proxy.md | 4 +++- doc/simple_transparent_proxy.md | 6 ++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/doc/scenarios-for-simple-transparent-proxy.md b/doc/scenarios-for-simple-transparent-proxy.md index d8e15dd..59f0394 100644 --- a/doc/scenarios-for-simple-transparent-proxy.md +++ b/doc/scenarios-for-simple-transparent-proxy.md @@ -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 ## @@ -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. diff --git a/doc/simple_transparent_proxy.md b/doc/simple_transparent_proxy.md index 13625ac..27e8e19 100644 --- a/doc/simple_transparent_proxy.md +++ b/doc/simple_transparent_proxy.md @@ -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 @@ -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 ###