Date: Thu, 16 Feb 2023 08:02:33 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Ian Zimmerman <possessor.assizer305@aceecat.org> Cc: User Questions <freebsd-questions@freebsd.org> Subject: Re: Source IP selection Message-ID: <B7D1F5BC-9817-4237-8B47-82C01A307E47@gromit.dlib.vt.edu> In-Reply-To: <20230216052233.sprgmazuunk25ynw@beesty.loosely.org> References: <20230215222458.bij5oh3wtaq6inje@beesty.loosely.org> <20230215232241.5A86B9977DF3@ary.qy> <20230216052233.sprgmazuunk25ynw@beesty.loosely.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 16, 2023, at 12:22 AM, Ian Zimmerman = <possessor.assizer305@aceecat.org> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 = mtu 1500 > = options=3D4c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,= LINKSTATE,TXCSUM_IPV6> > ... > 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 <full-duplex>) > status: active > nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> >=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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B7D1F5BC-9817-4237-8B47-82C01A307E47>