网络初学者,但我在网络和移动应用程序开发方面有 10 多年的经验,所以我对技术并不陌生。
我最近开始与一些开发运营工程师一起在一个新团队工作,他们非常熟悉网络、系统、服务、自动化和配置。为了以低成本学习更多知识,我买了 4 个 Raspberry Pi 和一个非托管交换机。
我从基本的网络和 Linux 管理开始,以进一步了解支持我所构建的应用程序的外围设备和平台技术。
我希望我的 Raspberry Pi 在任何 Raspberry Pi 连接时都能从我的调制解调器/路由器/wifi 接入点设备 (Motorola Surfboard G6580) 分配静态 IP。是否可以让 Raspberry Pi(或任何其他设备)从 DHCP 服务器请求特定的静态 IP?
调制解调器有一个 192.168.0.1 网址,允许我根据 mac 地址管理静态 ips 的 dhcp 分配。但是,我很好奇是否可以通过 raspberry pi 本身的请求自动执行此操作。
答案1
静态 IP
我希望为我的 Raspberry Pi 分配静态 IP
用我的术语来说,这些不是“静态的”。设备会选择自己的“静态 IP”地址。
但是,根据问题,我可以知道您在寻找什么:服务器已保留的动态地址。
如果 Raspberry Pi 甚至懒得询问 DHCP 服务器,那么它就是静态的(并且 DHCP 服务器仍然可以保留该地址)。如果地址如您所指定的那样“来自”DHCP 服务器,那么 Raspberry Pi 会从该地址询问 DHCP 服务器,因此它是“动态的”(从某种意义上说,Raspberry Pi 接受服务器指定的任何内容,因此如果 DHCP 服务器确实更改了地址,那么 Raspberry Pi 可能会接受更改。因此,从 Raspberry Pi 的角度来看,它是动态的,即使 DHCP 服务器将其称为保留的动态地址。
是否可以让 Raspberry Pi(或任何其他设备)从 DHCP 服务器请求特定的静态 IP?
不是,因为如果请求该地址,则它不是静态的。(它可以发出请求并获取保留地址。)
调制解调器有一个 192.168.0.1 的网址,它允许我根据 mac 地址管理静态 ips 的 dhcp 分配。
这些是保留地址,不是静态的。
很抱歉反复强调这一点,但问题中确实使用了“静态”一词,我不同意,所以我希望尽早改正这个习惯。即使正确使用术语,网络也可能会非常令人困惑,因此我鼓励您使用术语“静态 IP”来指代从自动地址分配协议(如 DHCP)收到的地址。(虽然 DHCP 在 IPv4 中最为普遍,但它并不是唯一可能的选择。例如,有“路由器通告”,它在 IPv6 中的使用可能比 IPv4 更广泛,只是因为 DHCP 在 IPv4 中得到了如此广泛的支持,经验表明它运行良好)。
请求 IP
设备是否可以向 DHCP 服务器(静态或动态)请求分配特定 IP?
是的。DHCP 协议允许这样做。它不是静态的,而是“保留的”。
如果你看一下 DHCP 通信,就会发现 DHCP 遵循多拉方法。DORA 代表发现 (DISCOVER)、提供 (OFFER)、请求 (REQUEST)、确认 (ACKNOWLEDGE)。
在简单事务中,序列可以像 DORA 一样简单。(这意味着有一个 DISCOVER、一个 OFFER、一个 REQUEST 和一个 ACKNOWLEDGE。)DHCP 客户端可以请求它想要的任何地址。如果客户端离开网络,然后返回并倾向于使用以前使用的地址,通常可以这样做。如果 DHCP 客户端请求不可接受的地址,则可能导致一些较长的通信,例如 DORORA。以下是此类通信的摘要。
首先,有几点需要注意:
- 描述 DORA 步骤之一的粗体字母代表实际发送的通信。
- 还使用粗体字母来帮助识别机器。
- 在以下示例中,按照以下说明使用 192.0.2 子网RFC 5737
-
以下地址为原文地址:
- 0.0.0.0
- 255.255.255.255
- FF-FF-FF-FF-FF
-
以下是更多示例地址,并将进行定制:
- 11-11-11-22-22-22
- 和 33-33-33-44-44-44
现在,承诺的沟通摘要如下:
- [客户]:“我没有 IP 地址。我想改变这种情况。”
- [客户]使用 IP 地址 0.0.0.0、MAC 11-11-11-22-22-22,并发送到 255.255.255.255、FF-FF-FF-FF-FF:并发送发现消息。(嘿!那里有 DHCP 服务器吗?)
- 可选步骤:【DHCP中继代理】传达给[DHCP 服务器],可能位于另一个子网。为了简化起见,我们不会详细介绍【DHCP中继代理】和[DHCP 服务器]. 请注意[DHCP 客户端]不需要注意[DHCP 服务器]或【DHCP中继代理】(顺便说一下,我不记得是否有可能[DHCP 客户端]做出这样的区分。
-
[DHCP 服务器或中继代理]位于同一子网,从 IP 地址 192.0.2.1 MAC-48 地址 33-33-33-44-44-44 响应到 0.0.0.0 MAC-48 地址 11-11-11-22-22-22:提供 192.0.2.140。(此优惠的意思是[服务器或中继代理] 可以让客户预订192.0.2.140(如果需要)。
- 如果存在多个[DHCP 客户端]同时进行通信,这是可以的,即使它们可能共享一个 IP 地址(如 0.0.0.0),因为可以使用各个 MAC-48 地址来跟踪各个对话。
-
[DHCP 客户端]忽略提供的 192.0.2.140 地址,因为[客户]更喜欢客户端昨天拥有的 192.0.2.135 地址。因此,客户端可以完全忽略 OFFER 提供的地址,只需请求它想要的任何内容即可。(这将在下一次通信中得到演示。)
- 这代表了客户所拥有的“影响力”。这不是绝对的权力,但如果[DHCP 服务器]我们会热情配合。
- (在实际使用中,这对于从休眠状态唤醒的笔记本电脑来说可能很常见?)
-
[DCHP 客户端]到[DHCP 服务器或中继代理],在同一子网中,从 0.0.0.0 MAC-48 11-11-11-22-22-22,发送到 192.0.2.1 地址 33-33-33-44-44-44:要求为理想192.0.2.135
- 此时,客户端发送了它的请求并希望得到确认。
- [DHCP 服务器]意识到 192.0.2.135 不再可用。
- [DHCP 服务器或中继代理],从 192.0.2.1 地址 33-33-33-44-44-44,到 0.0.0.0 MAC-48 11-11-11-22-22-22:提供 192.0.2.140
- [DHCP 客户端]因 OFFER 与 REQUEST 不匹配而感到失望。客户端因未收到理想的报价而感到失望,因此尝试一些更可能被这个不太合作的服务器接受的方案。
- [DHCP 客户端],从 0.0.0.0 MAC-48 11-11-11-22-22-22,到 192.0.2.1 地址 33-33-33-44-44-44,要求 192.0.2.140
-
[DHCP 服务器或中继代理]决定合作。它做了两件事:
-
[DHCP 服务器]记录租约,以便不会再次发出相同的地址。
- 该地址现在正式不再供其他任何人使用。客户端可能会对此地址感到满意,因为它已被请求。客户端无需指定任何进一步的协议
- [DHCP 服务器或中继代理],从 192.0.2.1 MAC-48 33-33-33-44-44-44 到 MAC-48 11-11-11-22-22-22,注意到它已决定承认(并由此批准)192.0.2.140要求。
-
[DHCP 服务器]记录租约,以便不会再次发出相同的地址。
DHCP 客户端只有在收到以下信息后才允许开始使用提供的地址:承认。(实际上,DHCP 服务器可以向多台计算机提供地址,并且这不会造成冲突,因为这些地址在实际提供 ACKNOWLDGE 之前应该保持未使用状态。)因此,从这个意义上讲,DHCP 客户端在收到 ACKNOWLEDGE 响应之前不会获得任何绝对权限,但它仍然可以通过决定要请求什么来拥有一些影响力。
如果服务器不想配合请求,它所要做的就是不确认。它可以礼貌地选择提供其他内容,也可以忽略不适当的请求,所有这些都不会冒授权使用不需要的 IP 地址的风险。当 DHCP 服务器收到请求时,DHCP 服务器可以决定查看请求的 MAC-48 地址并在决定要提供什么时使用该信息。这就是服务器如何有效地限制提供的地址仅使用 DHCP 预留中显示的地址的方式。
因此,REQUEST 可以请求其所需的任何特定 IP 地址。如果 DHCP 客户端不知道哪个 IP 地址可能对 REQUEST 来说是安全的,则 DHCP 客户端可以查看最后一个 OFFER,或者发送 DISCOVER 包并寻找新的 OFFER。
最后,
我很好奇,想知道是否可以通过来自树莓派本身的请求来实现自动化。
如果使用 Unix,请检查 /etc/dhclient.conf 文件。我知道这样的文件可用于指定使用哪些 DHCP 选项。(最常见的“DHCP 选项”示例是子网的大小(“子网掩码”)、路由器的地址(“默认网关”),但其他信息也可以由 DHCP 服务器共享,并由 DHCP 客户端使用(或忽略)。我怀疑该文件可能是您可以指定所需地址的地方。看起来所需的行可能是:“ send dhcp-requested-address 192.0.2.135;
”(参见:ISC dhclient.conf 手册页, 和dhcp-options 的 ISC 手册页, 和自答问题:如何从 DHCP 服务器请求特定的 IP 地址?)