访客投屏的网络边界与接入设计：独立链路、输码验证与容量测算
先说结论
接待场景里的投屏，技术含量不在"怎么投"，而在"让谁连进来"。把公司WiFi密码递给访客，等于把内网入口开给了外来设备；让访客装客户端，管理员权限、软件兼容、卸载残留全是麻烦。多数接待卡壳，都是把内部办公的连接习惯硬套在了临时设备上。
结论一句话：访客投屏要走独立链路——会议室的无线投屏自成独立网络，点对点直传大屏，访客设备从物理链路上就进不了公司内网；投屏门槛用可选开启的输码验证解决。本文把这条链路的隔离原理、验证机制、容量账和落地脚本一次讲清。
访客设备为什么不能进公司内网
先对齐风险模型。访客笔记本、手机是典型的不可信终端：系统补丁状态未知、装过什么没人知道、网络配置不受控。让这类设备接入办公VLAN，哪怕只开访客SSID，也要面对横向探测、ARP干扰、蹭网下载三件套；而接待场景的真实需求只有一条——把屏幕内容投到大屏上，仅此而已。
把三件套摊开看：横向探测，是访客设备拿到内网地址后顺手扫一遍网段，文件服务器、打印机、监控主机全部暴露在扫描范围内；ARP干扰，是不可控终端发广播包污染地址解析，轻则同事网速变慢，重则内网短暂异常；蹭网下载，是访客把会议室当办公网用，大文件占满出口带宽，白天开日销会的团队最受不了。三个风险都不算低频，而接待需求本身又只有"投屏"一件事——用开放内网换一次投屏，代价和收益完全不成比例。
需求收敛之后，网络边界就可以画得很干净：访客设备需要的不是"进网络"，而是"到屏幕"。谁能提供这条最小链路，谁就该承担访客接入的角色。会议室投屏方案里的接收器恰好就是这个角色：自己管接入、自成独立网络、自己把画面送上屏，全程不需要房间里的任何网络设备参与。
独立网络的隔离原理
投屏链路是独立网络：访客设备与接收器点对点直连，网内只有接收器和大屏这条链路。它不桥接房间AP、不向上联出口转发，所以从拓扑上讲，访客设备与公司内网之间根本不存在通路——不是防火墙拦住了，而是路本身没修。
点对点直传带来三个直接结果。第一，访客设备拿不到内网IP，内网的文件服务器、OA系统对它完全不可见；第二，投屏链路的流量不经过房间路由器，网络管理员不需要为访客开任何策略；第三，这条链路不依赖互联网，机房断外网、运营商故障，都不影响访客把方案投上屏。
对IT来说，这个设计把"访客接入"从安全审批项变成了免审批项：链路不存在，风险就不存在。剩下要管住的只有一件事——谁能拿到投屏的资格，这就是下一节的输码验证。
横向对比一下常见的替代方案就更清楚。方案一，访客SSID加 portal 认证：能管住接入，但访客设备已经拿到内网侧地址，横向隔离策略要逐条配置，出了问题排查成本高；方案二，让访客走有线：临时布线、位置受限，会议室桌面上插满线缆，接待观感直接降级；方案三，云中转投屏：画面上传云端再下发，会议内容出了内网，保密评审过不去，而且断外网就瘫痪。相比之下，独立链路是唯一一条"接入即隔离"的路径，不需要任何附加策略就成立。
输码验证：投屏门槛怎么起作用
输码验证的机制很简单：后台开启后，投屏要在屏上输入当前验证码才生效；不开启则选中接收器直接投。验证码只显示在会议室大屏上，人在屏前才拿得到——这把"投屏授权"和"物理在场"绑定在了一起。
它解决两个问题。一是防误投：隔壁会议室的设备，因为没有本屏验证码，投不进来；二是防乱投：谁在投、投什么，陪同人员抬头就看得到，授权是显式的、当面的。访客离场设备断开，连接自然解除，下次来访重新验证，没有残留会话。
和其他授权方式比一比：固定密码，一旦泄露就要全员通知更换，访客走了密码还留着，等于门槛常开；审批加白名单，每次来访都要IT操作，接待节奏被流程拖住；输码验证的码只在屏上、每次会话独立，天然满足"用完即失效"，IT零操作。三类方式里，只有它是把授权成本压到接近零、同时保留在场确认的。
边界也要说清楚：输码验证是接入门槛，不是加密协议。它防的是未经在场确认的误投和串扰，不要把它描述成端到端加密方案。保密等级高的会议室，按内部制度叠加管控，两层措施不冲突。
接入容量：员工与访客一本账
接入容量指接收器同时可待命的设备数。小会议室16台档、大会议室64台档的分级之前讲过，这里补一个接待场景的算法：员工设备与访客设备共用一本账。
测算方式：把每间会议室的"高峰期同时在线设备数"记一周（早中晚各记一次，取峰值上浮三成），这个数里要包含来访日的访客设备。开日销会、见客户频率高的房间，容量档按保守值选，别让访客来了挤不进接入——接待现场加购是不现实的。
再强调一次两本账：接入台数是池子，同屏画面数是分屏规格（1-9路向下兼容）。访客和员工各投一路画面，走的是画面账；64台待命不等于64路画面，采购需求里两个数分开写。
环境自检与接待台账脚本
投屏跑通后，跑一段自检确认链路状态——链路通、且无外网路径，才说明隔离按预期生效。bash版：
# 访客投屏环境自检：投屏链路验证GW=$(iproute|awk'/default/{print $3; exit}')echo"网关:$GW"ping-c2"$GW">/dev/null2>&1\&&echo"[OK] 点对点链路通，具备投屏条件"\||echo"[FAIL] 链路不通，检查投屏链路"curl-m3-shttps://www.baidu.com>/dev/null2>&1\&&echo"[WARN] 检测到外网访问路径，确认是否连错网络"\||echo"[OK] 无外网路径，投屏链路与公司内网隔离"第一段验证点对点链路（网关就是接收器），第二段验证外网路径不存在——两条都打OK，访客投屏的环境就是干净的。
接待频繁的团队，再配一个登记台账，记录来访接入并监控容量余量。python版：
# 访客接待台账：登记来访接入，监控会议室剩余待命容量importcsv,os CAPACITY={"small":16,"large":64}defremain(room_file,tier):used=0ifos.path.exists(room_file):withopen(room_file,encoding="utf-8")asf:used=sum(1for_inf)returnCAPACITY[tier]-useddefcheckin(room,guest,device,tier="small"):# 登记一条访客接入，容量不足则提示调整f=f"ledger_{room}.csv"left=remain(f,tier)ifleft<=0:returnf"[FULL]{room}待命容量已满，请换会议室或分流"withopen(f,"a",newline="",encoding="utf-8")asfh:csv.writer(fh).writerow([room,guest,device])returnf"[OK]{guest}({device}) 已登记，剩余{left-1}台"print(checkin("301","客户A","iPhone"))print(checkin("301","客户B","Windows笔记本"))台账按会议室分文件，月底一汇总，哪间房接待频率高、容量档要不要上调，数据说话。
接待SOP与离场清理
接待动线三步：访客进门，前台递流程卡片；进会议室，打开投屏就能看到接收器；自助连接、自助投屏，全程不用喊IT。手机和平板走屏幕镜像（AirPlay或Miracast），笔记本向前台接本会议室固定发射器——发射器与接收器首次配对后长期有效，插入按键即投，日常接待零等待。
离场清理更简单：访客设备离场，连接自然解除。要做的只有两件小事——陪同人员确认大屏切回本地信号源（内部资料别留在投屏通道里），前台把发射器收回原位。发射器按"每间固定一套"管理，别让访客带走，跨会议室使用需要重新配对。
边界说明
两点边界。第一，本文的隔离结论建立在"投屏链路不桥接、不转发"的产品形态上，采购前按这个标准核对，别拿开了互联网共享的方案套用。第二，输码验证是接入门槛不是加密手段，保密要求高的房间按制度叠加管控。
接待SOP跑顺之后，访客投屏就从"每次都要救火的事"变成"没人注意到的背景流程"——前台递卡片、访客自助连、陪同看大屏，三步各归其位，IT不用再被会议室召唤。这套流程的维护成本也低：台账每周扫一眼容量余量，发射器按位归位，验证码机制本身没有需要配置的常驻项。
访客投屏配置拿不准的，按会议室规模和来访频率对号入座，拿不准的留言讨论。
