WIP: Use postfix options for routing mails through tunnel #45

Draft
esavkin wants to merge 9 commits from enable-mail-proxy-and-tunnel into master
Owner

Once tested, new users can be created to improve security of the ssh tunnel process.

Already tested with VM and simple SMTP server that prints headers and source IP.
Just needs wg-quick genkey and wg-quick pubkey on nixbld side.

Things tested:

  • curl defaults to previous default route
  • curl can choose either tunnel or previous default interface and external services correctly identify the IP address (intl for tunnel)
  • smtp server correctly receives original IP address and replies correctly on both direct and tunneled connection
  • if endpoint is specified to be ipv6 address (i.e. tunnel is over IPv6), the ping is down from 160ms to 133ms
~~Once tested, new users can be created to improve security of the ssh tunnel process.~~ Already tested with VM and simple SMTP server that prints headers and source IP. Just needs `wg-quick genkey` and `wg-quick pubkey` on nixbld side. Things tested: * curl defaults to previous default route * curl can choose either tunnel or previous default interface and external services correctly identify the IP address (intl for tunnel) * smtp server correctly receives original IP address and replies correctly on both direct and tunneled connection * if endpoint is specified to be ipv6 address (i.e. tunnel is over IPv6), the ping is down from 160ms to 133ms
esavkin added 1 commit 2024-08-22 12:26:24 +08:00
56577193f0 Use postfix options for routing mails through ssh tunnel
Signed-off-by: Egor Savkin <es@m-labs.hk>
sb10q reviewed 2024-08-22 13:13:27 +08:00
@ -1179,0 +1193,4 @@
@m-labs.hk :
@m-labs.ph :
@193thz.com :
@malloctech.fr :
Owner

Does postfix require all domains to be listed there, even those without a relay host?

Does postfix require all domains to be listed there, even those without a relay host?
Author
Owner

As in examples at https://www.postfix.org/transport.5.html , a wildcard is probably a better way

As in examples at https://www.postfix.org/transport.5.html , a wildcard is probably a better way
esavkin marked this conversation as resolved
esavkin added 1 commit 2024-08-22 13:21:33 +08:00
esavkin added 1 commit 2024-08-23 17:18:59 +08:00
68d8deed73 Use tsocks to wrap socks and add sock transport type
Signed-off-by: Egor Savkin <es@m-labs.hk>
esavkin added 1 commit 2024-08-26 11:59:28 +08:00
a2d7b847a9 Use proxychains-ng instead of tsocks
Signed-off-by: Egor Savkin <es@m-labs.hk>
esavkin changed title from Use postfix options for routing mails through ssh tunnel to WIP: Use postfix options for routing mails through ssh tunnel 2024-08-28 17:24:12 +08:00
esavkin added 1 commit 2024-08-28 17:25:07 +08:00
684c63bb49 WIP: Use gre/ipsec instead of proxy
Signed-off-by: Egor Savkin <es@m-labs.hk>
sb10q reviewed 2024-08-28 21:28:26 +08:00
@ -219,0 +235,4 @@
address = "0.0.0.0";
prefixLength = 0;
via = "5.78.86.156";
options.table = "2";
Owner

Already in use, please pay attention.

