=== timeless_ is now known as timeless === npgm_ is now known as npgm === ]42[ is now known as [42] [09:47] PeGaSuS: If you remove any gateway6 the IP addresses still stay the same. This settings is only about where outgoing packages are being send [11:19] Hi [11:19] maybe someone can help me with an issue ? [11:20] i have set up netplan with one physical nw-adapter and defined some virtual ip-addresses for a reverse proxy [11:22] this works so far, but: when i request the website via the virtual ip, the proxy sents the request to the backend via an other ip, as i have requested [11:23] eg: client => 192.168.0.2 => rev. proxy to 192.168.0.10 but the request to the backend will be via ip-address 192.168.0.1 [11:27] what do you mean by virtual ip-address? probably best to put your netplan in a pastebin/gist [11:28] network: [11:28] ethernets: [11:28] enp0s3: [11:28] dhcp4: no [11:28] addresses: [10.24.10.30/24,10.24.10.31/24,10.24.10.33/24] [11:28] gateway4: 10.24.10.50 [11:28] nameservers: [11:28] addresses: [10.24.10.50] [11:29] i have 3 addresses on one physical interface [11:30] i make a request to 10.24.10.31 this will be forwarded via reverse-proxy to a backend-server [11:30] but the request to the backend will be made via 10.24.10.30 [11:30] and not via 10.24.10.31 as requested [11:31] slyon: right. I've just tested and this seems to work: https://termbin.com/dm07 [11:31] neo7530: I think you mean, not via, but with source address? [11:32] (via implies a hop via a router) [11:32] yep [11:32] the request to the backend should be the same as my client sent the request to [11:33] same ip, i mean [11:34] right - you need source routing to enable this. ie. a route where you specify from: and table: [11:34] table is just some integer to separate the routing from the default route table [11:35] btw, one of my favourite commands when checking stuff like this is "ip route get A.B.C.D" - it will tell you what src address the kernel will use for a new connection there [11:44] and how should i do this? i'm fairly new to netplan [12:08] routes: [12:08] - [12:08] from: 10.24.10.31 [12:08] to: 10.24.10.31 [12:08] via: 10.24.10.31 [12:08] table: 17 [12:08] ehhh [12:09] cut and paste error of your addresses [12:09] to: 192.168.0.10 [12:09] I think is what you wanted? [12:10] hmmm [12:10] local 10.24.10.31 dev lo table local src 10.24.10.30 uid 0 [12:15] doesn't work [12:17] you need to explain what you want again [12:17] the components are not clear [12:19] okay. client = 10.24.10.xxx reverse-proxy 10.24.10.31 backend 10.24.10.10 [12:20] client request goes to *31 [12:21] reverse-proxy talks to the backend via *30 but should use the *31 for communication [12:21] same address outgoing as ingoing [12:22] *30 *31 *33 are on the same physical interface [12:29] so backend is your value for to [12:29] and reverse-proxy your values for from and via [12:31] there might be a better method to make .31 preferred generally - you don't really need a specific exception rule here, it seems [12:35] ip route get 10.24.10.10 [12:35] 10.24.10.10 dev enp0s3 src 10.24.10.30 uid 0 [12:35] makes no difference [12:35] routes: [12:35] - to: 10.24.10.10 [12:35] from: 10.24.10.31 [12:35] via: 10.24.10.31 [12:35] table: 101 [12:44] oh. I thought netplan added the ip rule automatically :-( [12:44] "15:01 btw, I just set up source based routing with Netplan - so simple I hardly could believe it :)" - it was too good to be true ... [12:46] maybe i should use iptables for this [12:46] :/ [12:48] ahhh - I need to add routing-policy! [12:48] you, too. [12:48] routing-policy: [12:48] - from: 10.24.10.31 [12:49] table: 101 [12:49] ahh, i try this [12:50] the from: in the routes is probably superfluous, then [12:52] nope, makes no difference [12:52] this is odd :/ [12:57] hrm, no ip rules installed here either [13:54] hrm, it does work for me though - but I don't understand how, since ip rule does not list any new rules [13:54] slyon: ^ how does routing-policy work behind the scenes? [13:56] now I'm not sure if routing-policy is needed for my case after all. it's a bit awkward to test since a reboot is required. [13:56] (I mean, applying config will not clean up random stuff added earlier) [14:04] kjetilho: behind the scenes netplan generates a [RoutingPolicyRule] section inside a .network file for systemd [14:08] sorry for being a n00b, but I can't find anything like this (I'm on Ubuntu Focal) [14:09] that is, no units of type network at all. [14:16] right, they end up in /run/systemd/network [14:16] and right², the from-parameter in a route ends up as PreferredSource in the .network file [14:17] correct, /run/systemd/networkd/10-netplan-*.network [14:18] perhaps my netplan version is too old - 0.101 [14:18] grep -i policy /run/systemd/network/* → nada [14:18] 0.101 is the latest version. But the "from" parameter should end up as "From=...", see https://paste.ubuntu.com/p/ydTWpBq9yS/ [14:19] the from in a route, not routing policy [14:20] ah yes, then you're right [14:20] did you run 'netplan generate' before? to produce the latest files. Also this only applies only if using the 'networkd' renderer (the default). Do you use NetworkManager renderer? [14:20] doh. I was running netplan apply ~kjetilho/login-osl2.yaml [14:20] that really should cause an error [14:21] (or preferably - work) [14:22] there we go, I got ip rules :) [14:22] nice! [14:22] (after copying my file to /etc/netplan [14:23] I do wonder if PreferredSource is sufficient for me