So, different IP means different DNS names
Or a dynamically updated DNS name. Windows machines do it all the time – all AD domain members send RFC2136 "UPDATE" messages towards the authoritative DNS server (that's what the ipconfig /registerdns option does) so that no matter where the machine is, it'll have a valid DNS entry. Windows even uses Kerberos to authenticate the updates.
With a dynamically updateable zone hosted by ISC BIND, you can have the same on Linux; you could have a network script that runs nsupdate to add/remove IP addresses as soon as a network connection is up.
nsupdate -g <<!
zone dyn.example.com
del $(hostname).dyn.example.com 0 ANY
add $(hostname).dyn.example.com 300 A ${ipv4}
add $(hostname).dyn.example.com 300 AAAA ${ipv6}
add $(hostname).dyn.example.com 300 SSHFP ${fingerprint}
send
!
(Other DNS servers also implement RFC2136 dynamic updates, although most of them only support PSK-based TSIG-HMAC authentication – BIND is the only one that supports Kerberos via GSS-TSIG.)
As mentioned in comments, the DHCP server may also update DNS upon receiving a DHCP lease request with the "hostname" option (most hosts send it, and most consumer wireless routers do this). The ISC BIND+dhcpd setup uses the same TSIG RFC2136 updates; others might have their own mechanisms.
You could also use Multicast DNS (mDNS) – add host/foo.local as a Kerberos principal and let avahi-daemon (or systemd-resolved) announce its own address to other LAN hosts. Support for mDNS is common on non-Linux systems as well.
i.e., different keytab entries.
It is possible to have both principals share the same keys; e.g. with MIT Kerberos using the LDAP backend, you could create LDAP alias objects and add multiple krbPrincipalName attributes.
ldapmodify <<EOF
dn: krbPrincipalName=host/[email protected],cn=EXAMPLE.COM,cn=Kerberos,o=FooInc
add: krbCanonicalName
krbCanonicalName: host/[email protected]
-
add: krbPrincipalName
krbPrincipalName: host/[email protected]
krbPrincipalName: host/[email protected]
-
EOF
ldapadd <<EOF
dn: krbPrincipalName=host/[email protected],cn=EXAMPLE.COM,cn=Kerberos,o=FooInc
objectClass: alias
objectClass: extensibleObject
aliasedObjectName: krbPrincipalName=host/[email protected],cn=EXAMPLE.COM,cn=Kerberos,o=FooInc
EOF
(I think Heimdal supports aliases with its default HDB backend as well, but MIT Krb5 does not.)
With aliases having been created, the server only needs keytab entries for one principal – it'll accept tickets issued for other principals as long as they successfully decrypt (which they will, if the keys are shared). Though you might need to enable this krb5.conf option for that to work:
[libdefaults]
ignore_acceptor_hostname = yes
This is most useful if some Kerberos clients don't do hostname canonicalization (e.g. when SSH'ing from Windows, which does not canonicalize hostnames at all), as it allows you to have both host/foo.example.com and host/foo for the same machine.
The NIC for LAN and WiFi have different MAC and thus DHCP will assign different IP addresses
As long as both Ethernet and Wi-Fi are not used simultaneously on the same subnet, it is possible to configure the same DHCP Client ID for both interfaces, and therefore receive the same lease on both interfaces (the Client ID takes priority over physical MAC address).
But isn't there a more convenient solution more oriented towards the machine rather than the NIC?
You could borrow the "loopback address" idea from enterprise routing – that is, decouple the "management" address from addresses assigned to the physical interfaces. (Also known in IPX as "internal network", or in LISP as "EID/RLOC", etc.)
A typical way to do this, is to create a dummy0 interface and assign it an IP address as a /32; then have the laptops run a small routing daemon such as babeld or Bird2 to announce it (as a stub interface) to other computers, via OSPF or Babel or RIP.
Devices running the routing daemon (either other hosts and/or your LAN router) will automatically know that they can reach the "loopback" IP address via any of the "physical" Ethernet/Wi-Fi IP addresses; the host will be able to switch from Wi-Fi to Ethernet or even move between subnets while retaining its address and active TCP connections.
Complexity aside, this has the disadvantage of most routing protocols being slightly "chatty" on Wi-Fi, which might impact battery life. (BGP is used in datacenters to have servers announce their IP addresses this way, and is is less chatty but it needs a router to support it, unlike OSPF/Babel which can run directly between all hosts.)
