Use postfix options for routing mails through tunnel #45
Loading…
Reference in New Issue
No description provided.
Delete Branch "enable-mail-proxy-and-tunnel"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Testable solution (wireguard) was replaced by ipsec/gre strongswan, which is not possible to test safely.
@ -1179,0 +1193,4 @@
@m-labs.hk :
@m-labs.ph :
@193thz.com :
@malloctech.fr :
Does postfix require all domains to be listed there, even those without a relay host?
As in examples at https://www.postfix.org/transport.5.html , a wildcard is probably a better way
Use postfix options for routing mails through ssh tunnelto WIP: Use postfix options for routing mails through ssh tunnel@ -219,0 +235,4 @@
address = "0.0.0.0";
prefixLength = 0;
via = "5.78.86.156";
options.table = "2";
Already in use, please pay attention.
@ -1190,0 +1245,4 @@
services.postfix = {
config = {
sender_dependent_relayhost_maps = "hash:/etc/postfix/sender_relay";
postscreen_upstream_proxy_protocol = "haproxy";
What?
@ -219,0 +223,4 @@
ttl = 255;
type = "tun";
};
interfaces.intl0 = {
call it
trump0
, he's the one who started this shit.684c63bb49
to568d6ccfb1
568d6ccfb1
to6a46388d68
WIP: Use postfix options for routing mails through ssh tunnelto WIP: Use postfix options for routing mails through tunnel6a46388d68
toebe55e2fa6
@ -230,0 +237,4 @@
interfaces.intl0 = {
ipv4.addresses = [
{
address = "10.42.0.2";
That's a private class A address. Again this is never going to work.
AX.25 is also in the kernel. Why not use that instead?
@ -249,0 +256,4 @@
publicKey = "4RozbGZ9ENCjvJXGMB5aK1oqyZfD4UCarEHjSckwVGI=";
allowedIPs = [ "0.0.0.0/0" ];
endpoint = "5.78.86.156:51820";
persistentKeepalive = 25;
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 trafficYou need to set up the policy-based routing for the interface choosing part. As has been done before with existing altnet and HKBN connections.
@ -248,1 +248,4 @@
};
wireguard.interfaces = {
intl0 = {
ips = [ "10.42.0.2/32" ];
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.
This IP is to acquire.
But for now its a draft anyway, I'll test and update.
If you use /32 then you can't reach any other hosts.
Also with a /31 the last digits should be .0 and .1, .2 is not going to work.
What does that mean anyway?
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.And to where will you route? I repeat: with a /32 address you cannot reach any other host.
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).
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.
6382326316
toaddc202345
12af7ce0ad
tob3c97d0fb5
b3c97d0fb5
to451328c28b
WIP: Use postfix options for routing mails through tunnelto Use postfix options for routing mails through tunnelStop whining and listen to the instructions I gave you on several occasions to test this without taking out the server connection.
Your comment is just like saying that website changes cannot be tested before deployment because HTTP servers do not work behind NAT. I gave you at least four ways to make it work for testing in the case of GRE.
Well indeed I cannot allocate a global IPv4 for myself.
I checked with IPv6 - tunnel works, once loaded just needs a few iptables rules on intl side.
Also checked that postfix builds and loads successfully and accepts connections from both interfaces.
That enforceful advice of doing the "seemless" (?) routing using GRE was totally misleading. NAT + a few iptables rules is the only possible way since most cloud providers do not allow global IPv4 subnets (Hetzner has this feature on Robot, which is VDS, which is overkill for a simple port forwarding since easier, more straightforward, more common and cheaper solutions exist).
Cannot do this, cannot do that... Anyway this is only one of the several ways of testing it, and as I told you multiple times and as you could have figured out by studying the contents of this repo, we in fact have VLAN switch ports with additional public IPv4s for your convenience.
GRE vs. Wireguard and IP range vs. NAT have nothing to do with each other, and all four combinations of these are possible. You just keep whining whilst demonstrating your lack of understanding of computer networks.
@ -1208,2 +1261,4 @@
};
services.postfix.mapFiles.sender_transport = pkgs.writeText "sender_transport" ''
@m-labs-intl.com smtptun:
"smtptun" is quite a confusing name. You'd think it's some postfix internal option. Make it more specific and explicit.
02b0095e81
toed9b79a2d7
ed9b79a2d7
to4d7e836f07
They're packets to/from the public internet. They don't really need to be encrypted. That's what AH is for.
6d2f4d136e
to0ff90d54a9
0ff90d54a9
to60903e955f
Appears that firewall indeed does reject the AH+GRE packets from intl host by default - it happens before these packages get unwrapped to other interfaces.
Latest commit with iptables extra rules solves this issue.
@ -97,0 +99,4 @@
iptables -A INPUT -s 5.78.86.156 -p ah -j ACCEPT
iptables -A OUTPUT -d 5.78.86.156 -p gre -j ACCEPT
iptables -A OUTPUT -d 5.78.86.156 -p ah -j ACCEPT
'';
Still zero explanation why this would be required for your tunnel only and not altnet, nor why it works without it anyway.
Most likely because intl is NATed, and altnet is not, which interferes with conntrack rules in iptables.
This makes no sense.
How do you trigger a problem which is addressed by these iptables commands?
Just send the ping or telnet from intl to the hk end's NATed address. It gets rejected (in the logs) on the hk side, and then it sends destination/port unreachable to the unNATed intl (it's done by iptables rules).
Here iptables table with counters (
ip6tables -L -v -n
):So by default iptables in nixos firewall indeed rejects any IP packets with custom headers (like that with AH and GRE), and as it seen in logs in the last line.
The other way works because it falls into
ctstate RELATED,ESTABLISHED
rule, and once hk host sends to intl at least one packet conntrack will mark intl->hk packets as related or established and thus iptables will accept it.I guess in case of altnet it doesn't fail because it gets unwrapped earlier, or conntrack is able to do the tracking properly (unlike in case of NAT).
@ -1252,0 +1265,4 @@
ExecStart = "${pkgs.postfix}/sbin/postmap /var/lib/postfix/conf/sender_transport";
};
wantedBy = [ "multi-user.target" ];
};
Is this really required? I would expect NixOS to deal by itself with
services.postfix.mapFiles
without requiring any additional user-defined systemd services.https://github.com/NixOS/nixpkgs/blob/nixos-24.05/nixos/modules/services/mail/postfix.nix#L752-L755
Does this not work for some reason, or is it your usual sloppiness?
@ -1261,1 +1278,4 @@
} // (import /etc/nixos/secret/email_settings.nix);
services.postfix = {
config = {
sender_dependent_default_transport_maps = "hash:/var/lib/postfix/conf/sender_transport";
I have not looked into it, but considering your sloppy code above, this looks suspicious and I recommend you review this and double check that this is the right way of doing it.
@ -1262,0 +1286,4 @@
args = [
"-o" "smtp_bind_address=10.47.3.1"
"-o" "inet_interfaces=10.47.3.1"
"-o" "inet_protocols=ipv4"
Are the last two lines necessary, considering the first line?
@ -1261,1 +1264,4 @@
} // (import /etc/nixos/secret/email_settings.nix);
services.postfix = {
mapFiles.sender_transport = pkgs.writeText "sender_transport" ''
@m-labs-intl.com intltunnel:
In https://www.postfix.org/transport.5.html I don't see the syntax
@domain
. Justdomain
. What is going on?I checked previously and it just didn't work until I used
@domain
Why the apparent discrepancy with the documentation? How carefully did you check?
@ -1262,0 +1276,4 @@
args = [
"-o" "inet_interfaces=10.47.3.1"
"-o" "smtp_helo_name=mail.m-labs-intl.com"
"-o" "inet_protocols=ipv4"
Is inet_protocols=ipv4 still needed?
Yes, otherwise it tries to use ipv6
Despite net_interfaces=10.47.3.1 ?
Yes
@ -1262,0 +1266,4 @@
mapFiles.sender_transport = pkgs.writeText "sender_transport" ''
@m-labs-intl.com intltunnel:
* :
'';
Is the line
* :
needed?@ -97,0 +97,4 @@
extraCommands = ''
iptables -A INPUT -s 5.78.86.156 -p gre -j ACCEPT
iptables -A INPUT -s 5.78.86.156 -p ah -j ACCEPT
'';
This is piling up iptables rules at each firewall activation. You need to clear them somewhere...
I didn't notice rule duplication on rebuild switch, I guess in between they just flush all -> forbid all -> flush -> apply new rules.
nixos-rebuild switch only restarts units which have changed.
2ee23bc03a
to8ff15e4aba
@ -93,3 +93,3 @@
allowedTCPPorts = [ 53 80 443 2222 7402 ];
allowedUDPPorts = [ 53 67 500 4500 ];
trustedInterfaces = [ netifLan ];
trustedInterfaces = [ netifLan netifUSA ];
No.
8ff15e4aba
to785777eb0e
Pull request closed