如果没有考虑到特定的应用程序，这很难回答，但我会尝试给出一些通用的提示：
创建一个容器，存储所有允许连接的客户端的所有地址（成功登录后）
由于 NAT，这根本行不通，遗憾的是，由于 IPv4 耗尽，它仍在使用，实际上甚至增加了。你至少需要 src-ip+src-port。即便如此，考虑到移动用户，您可能永远不想使用 IP 作为会话 ID。普通智能手机会很容易地在蜂窝网络和 WiFi 网络之间切换，通常会导致 IP 堆栈完全重启，因此无法将新流量与之前的流量关联起来。这可能是也可能不是问题，但除非您可以控制 IP 地址，否则我永远不会使用这种方法。
创建一个存储所有会话 ID 的容器（会话 ID 将与每个数据包一起发送）
这实际上是通用解决方案，您的第一个解决方案只是一个特定的实现，您使用源 IP 作为会话 ID。如果您担心会话 ID 管理，只需使用UUID，会话 ID 之间发生冲突的几率非常低。或者，当使用公钥/私钥加密时，您可以使用用户的公钥作为会话 ID。
这里的一个重要部分是如何协商会话 ID。你可能想让用户选择，你可能想用一个“特殊的”会话ID（例如0）来让服务器选择。什么是最好的取决于您的应用程序。
有人可以更改数据包发件人的地址吗？（我假设是的）
当然，这被称为中间人攻击（如果对传输中的数据包进行）或IP 地址欺骗（如果发送带有假 IP 的数据包），并且对于大多数最终用户来说是无法检测到的。尽管许多网络对此都有保护，例如使用反向路径转发。
会话 ID 可能会被嗅出。（我记得一些大公司的名字有这个问题）
如果加密：也许（见下文）。如果没有加密：当然。
那么关于你的加密问题的整个部分：
一般来说，您走在正确的轨道上，您通常希望对常规流量使用对称密钥加密方案。AES 是一个不错的选择，但还有其他的，去研究一下吧。
但是，您在设置加密时遇到了问题。通常，您需要安全地获取双方的加密密钥，而无需人们嗅探它们。您可以尝试通过航空邮件发送密钥，但我怀疑大多数用户会发现这对用户很友好，即使这样也不是很安全。
这就是非对称密钥加密方案的用武之地。您通常会使用 RSA 之类的东西来协商初始连接（会话 id、加密密钥，也许是一些记帐，...），并让对称密钥接管实际流量。一个流行的方案是Diffie-Hellman 密钥交换，但同样还有更多。
话虽如此，您可以很好地保护您的频道，但中间人攻击始终是一个问题。事实证明，实际上您几乎无法真正防止这种情况发生，因为您无法控制其中一方（客户端），如果它是受感染的机器，则所有赌注都关闭：
- 为每个用户使用唯一的、预分配的私钥，您可以使用传入会话进行验证。如果他们没有以其他方式获得该密钥，这将使 mitm 攻击更加困难，但非自动生成的私钥通常难以与用户友好性相结合。您在如何分发它们（该死，我如何在那里处理 mim？）、如何将它们存储给用户（哦，他使用笔记本电脑、iPhone 和 iPad）、如果丢失时如何恢复它们、. ..
- Make sure that all traffic is initiated by the client and encrypted immediately with the server's public key. This is easier as you don't have to distribute a private key. However, a hacker can still replace your server's public key with it's own key, but it's a lot harder and if done right almost comes down to installing a virus on the client computer.
- Do some sanity checks in your client application. For example, make sure you're connecting to a known pool of server IP's, check if the DNS query is correct, etc etc. It's far from fail-safe but it are simple verification that will discourage potential hackers.
- Educate your users. This is what many banks do (at least where I live), let them do a regular anti-virus check, only use trusted WiFi-networks, verify the DNS servers, ... . Of course some things are harder to teach then others, but a little common sense gets you a long way.
Oh and finally I do actually want to comment on the UDP part: are you really really sure? Because almost everything of this scheme and even a lot more is covered by TLS, which is integrated in boost asio. If your traffic is that low-rate I can hardly imagine it's an application that needs the advantages that UDP offers, unless you want to secure voip, which is done already, don't reinvent the wheel.