[翻译]systemd-resolved

URL:https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html

网络名称解析管理器 systemd-resolved.service

systemd-resolved是一项系统服务,可为本地应用程序提供网络名称解析。它实现了缓存和验证DNS / DNSSEC存根解析器以及LLMNR和MulticastDNS解析器和响应器。本地应用程序可以通过三个接口提交网络名称解析请求:

  1. 系统解析的本机,功能齐全的API 在总线上公开。有关详细信息,请参见 API文档。通常建议客户端使用此API,因为它是异步的且功能齐全(例如,为支持本地链接网络而正确返回DNSSEC验证状态和地址的接口范围)。
  2. RFC3493定义的glibc getaddrinfo(3) API 及其相关的解析程序功能,包括gethostbyname(3)。该API得到了广泛的支持,包括Linux平台之外的其他支持。当前,它不公开DNSSEC验证状态信息,并且仅是同步的。此API由glibc名称服务开关(nss(5))支持。 为了允许glibc的NSS解析器功能通过systemd-resolved解析主机名,需要 使用glibc NSS模块nss-resolve(8)
  3. 此外,systemd-resolved在本地回送接口上的IP地址127.0.0.53上提供了本地DNS存根侦听器。直接绕过任何本地API发出DNS请求的程序可以定向到此存根,以便将它们连接到systemd-resolved。但是请注意,强烈建议本地程序改用glibc NSS或总线API(如上所述),因为各种网络解析概念(例如链接本地寻址或LLMNR Unicode域)无法映射到单播DNS协议。

