From nobody Thu Feb 16 13:02:33 2023 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PHZqb5JsCz3qQ52 for ; Thu, 16 Feb 2023 13:02:51 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PHZqb3FK4z3MBV for ; Thu, 16 Feb 2023 13:02:51 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0E63F654D9; Thu, 16 Feb 2023 08:02:45 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Source IP selection From: Paul Mather In-Reply-To: <20230216052233.sprgmazuunk25ynw@beesty.loosely.org> Date: Thu, 16 Feb 2023 08:02:33 -0500 Cc: User Questions Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230215222458.bij5oh3wtaq6inje@beesty.loosely.org> <20230215232241.5A86B9977DF3@ary.qy> <20230216052233.sprgmazuunk25ynw@beesty.loosely.org> To: Ian Zimmerman X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PHZqb3FK4z3MBV X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 16, 2023, at 12:22 AM, Ian Zimmerman = wrote: > On Wed, Feb 15, 2023 at 06:22:40PM -0500, John Levine wrote: >>> May the kernel choose an address through which there's no route to >>> the destination? >>=20 >> It knows what addreses it has configured on what interfaces, and >> what's in its local routing table, not the entire state of the global >> Internet. The routing table just tells it what interface to use for >> what networks. I think it does soemthing simple minded like using the >> first address configured on the interface if you don't override that >> with bind().=20 >>=20 >> If you bind a local address and then tell it to send to a remote >> address that isn't in the routing table for the interface the address >> is assigned to, I have no idea what happens. Try it and let us know >> what happens. >>=20 >> If you told us what you are trying to do, you would get more useful >> answers. >=20 > Yes, fair enough. >=20 > This is a sysadmin question, not a programming one. I cannot recompile > every program installed on the system to fix this (if it needs = fixing). >=20 > My VPS provider (Linode) gave me a secondary address so my two nodes > can talk to each other without accruing charges. Note that: >=20 > - it really is an alias on the same interface, *not* a VLAN >=20 > - it is not a publicly routable address (192.168.) >=20 > Here's an excerpt of the configuration, with one obvious change: >=20 > 6+1 ~$ ifconfig vtnet0 > vtnet0: flags=3D8863 metric 0 = mtu 1500 > = options=3D4c00b8 > ... > inet 123.123.123.4 netmask 0xffffff00 broadcast 123.123.123.255 > inet 192.168.135.161 netmask 0xffff8000 broadcast = 192.168.255.255 > media: Ethernet autoselect (10Gbase-T ) > status: active > nd6 options=3D23 >=20 > 7+1 ~$ netstat -rn > Routing tables >=20 > Internet: > Destination Gateway Flags Netif Expire > default 123.123.123.1 UGS vtnet0 > 123.123.123.0/24 link#1 U vtnet0 > 123.123.123.4 link#1 UHS lo0 > 127.0.0.1 link#2 UH lo0 > 192.168.128.0/17 link#1 U vtnet0 > 192.168.135.161 link#1 UHS lo0 >=20 > Now I am concerned what happens if something like unbound sends > to the outside world, in a client role. I don't think it binds its > socket, how would *it* know which address to use? It lets the kernel > decide, and I think most client programs do. So, can it get the > secondary address? In the specific case of unbound you can use the "outgoing-interface" = option in "unbound.conf" to bind to specific IP addresses for outgoing = traffic (e.g., to authoritative nameservers). Similarly, you can use = the "interface" option in "unbound.conf" to bind to specific IP = addresses or interfaces to limit where you receive queries. Many services have some similar configuration file/command line option = to limit or otherwise specify which IP addresses are bound by the = service when operating. Cheers, Paul.