Language:
switch to room list switch to menu My folders
Go to page: First ... 73 74 75 76 [77]
[#] Wed Aug 24 2022 17:06:27 EDT from nonservator

[Reply] [ReplyQuoted] [Headers] [Print]

The two most annoying responses on Usenet are still with us today:

"Why would you want to do that?"

and

"You don't want to do that."



[#] Wed Aug 24 2022 19:32:30 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

It's ok, I think my motive for wanting to do that needed to be justified.

[#] Fri Aug 26 2022 10:53:43 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


When I set up VPN connections like that, I usually just route only our internal subnet over the tunnel. Except when I have a strong need to appear as if I'm coming from a different IP address.

[#] Fri Aug 26 2022 13:05:48 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Right -- that's a split tunnel and it's the most efficient way of making things work. Security theater people do non split tunnel because they believe it's more secure to have your Internet traffic go through "their" firewall (and captive DNS and security scanners etc etc) while you're connected to the corporate network.

(Side note: this makes it impossible to use your own network printer, and I can't bypass that on my work machine even with admin access. I actually had to publish a hidden port on my home router, resulting in print jobs taking a 600+ mile round trip to the VPN location and back, when the printer is actually six feet away from the computer.)

As for my setup though, it's non split tunnel because the /29 routed in by my VPN provider is hosting services on the public Internet (including this site) so split tunnel isn't an option; it has to reach the entire Internet.

The reason I want to change things up is because I want to *add* another VPN -- this time to just connect my home network to the server network. And I don't want one VPN to run over the other.

[#] Tue Aug 30 2022 16:08:39 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

(Side note: this makes it impossible to use your own network printer,


I CAN'T PRINT!!!!!1

[#] Tue Aug 30 2022 16:10:49 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

As for my setup though, it's non split tunnel because the /29 routed

in by my VPN provider is hosting services on the public Internet
(including this site) so split tunnel isn't an option; it has to reach

the entire Internet.

there might be a DNS domain-route workaround for that

[#] Sat Sep 03 2022 13:33:33 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

You mean like looking for the dynamic DNS name of the other end and then setting the route appropriately? That could work, as ugly as it might be. There is also the possibility of playing around with route tables and trying to find a way to set a different routing table for a single program. I suspect there's a way to do it.

From home I have two things that need to reach the hosting network directly.
One is me; i.e. connecting to the servers from my desk at home. I've largely solved this by setting up ProxyJump directives in my .ssh/config file. Anything in that range of addresses, SSH automatically tunnels through the machine that runs the VPN VM, and then through the VPN VM itself, and then to the host. It works for regular SSH; it even works from (gasp!) VS Code.

The second is my I2P router. I really want I2P connections to reach the hosted services out-of-band from the normal path. I think I have a solution for this. I bought a $3.50/month server from OVHcloud and I'm going to move my router there. Since it has a static IP address, I can set a host route on the other end and run WireGuard between them.

[#] Sat Sep 03 2022 16:11:18 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

3.50 a month is cheap.



[#] Sat Sep 03 2022 16:39:07 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

It sure is. One of the people here via I2P mentioned it to me. They're having a summer promo and I took advantage of it. It's the perfect place for running a tiny little darknet router. Also they don't charge for transfer, they set the service price based on a bandwidth cap (in this case 250 Mbps which I consider pretty generous; Ace only gives 5 Mbps). You could totally use that for an Internet-facing presence and then use a VPN back to the origin servers.

Back to the previous discussion: I think I might see a way to do what I need.
Let's say the VPN is running on port 64444 (that's in a good range for WireGuard; substitute 1701 for L2TP or 443 for SSLVPN or whatever). We want traffic from the VPN program to use the host system's default gateway, while all remaining traffic is entered into the tunnel. The tunnel, again, is the default gateway once the VPN is established.

So...

ip route add table 100 default via <the real default gateway for the host> dev ens0
ip rule add fwmark 0x2 table 100
<various rules to flush out old tables and set local metrics etc>

Followed by...

iptables -t mangle -A OUTPUT -p udp --dport 64444 -j MARK --set-mark 2

I'll try it later.

[#] Sat Sep 03 2022 17:52:17 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

I have bookmarked them for later. Might want an off-site server sometime.

What OS are they running on the VMs?  I didnt see it listed from a quick glance at the plans.



[#] Mon Sep 05 2022 18:16:30 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

I'll try it later.

Turns out I was thinking too much. I do that sometimes.

It was easy. Instead of playing around with fwmark and other such incantations, the solution was to start understanding Linux's multiple routing table capabilities and how they can be used outside of containers and namespaces etc.

Step 1: create a routing table, in this case table 100, and make its default the tunnel:
ip route add default dev $1 table 100

Step 2: use that table to route all traffic originating from the origin server network:
ip rule add from 72.0.224.88/29 table 100

That's all it took. None of the other nonsense worked. This worked elegantly and beautifully. Now, traffic being forwarded *through* the host goes into the tunnel, while traffic to/from the host stays on the main routing table.

This of course gets me right back to where I started, but now I can add more VPNs without needing to know the IP address of the other end. I intend to create a Wireguard VPN from my home router to this router, but I have dynamic IP at home. WireGuard supports one end being dynamic. So now when I get a WireGuard connection I simply add the route to my home network (192.168.1.0/24) to table 100 instead of table main. Easy fo'sheezy and everything just works.

[#] Mon Sep 05 2022 19:50:32 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Overthinking has burnt us all a few times :)

 

And that is cool.



[#] Wed Sep 07 2022 14:14:08 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

2022-09-03 13:33 from IGnatius T Foobar
You mean like looking for the dynamic DNS name of the other end and
then setting the route appropriately? That could work, as ugly as it


what I mean is, systemd-resolved has a mode where you can tell it which TLD/suffix to route to which interface. And each interface has its own DNS servers.

So if you use a TLD like .internal or anything else specific to your org, you can configure the routing so that those names will only ever be queried against the nameservers associated with your VPN interface.

In the absense of this config, the default behavior of systemd-resolved is to send the DNS query on all interfaces at once, and return the first positive response it receives. This mostly works OK, but it has two drawbacks:

1) DNS queries for your internal hosts are sent to the public internet, and might be observed by an attacker who can then gather intel about your internal topology
2) If the address resolves differently when it's queried on your internal nameserver, the result you get is the luck of the draw.

OpenVPN has a config option `dhcp-option DOMAIN-ROUTE foo` which can be used to communicate this config to systemd-resolved (assuming it's not broken at the moment...)

[#] Wed Sep 07 2022 15:06:42 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Oooooh, that explains the output of "resolvectl dns" and how it spits out interface-specific resolvers. I was playing around with that yesterday in search of a better way to say "tell me this system's resolvers" other than scanning through /etc/resolv.conf and /etc/systemd/resolved.conf and /etc/netplan/* etc etc etc.

systemd is good at that sort of thing, which is one of the reasons I like it.

For this purpose I'm not sure I could cleanly map a domain to it, because it's acting as a router, and also it's got servers rather than clients behind it. What you are describing sounds like just the thing for split tunnel client VPN though. And that's probably why they did it.

The solution I described earlier feels pretty clean at the moment. One routing table for input/output and another for forwarding.

Go to page: First ... 73 74 75 76 [77]