联系的DNS服务器由以下各项中的全局设置确定: 文件中/etc/systemd/resolved.conf的每个链接静态设置 /etc/systemd/network/*.network(如果使用 systemd-networkd.service(8)),通过DHCP接收的每个链接动态设置,通过resolvectl发出的用户请求 (1),以及其他系统服务可用的任何DNS服务器信息。见 resolved.conf(5)和 systemd.network(5)有关DNS服务器systemd自己的配置文件的详细信息。为了提高兼容性, /etc/resolv.conf为了发现已配置的系统DNS服务器,必须对其进行读取,但前提是它不是指向或的符号链接/run/systemd/resolve/stub-resolv.conf。 /usr/lib/systemd/resolv.conf/run/systemd/resolve/resolv.conf (见下文)。

综合纪录

在以下情况下, systemd解析会合成DNS资源记录(RR):

  • 本地配置的主机名将解析为按其作用域排序的所有本地配置的IP地址,或者-如果未配置,则为IPv4地址127.0.0.2(位于本地环回上)和IPv6地址:: 1(即本地主机)。
  • 主机名“ localhost”和“ localhost.localdomain”(以及任何以“ .localhost”或“ .localhost.localdomain” 结尾的主机名)被解析为IP地址127.0.0.1和:: 1。
  • 主机名“ _gateway”解析为所有当前默认路由网关地址,按其度量标准排序。这将为当前网关分配一个稳定的主机名,对于独立于当前网络配置状态引用该主机名很有用。
  • 在中定义的映射/etc/hosts将解析为其配置的地址并返回,但它们不会影响非地址类型(如MX)的查找。

协议和路由

根据以下规则,查找请求将路由到可用的DNS服务器,LLMNR和MulticastDNS接口:

  • 特殊主机名“ localhost”的查找永远不会路由到网络。(其他一些特殊域的处理方式也相同。)
  • 使用LLMNR协议,将单标签名称路由到所有能够进行IP多播的本地接口。仅通过IPv4上的LLMNR发送对IPv4地址的查找,而仅通过IPv6上的LLMNR发送IPv6地址的查找。本地配置的主机名和“ _gateway”主机名的查找永远不会路由到LLMNR。
  • .local使用MulticastDNS协议,将带有后缀“ ”的多标签名称路由到所有能够进行IP多播的本地接口。与LLMNR一样,IPv4地址查找通过IPv4发送,而IPv6地址查找通过IPv6发送。
  • 其他多标签名称将路由到配置了DNS服务器的所有本地接口,如果存在则将路由到全局配置的DNS服务器。从链接本地地址范围进行的地址查找永远不会路由到DNS。请注意,默认情况下,带有.local后缀“ ”的域的查找不会路由到DNS服务器,除非该域被明确指定为DNS服务器和接口的路由或搜索域。这意味着,在.local站点特定的DNS服务器中定义了“ ”域的网络上,需要配置显式搜索或路由域,以使在此DNS域中的查找有效。请注意,今天通常建议避免.local在DNS服务器中定义“ ”,如RFC6762 保留此域供MulticastDNS专用。

如果将查找路由到多个接口,则返回第一个成功的响应(从而有效地合并所有匹配接口上的查找区域)。如果在所有接口上查找失败,则返回最后一个失败的响应。

查找的路由可能会受到配置每个接口的域名和其他设置的影响。有关详细信息,请参见 systemd.network(5)和 resolvectl(1)。以下查询路由逻辑适用于单播DNS通信:

  • 如果要查找的名称匹配(即:等于或具有后缀)的任何链接的任何已配置搜索或仅路由域(或全局配置的DNS设置),则“最佳匹配”搜索/路由-仅确定域:标签最多的匹配域。然后将查询发送到任何链接的所有DNS服务器或与此“最佳匹配”仅搜索/路由域关联的全局配置的DNS服务器。(请注意,多个链接可能配置了相同的“最佳匹配”搜索/仅路由域,在这种情况下,查询将并行发送给所有它们)。
  • 如果查询与任何已配置的仅搜索/仅路由域(既不是每个链接也不是全局)都不匹配,则它将被发送到在“ DNS默认路由”选项集的链接上配置的所有DNS服务器以及全局配置的DNS服务器。
  • 如果没有将链接配置为“ DNS默认路由”,也没有配置全局DNS服务器,则使用嵌入式后备DNS服务器。
  • 否则,查询将失败,因为无法确定合适的DNS服务器。

“ DNS默认路由”选项是可使用resolvectl或在 .network文件中配置的布尔设置。如果未设置,则根据为链接配置的DNS域隐式确定:如果有任何仅路由域(不匹配“ ~.”),则默认为false,否则为true。

实际上,这意味着:为了将所有未与仅搜索/仅路由域配置明确匹配的DNS查询路由到特定链接,请在其上配置“ ~.仅路由” 域。这将确保不会为查询考虑其他链接(除非它们也带有此类仅路由域)。为了仅在没有其他链接可取的情况下将所有此类DNS查询路由到特定链接,请将该链接的“ DNS默认路由”选项设置为true,并且不要~.在其上配置“ 仅路由” 域。最后,为了确保特定链接永远不会收到与任何其配置的仅搜索/路由域都不匹配的DNS流量,请将其“ DNS默认路由”选项设置为false。

有关API 提供的信息,请参阅已解析的D-Bus API文档systemd-resolved

/etc/resolv.conf

支持四种处理方式/etc/resolv.conf(请参阅 resolv.conf(5)):

  • systemd-resolved维护 /run/systemd/resolve/stub-resolv.conf文件以与传统Linux程序兼容。该文件可能是从链接的/etc/resolv.conf。此文件将127.0.0.53 DNS存根(请参见上文)列出为唯一的DNS服务器。它还包含由systemd-resolved使用的搜索域列表。搜索域列表始终保持最新。请注意, /run/systemd/resolve/stub-resolv.conf应用程序不应直接使用,而只能通过的符号链接使用/etc/resolv.conf/etc/resolv.conf为了连接所有绕过本地DNS API的本地客户 端到具有正确搜索域设置的 systemd-resolved,可以对该文件进行符号链接 。建议使用此操作模式。
  • 提供了一个静态文件/usr/lib/systemd/resolv.conf,该文件列出了127.0.0.53 DNS存根(请参阅上文)作为唯一的DNS服务器。/etc/resolv.conf为了将绕过本地DNS API的所有本地客户端连接到 systemd-resolved,可以对该文件进行符号链接 。该文件不包含任何搜索域。
  • systemd-resolved维护 /run/systemd/resolve/resolv.conf文件以与传统Linux程序兼容。该文件可能是从符号链接的,/etc/resolv.conf并且始终保持最新状态,其中包含有关所有已知DNS服务器的信息。请注意文件格式的局限性:它不了解每接口DNS服务器的概念,因此仅包含系统范围的DNS服务器定义。请注意, /run/systemd/resolve/resolv.conf应用程序不应直接使用,而只能通过的符号链接使用/etc/resolv.conf。如果使用此操作模式,则绕过任何本地DNS API的本地客户端也将绕过 systemd-resolved,并将直接与已知的DNS服务器通信。
  • 或者,/etc/resolv.conf可以由其他程序包管理,在这种情况下,systemd-resolved将读取该数据包以获取DNS配置数据。在这种操作方式下, systemd-resolved是该配置文件的使用者而不是提供者。

请注意,此文件的所选操作模式是完全自动检测到的,具体取决于是否 /etc/resolv.conf将符号链接指向/run/systemd/resolve/resolv.conf127.0.0.53或将其列为DNS服务器。

Signals

SIGUSR1

收到systemd-resolvedSIGUSR1过程信号后, 系统会将其维护的所有DNS资源记录缓存的内容以及它从已配置的DNS服务器中学到的所有功能级别信息都转储到系统日志中。SIGUSR2

收到SIGUSR2过程信号 systemd-resolved后,将刷新其维护的所有缓存。请注意,除调试目的外,通常不需要显式地请求此请求,因为无论何时 主机的网络配置发生更改,systemd-resolved都会自动刷新缓存。发送此信号到systemd-resolved等效于resolvectl flush-caches 命令,但是建议使用后者,因为它以同步方式运行。SIGRTMIN+1

收到SIGRTMIN+1过程信号 systemd-resolved时,将忘记它所了解的有关已配置DNS服务器的所有信息。具体来说,会清除有关服务器功能支持的所有信息,并在下一个请求(从功能最全的级别开始)起重新启动服务器功能探测逻辑。请注意,除调试目的外,通常无需显式请求此请求,因为在DNS服务器配置更改时, systemd-resolved会自动忘记学习的信息。发送此信号到systemd-resolved等效于 resolvectl reset-server-features 命令,但是建议使用后者,因为它以同步方式运行。

[issue翻译]提议:为CNI支持虚拟机监控程序容器运行时

URL: https://github.com/containernetworking/cni/issues/251

feiskyer
Overview
CNI旨在为Linux上的应用程序容器提供基于通用插件的联网解决方案。今天有许多容器运行时实现。为了将容器网络与主机隔离,其中一些基于Linux网络 命名空间(例如docker,没有lkvm的rkt),而其他的则基于管理程序(例如rkt带有lkvmHyperContainer)。 当前的CNI设计已经支持基于网络名称空间的运行时,但不支持虚拟机管理程序。因此,该提案旨在为CNI添加虚拟机监控程序运行时支持。 当前的CNI设计已经支持基于网络命名空间的运行时,但不支持虚拟机管理程序。因此,该提案旨在为CNI添加虚拟机监控程序运行时支持。
Considerations
网络上的hypervisor和linux网络名称空间之间有很多区别:
- 虚拟机监控程序具有自己的网络栈,无需为虚拟机监控程序创建网络名称空间。相反,CNI应该为管理程序创建一个Tap设备。
- 由于网络是在系统管理程序内部配置的,因此CNI网络插件无法直接在外部配置IP地址。相反,CNI应该准备网络设备(例如,创建网桥并连接tap设备),然后将网络信息(包括设备,IP地址,网关,路由等)传递回运行时,并让运行时完成剩余工作配置工作。
Design
- 为了支持基于管理程序的运行时,应在CNI中进行一些更改:
- 让CNI知道运行时类型( hypervisor 或netns) 为基于 hypervisor 的运行时配置tap设备而非veth对
- 将网络信息传递回运行时

1) 知道运行时类型
在RuntimeConf中添加一个新字段UsesTapDevice, 例如:

type RuntimeConf struct {
    // The ID of the container
    ContainerID string
    // If set, a tap device instead of veth pair should be created
    UsesTapDevice bool
    // The network namespace path. 
    // Optional. Only need if IsHypervisor is not set.
    NetNS       string
    // Name of the interface inside the container. 
    IfName      string
    // Extra arguments
    Args        [][2]string
}

2) 配置tap设备,而不是veth对
这将是网络插件的工作。由于没有网络名称空间,因此网络插件应直接在主机上创建Tap设备。现有插件将被重构以创建用于虚拟机管理程序运行时的tap设备。
网络配置和IPAM可以保持不变,因此可以像以前一样分配容器的IP地址。

3) 将网络信息传递回运行时
Dan已经从#145开始了

feiskyer:CNI不在乎虚拟机监控程序的实现细节,它只是知道运行时基于虚拟机监控程序,并且希望使用Tap设备而不是veth对。容器运行时应将此Tap设备连接到虚拟机监控程序。

lukasredynk :我研究了 #145 ,它在接口更改方面显得更改量很大,添加像“ CNI_VIRT”这样的env并返回tap索引还不够吗?

feiskyer :添加环境可能有效,但不是那么明确。当前所有的cni插件都应该是基于netns的,它需要知道运行时明确是虚拟机管理程序。
仅返回tap索引是不够的,因为我们不希望每个插件都直接与hypervisor交互。取而代之的是,cni将创建的tap设备和相关的IP地址/掩码/网关/dns返回到运行时,并让运行时本身将其配置到虚拟机监控程序中。

lukasredynk : 抱歉,我不确切,是的,我同意。
我正在考虑的方案:

  1. Set CNI_VIRT (optional)
  2. Run plugin (from plugins/main)
  3. Plugin checks if CNI_VIRT set
    • CNI_VIRT not set: no changes in flow
    • CNI_VIRT set: creates tap instead of veth
  4. Plugin executes IPAM plugin (and passes CNI_VIRT if set)
    • CNI_VIRT not set: no changes in flow
    • CNI_VIRT set: only reserves IP and returns information about how to configure iface in VM
  5. Top-most plugin returns:
    • CNI_VIRT not set: no changes in flow
    • CNI_VIRT set: to the usual output would be added additional param "Iface *uint" in types.IPConfig

feiskyer: 确实需要一个新的环境变量(例如CNI_VIRT),但是仅此一个环境变量是不够的:
- 许多外部cni插件都在使用libcni,这当然需要知道运行时是否基于管理程序
- invoke.Args和CmdArgs还需要知道运行时是否基于虚拟机管理程序
顺便说一句,我对IsHypervisor bool不满意,您对此有何建议?也许 Virtualized bool?例如

type RuntimeConf struct {
    // If set, the runtime is based on hypervisor
    Virtualized bool
    ....
}

lukasredynk:我已经开始着手研究可以显示的代码,以进一步推动讨论,但是现在,我已经在pkg / skel / skel.go“ CNI_VIRT”中添加了放入CmdArgs的环境变量列表。 首先,我正在考虑提供ptp和bridge插件的基本实现,但我仍在努力,看来netlink库版本应该受到影响,因为所使用的版本不支持创建tun / tap设备。 感谢您指出invoke.Args,我完全错过了它,我本以为在pkg / skel / skel.go中添加文件就足够了。
关于IsHypervisor bool:也许TunTap bool,默认为false?因为可能会出现这种情况,tap优先于veth,而不与虚拟机管理程序字段相关?

jellonek : 要使用tap设备,您不必使用虚拟化,因此应该使用UsesTapDevice 而不是Virtualized 。

feiskyer: 谢谢。已将提案更新为UsesTapDevice而不是IsHypervisor。

lukasredynk:非常早期且非常WIP的分支,它为ptp插件创建和配置Tap设备:https://github.com/lukasredynk/cni/pull/1/files,这里的大部分更改与更新netlink库有关(供应商的版本不能处理 Tap设备 )。

lukasredynk:我已经使用rkt-kvm进行了测试,并且至少在默认受限网络中有效。

lukasredynk: RFC:应该如何命名接口?我认为它应该与“ veth_”不同,不要混用不同的设备类型,也许是“ tap_”,其中“ *”后缀的生成方式与veth_型接口相同。你怎么看待这件事?

lukasredynk:我更新了PR: 将CNI_VIRT更改为CNI_USE_TAP ;向libcni添加了代码路径;重构tap创建。
唯一缺少的是在netlink存储库中合并挂起的PR。

thockin :我不确定,但是对我来说,这似乎是一个错误的转折。并非所有的CNI插件都将使用veth。感觉就像是在获取内部信息并将其放在外部。您现在使每个网络插件负责了解tap设备吗?
为什么不能在CNI插件中完全完成此操作?我们是否需要在CNI API中提供一些能力以为插件提供线索,我也许可以买单。但总的来说,这对我来说很困难。只是感觉不对。

feiskyer: 是的,该建议将使每个cni插件负责理解tap设备。这是有道理的,因为CNI是所有容器(包括基于管理程序的运行时)的所有容器的通用网络接口。
可以在CNI插件中完全完成此操作 ,但是该插件不再通用。通常,所有内置网络插件(不确定这是否正确,我的意思是这里的插件)应在所有支持CNI的运行时中正常工作。

thockin : 我认为这是一个非常可疑的起点。你不能合理地 希望所有容器供应商都支持这一点。
有人对网络有图表或详尽的解释吗 为虚拟化运行时设置?我想看一个例子 设备链接在一起,以及如何配置IP路由。

lukasredynk : 遵循@jellonek的建议,我已经准备了带有更新的netlink(包括我的更改)的PR(#274),合并之后,我将使用PTP插件对原始PR进行重新设置。

lukasredynk : @thockin CNI插件无法在VM内部设置网络,因为它始终在主机上运行。对于基于systemd-nspawn的容器来说,在主机生成之前先建立网络连接并不是问题,因为主机和容器共享内核空间,但是在VM的情况下,没有直接的方法来创建虚拟接口(它将如何连接到主机上的网络?) ,请通过syscall分配IP地址并设置路由(有效执行CNI的操作),因为在生成VM之前无法执行此操作。系统管理程序也无法将veth设备附加到VM(当前由ptp,bridge和flannel插件创建)。

lukasredynk : 您可以看一下rkt中的网络(在github.com/coreos/rkt/networking:networking.go和kvm.go中):当前实现对nspawn容器使用CNI,对于基于VM的容器,使用自定义路径(使用CNI代码库)设置tap,获取路由,获取IP并将此信息传递回虚拟机监控程序(tap设备名称, 通过cli )。还创建了systemd单元文件,VM的systemd使用该文件来设置所有网络。实际上,所有插件均能通过这种“野路子”支持,但是会a)部分复制了CNI功能 b)使其难以维护。
集装箱供应商对此有何担忧?选择加入创建tap。在将特定的可选标志传递给CNI之前,它们将像以前一样工作。实际上,对于希望通过CNI处理网络配置并且还需要针对特定​​情况需要基于tap的网络的项目而言,这是很大的收获。

jellonek: 老实说-并非所有插件(ipvlan 不支持)。将这些代码从rkt移到cni 仍然可以解决很多问题-首先消除了提到项目上的代码重复,其次-为其他基于VM的运行时(例如HyperKube或vocker)提供了相同的功能。 而且,这还提供了在容器启动之前配置网络,并在结束后在其他网络上重用它的可能性。

thockin:明确地说-我理解为什么这对于超虚拟化运行时更好。我比较关注的是API的丑陋性以及现有驱动程序的想法:应该实现两种模式。只是感觉不对。
如果我有一个可以处理OVS的CNI插件-我可以将Tap设备链接到我的 OVS 设备中吗 ?
我可以在Calico上使用tap设备吗? Weave ? Contiv 呢?
为什么这比一组明确支持"仅tap设备"的新CNI插件更好 ?是“需要开放的FD”问题吗?

feiskyer : @thockin创建水龙头已启用。现有的驱动程序可以像今天一样选择仅支持基于netns的容器。你能解释为什么它很丑吗?
当然可以支持OVS 。只需稍作改动即可:连接到容器时,创建分接设备而不是veth对。
如果Calico / Weave / Contiv添加了对tap设备的支持,则也是如此。

feiskyer:
1) 减少代码重复 :
- 一个二进制和代码库都可以
- 网络插件可以执行许多步骤来设置网络,例如分配IP地址,创建网桥,设置iptables规则,设置隧道,将网桥连接到容器(通过veth对或Tap设备)。只有最后一步是不同的。两者的所有其他步骤完全相同。
2) 扩展CNI的范围,因此它可以支持所有类型的运行时,无论是netns还是hypervisor。 (否则,我们可能需要另一个专用于Tap设备的CNI)
3) 切换运行时时具有一致的用户体验,因此用户无需重写新插件即可与现有网络基础架构集成。

lukasredynk: 并且只有以下插件是受此变更集影响 :

  • ptp
  • bridge
  • macvlan
  • flannel (because internally wraps bridge plugin)

一些来自主要的CNI存储库。如果外部插件希望支持创建tap,则可以,但这不是强制性的。 AFAIK Calico仅使用ipam进行IP管理(单独管理veth),我不确定Weave,但快速浏览他们的文档后,情况似乎是这样。

thockin :您正在详细说明:
网络设备的特定类型并且使其成为API的一部分。一旦支持,就没有根据了 拒绝下一个不同的想法,而您的APi变成 混乱的条件和可选的if字段。有优雅和 简单到不透明。这感觉不是最简单的 可能的解决方案。
我们可以做一些管理程序存在于网络中的事情吗? 主机os)和net插件在所有情况下都是相同的,并委托 虚拟机管理程序的复杂性仅在管理程序中出现?
MacVLAN? IPVLAN?我的意思是您已经强迫用户 考虑他们的插件是否支持特定的操作模式 。 为什么将其作为API的一部分。
我的观点是,tap是一种非常特殊的技术。立刻 更好的东西来了,此API就过时。可能是一样的 说到netns(实际上,libnetwork甚至不公开netns,如果我 回想一下),但那是一个较低的水平,因此对我来说风险较小。
但实际上他们确实有不同的插件。它可能会使用80% 相同的代码,但是其行为和执行方式有所不同,因此它 是不同的。

thockin : 用户也可以针对不同的运行时使用相同的配置。

rosenhouse : 不要堆得太多,但我还会问我们如何计划在CI系统中测试这种虚拟机监控程序支持? Travis允许我们创建netns并在这些netns中执行插件。是否可以使用CI环境来行使管理程序代码路径?

squeed : 与其让“ ADD”命令具有两种相当不同的语义,不如在规范中添加一个附加命令?诸如“ CONFIGURE”之类的东西,它通过一个已经初始化的接口(例如,由管理程序创建tap)来由CNI插件配置?

jellonek:这将要求管理程序在调用CNI插件之前运行(这与kvm风格的rkt的当前实现的方式非常相似)。 使用当前的建议(以及  #271 中的初始实现),您可以从kubernetes网络准备过程中运行,然后将结果传递给任何基于虚拟机监控程序的运行时(这可能是kvm风格的rkt,hyperd或其他我现在正在工作的东西; ))。
仍然有可能通过网络设备(可以准备veth / tap / macv(lan | tap))作为附加的CNI“主”插件似乎很容易实现。现有的插件也可以重用它,就像它们已经在调用IPAM插件一样。
这样,我们将拥有像这样的链:
- 准备接口(可以通过插件或外部事物完成),该接口调用:
- 在调用特定设备的设备上分配ipv4 / ipv6所需的配置(地址/路由/ iptables) ,该接口调用:
- IPAM
实际上,前两个步骤在主要插件中组合在一起。 如果有人对此感兴趣-我们可以讨论这个问题,但是我看来在另外一个问题上。

翻译声明:并不保证翻译的质量,只是看都看了,顺便把零散的片段整理起来,也能够帮助同样需要的人罢了。

浙大校园网ZJUWLAN连接后VMWare虚拟机域名解析失败

如题,浙大校园网ZJUWLAN连接后VMWare虚拟机,可以ping通外网,但域名解析失败。

ping 233.5.5.5 // ok

ping www.baidu.com //error

解决方法,修改虚拟机DNS,示例如下:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens33
iface ens33 inet static 
        address 192.168.237.112
        gateway 192.168.237.2
        netmask 255.255.255.0
        network 192.168.237.0
        broadcast 192.168.237.255
        dns-nameservers 10.10.0.21

将dns-nameservers改为10.10.0.21,使用校园网的DNS服务器。

树莓派Raspberry Pi 4连接浙江大学有线网络ZJUVPN后开启AP WiFi热点

首先,树莓派Raspberry Pi 4连接浙江大学有线网络ZJUVPN。之后开启AP 无线网卡热点。

预准备

事后梳理

安装配置

主要有两点,一个是创建热点,都是hostapd,有些工具脚本在其上封装更便捷了。而提供DHCP服务的,有的方案选择的dnsmasq,有的选择dhcpd,有的选择udhcp。

当然,首先需要查看当前无线网卡硬件驱动是否支持AP模式。这一点在linux软AP--hostapd+dhcpd中提到了驱动识别、iwconfig识别、iw识别。

有些背景知识,其中channel信道有2.4G、5G之分,中国地区2.4G channel不超过13,美国不超过11。

我一开始按照浙江大学有线网和树莓派路由器 - 无线热点配置来的,我遇到的问题是,热点只有几秒,就消失了?!反复配都是这样,原以为有些配置项不对,后来走的GitHub create_ap,封装的hostapd,还是这样。才在create_ap一个issue中发现网络稳定性,禁用ipv6,有效。也可能是dnsmasq中dnsserver等地方也要配置ipv6,没配置导致的。

最后,根据使用体验和iperf网络性能测试,树莓派4开启的2.4G WiFi热点性能并不好。实际下载峰值1.3MB/s,感觉只有10M带宽。有待优化。

设置iptables的NAT转发功能,转发给ppp0

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

树莓派Raspberry Pi 4连接浙江大学有线网络ZJUVPN

之前购买了树莓派4,最近有空捣鼓一下。树莓派4有1个千兆网线接口,在浙江大学西溪校区学校宿舍连接校园有线网络需要连接ZJUVPN,网络中心只提供了CentOS amd64的客户端安装包,看来要自己捣鼓一下了。连接有线网络后,可以将无线网卡改为AP模式,开启热点供多设备使用。

希望能帮到有同样需要的同学。记录重要的步骤。

预准备

这里罗列整理了一些零散的材料:

申请IP

微信公众号:浙大学生公寓管理服务中心

登录并选择下面的iHome,选择IP地址申请,需要填一下你的MAC地址。

配置IP地址

  • IP地址
  • 网络掩码
  • 网关
  • DNS地址

连接有线网络

需要安装xl2tpd,后来我才搜到GitHub zjunet - Command Line Scripts for ZJU (VPN / WLAN / DNS),感觉很方便。我原来是按照Gist 浙江大学 VPN 及 ZJUWLAN 网络配置配置的。