Already in use, please pay attention.
sb10q reviewed 2024-08-28 21:28:57 +08:00
@ -1190,0 +1245,4 @@
services.postfix = {
config = {
sender_dependent_relayhost_maps = "hash:/etc/postfix/sender_relay";
postscreen_upstream_proxy_protocol = "haproxy";
Owner

What?

What?
esavkin marked this conversation as resolved
sb10q reviewed 2024-08-29 11:04:53 +08:00
@ -219,0 +223,4 @@
ttl = 255;
type = "tun";
};
interfaces.intl0 = {
Owner

call it trump0, he's the one who started this shit.

call it ``trump0``, he's the one who started this shit.
esavkin marked this conversation as resolved
esavkin force-pushed enable-mail-proxy-and-tunnel from 684c63bb49 to 568d6ccfb1 2024-08-29 17:28:25 +08:00 Compare
esavkin force-pushed enable-mail-proxy-and-tunnel from 568d6ccfb1 to 6a46388d68 2024-09-04 17:24:54 +08:00 Compare
esavkin changed title from WIP: Use postfix options for routing mails through ssh tunnel to WIP: Use postfix options for routing mails through tunnel 2024-09-05 15:40:47 +08:00
esavkin force-pushed enable-mail-proxy-and-tunnel from 6a46388d68 to ebe55e2fa6 2024-09-06 17:31:28 +08:00 Compare
sb10q reviewed 2024-09-06 17:32:35 +08:00
@ -230,0 +237,4 @@
interfaces.intl0 = {
ipv4.addresses = [
{
address = "10.42.0.2";
Owner

That's a private class A address. Again this is never going to work.

That's a private class A address. Again this is never going to work.
esavkin marked this conversation as resolved
esavkin added 1 commit 2024-09-09 15:12:39 +08:00
Owner

AX.25 is also in the kernel. Why not use that instead?

AX.25 is also in the kernel. Why not use that instead?
esavkin reviewed 2024-09-10 11:37:51 +08:00
@ -249,0 +256,4 @@
publicKey = "4RozbGZ9ENCjvJXGMB5aK1oqyZfD4UCarEHjSckwVGI=";
allowedIPs = [ "0.0.0.0/0" ];
endpoint = "5.78.86.156:51820";
persistentKeepalive = 25;
Author
Owner

TODO: needs disabling routing tables (Table = off in wg conf file), so it will open interface and let apps choose to use interface instead of forwarding all the traffic

TODO: needs disabling routing tables (`Table = off` in wg conf file), so it will open interface and let apps choose to use interface instead of forwarding all the traffic
Owner

You need to set up the policy-based routing for the interface choosing part. As has been done before with existing altnet and HKBN connections.

You need to set up the policy-based routing for the interface choosing part. As has been done before with existing altnet and HKBN connections.
esavkin marked this conversation as resolved
sb10q reviewed 2024-09-10 15:36:06 +08:00
@ -248,1 +248,4 @@
};
wireguard.interfaces = {
intl0 = {
ips = [ "10.42.0.2/32" ];
Owner

I think you'd want /31 and then route the default traffic on table 3 through 10.42.0.1 (which would be the VPS)?

I suppose you are then using a regular NAT on the VPS to forward that to the internet and also do the port redirections? Sounds hacky but should work.

I think you'd want /31 and then route the default traffic on table 3 through 10.42.0.1 (which would be the VPS)? I suppose you are then using a regular NAT on the VPS to forward that to the internet and also do the port redirections? Sounds hacky but should work.
Author
Owner

This IP is to acquire.
But for now its a draft anyway, I'll test and update.

This IP is to acquire. But for now its a draft anyway, I'll test and update.
Owner

If you use /32 then you can't reach any other hosts.

If you use /32 then you can't reach any other hosts.
Owner

Also with a /31 the last digits should be .0 and .1, .2 is not going to work.

Also with a /31 the last digits should be .0 and .1, .2 is not going to work.
Owner

This IP is to acquire.

What does that mean anyway?

> This IP is to acquire. What does that mean anyway?
Author
Owner

It corresponds to Interface.Address in the wg.conf, which results in ip -4 address add 10.42.0.2/32 dev intl0. Routes are done separately.

It corresponds to Interface.Address in the wg.conf, which results in `ip -4 address add 10.42.0.2/32 dev intl0`. Routes are done separately.
Owner

And to where will you route? I repeat: with a /32 address you cannot reach any other host.

And to where will you route? I repeat: with a /32 address you cannot reach any other host.
Author
Owner

For example ip route add 10.42.0.0/30 dev wg0.

The current problem with nix configuration is to ensure that it doesn't route too much by default, as it happens wg.conf (but it can be disabled by disabling tables).

For example `ip route add 10.42.0.0/30 dev wg0`. The current problem with nix configuration is to ensure that it doesn't route too much by default, as it happens wg.conf (but it can be disabled by disabling tables).
Owner

And why not just set the correct netmask in the first place?

Regarding the routing tables: You complain about strongswan (despite having been provided with fully working configuration files where you just had to change the IP addresses), but you should note that it doesn't mess up the routing tables. Your private network/NAT hack would also work with strongswan.

And why not just set the correct netmask in the first place? Regarding the routing tables: You complain about strongswan (despite having been provided with fully working configuration files where you just had to change the IP addresses), but you should note that it doesn't mess up the routing tables. Your private network/NAT hack would also work with strongswan.
esavkin marked this conversation as resolved
esavkin added 1 commit 2024-09-11 11:04:42 +08:00
5e13fc0bc2 Apply tested client configuration
Adds an additional route, but doesn't enforce it so other apps will remain the same, but smtp can use tunnel for sending. Also sends replies through the tunnel if connection arrives on the tunnel.
Better have something tested and working before I start doing "perfect".

Signed-off-by: Egor Savkin <es@m-labs.hk>
esavkin added 1 commit 2024-09-11 11:28:10 +08:00
2f1c11d779 Ip rules instead of iptables tracking
Signed-off-by: Egor Savkin <es@m-labs.hk>
esavkin added 1 commit 2024-09-13 15:06:37 +08:00
6382326316 Use IPv6 for WG transport to decrease latency by 20%
Signed-off-by: Egor Savkin <es@m-labs.hk>
esavkin force-pushed enable-mail-proxy-and-tunnel from 6382326316 to addc202345 2024-09-13 16:48:01 +08:00 Compare
This pull request is marked as a work in progress.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b enable-mail-proxy-and-tunnel master
git pull origin enable-mail-proxy-and-tunnel

Step 2:

Merge the changes and update on Gitea.
git checkout master
git merge --no-ff enable-mail-proxy-and-tunnel
git push origin master
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/it-infra#45
No description provided.