简介本资源是一份全面系统的F5 BIG-IP配置实践指南面向网络工程师、安全运维人员及ADC技术学习者聚焦真实生产环境中设备接入、网络部署、安全加固、负载均衡与应用交付等核心配置任务。文档以结构化目录展开覆盖Console/SSH/Web三种连接方式、L2 VLAN与L3 Self IP配置、直连/非直连/透明模式网络拓扑设计、LDAP/RADIUS认证集成、SSL/TLS卸载、Round Robin/Least Connection等负载算法、Pool与Virtual Server配置、Cookie/Simple会话保持以及配置备份、日志监控等运维要点。资源为1个2.81MB的Word文档.doc内容完整、章节清晰、操作步骤详实适合作为日常配置速查手册或系统性入门学习材料。目前已有1858人学习下载是F5技术栈中少有的中文全场景配置知识点总结型资料。1. F5 BIG-IP 配置手册最全的不是文档堆砌而是把 200 页 PDF 拆成能上手改、能排错、能防翻车的实战路径你手头刚拿到一台新上架的 F5 BIG-IP VEv17.1控制台里全是蓝色菜单和灰色按钮或者你正被生产环境里一个“池成员健康检查总失败但服务器明明通”的问题卡住三天翻遍官方 PDF 却找不到对应场景的排查链路又或者你刚接手前任留下的 12 个 iRule、8 个自定义 monitor、3 套 SSL 策略却连哪个 iRule 正在生效都查不出来——这时候“最全的配置手册”不是指页数最多而是指每个操作背后有明确意图、每条命令可验证效果、每个报错有定位坐标、每次修改留后悔药。本篇不讲“什么是虚拟服务器”不列“所有 GUI 菜单项”只聚焦一线工程师真实高频动作从零配通一个 HTTPS 业务入口、让后端服务真正被探测到、iRule 逻辑不黑匣子、SSL 卸载不掉链、故障时 5 分钟内锁定是 LTM 还是后端的问题。它适合两类人刚考完 F5 CSE 想落地的新人以及被线上策略反复打脸、急需建立确定性操作习惯的老手。全文所有步骤均基于 v16.1–v17.1 主流版本实测参数值标注来源GUI 路径 / tmsh 命令 / REST API 路径拒绝“默认即可”式模糊指引。2. 用 tmsh 在本地跑通 HTTPS 业务入口最小命令集 必设 4 个参数F5 的配置入口有三类Web GUI适合初探、tmsh命令行生产主力、REST API自动化必需。新手常陷在 GUI 里点迷路老手则依赖 tmsh 实现原子化操作与脚本复用。本节以“上线一个带证书卸载的 HTTPS 服务”为锚点给出从创建对象到验证通路的最小可行命令集并解释每个参数为什么不能省、设错会怎样。2.1 创建监听用的虚拟服务器Virtual Servertmsh create ltm virtual /Common/vs_web_https \ destination 192.168.10.100:443 \ ip-protocol tcp \ source 0.0.0.0/0 \ profiles add { \ /Common/tcp { context all } \ /Common/http { context all } \ /Common/oneconnect { context all } \ /Common/clientssl { context clientside } \ /Common/serverssl { context serverside } \ } \ rules { /Common/irule_redirect_http_to_https } \ pool /Common/pool_web_backend \ snat automap \ description HTTPS frontend for web app逻辑说明这条命令一次性创建虚拟服务器vs_web_https绑定 IP:Port、协议、源地址范围、关键 profile 和后端池。注意profiles add是显式添加而非继承避免因 parent profile 变更导致意外行为。参数深挖destination 192.168.10.100:443必须是 BIG-IP 自身监听的 IP不是后端服务器 IP。若该 IP 未在 Self IP 中配置命令会静默失败无报错需先tmsh create net self 192.168.10.100/24 { vlan internal }source 0.0.0.0/0看似宽松实为安全基线——F5 默认放行所有源访问控制应由后续security log profile或iRule细粒度实现而非在此处做 ACLsnat automap强制启用 SNAT否则后端服务器看到的是客户端真实 IP可能触发反爬或日志污染automap表示使用 BIG-IP 的自动生成 SNAT 地址池比none更安全rules { ... }iRule 名必须已存在否则虚拟服务器创建成功但规则不加载需tmsh list ltm rule /Common/irule_redirect_http_to_https验证。2.2 配置 clientssl profile证书卸载的核心开关tmsh create ltm profile client-ssl /Common/clientssl_web \ defaults-from /Common/clientssl \ cert /Common/cert_web_f5 \ key /Common/key_web_f5 \ chain /Common/chain_web_intermediate \ secure-renegotiation require-strict \ options replace { no-tlsv1.0 no-tlsv1.1 } \ serverssl-use-sni disabled逻辑说明clientsslprofile 控制客户端到 BIG-IP 的 TLS 握手行为。此处基于/Common/clientssl模板新建覆盖关键字段。cert/key/chain必须是已上传的文件对象非路径字符串否则tmsh load sys crypto会报file not foundsecure-renegotiation require-strict强制重协商安全模式防 CVE-2009-3555options replace显式禁用老旧 TLS 版本比inherit更可控。参数深挖serverssl-use-sni disabled当后端是单 IP 多域名SNI 场景时才需启用普通直连后端无需开启开启反而增加握手延迟cert和key必须配对且私钥不能带密码F5 不支持密码保护密钥可用openssl rsa -in key_encrypted.pem -out key_decrypted.pem解密chain字段填中间证书intermediate CA非根证书root CA——填错会导致浏览器提示“证书不可信”但 BIG-IP 日志无明显报错需用openssl s_client -connect 192.168.10.100:443 -showcerts抓包验证证书链完整性。2.3 创建后端池Pool与健康检查Monitortmsh create ltm pool /Common/pool_web_backend \ members add { 10.1.1.10:443 { connection-limit 0 rate-limit 0 ratio 1 priority-group 0 } } \ monitor /Common/https_monitor_web tmsh create ltm monitor https /Common/https_monitor_web \ defaults-from /Common/https \ interval 10 \ timeout 31 \ recv HTTP/1.1 200 \ send GET /health HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n逻辑说明池成员10.1.1.10:443是后端真实服务地址monitor指向自定义 HTTPS 监控。recv和send构成一次完整探测闭环发送 GET 请求期待返回含HTTP/1.1 200的响应体。参数深挖interval 10探测间隔 10 秒过短如 3 秒易被后端限流误判为宕机过长如 60 秒故障发现慢timeout 31必须 interval否则探测未完成即超时推荐设为interval * 3 1recv HTTP/1.1 200匹配响应状态行非响应体。若后端返回HTTP/1.1 200 OK此正则仍匹配但若返回HTTP/1.1 200后紧跟换行符需写成recv HTTP/1.1 200.*send中Host头必须与后端实际要求一致如 Nginx 的server_name否则返回 404 导致池成员被标记 down。3. iRule 逻辑不黑匣子用 3 行代码看清流量走向iRule 是 F5 最强大也最易翻车的功能。新手常把 iRule 当万能胶水结果策略叠加后行为不可预测老手则靠log local0.打点调试但日志量大时难定位。本节教你用最简方式让 iRule “开口说话”并避开 3 类典型陷阱。3.1 写一个可验证的请求路由 iRulewhen HTTP_REQUEST { log local0. DEBUG: [IP::client_addr] - [HTTP::host][HTTP::uri] if { [HTTP::host] equals api.example.com } { pool pool_api_backend log local0. ROUTE: to api pool } elseif { [HTTP::host] ends_with .admin.example.com } { pool pool_admin_backend log local0. ROUTE: to admin pool } else { pool pool_web_backend log local0. ROUTE: to default web pool } }逻辑说明此 iRule 在HTTP_REQUEST阶段执行根据 Host 头分发流量。关键在于首行log local0.—— 它将客户端 IP、Host、URI 输出到/var/log/ltm是唯一能实时看到“谁、何时、发了什么”的手段。log local0.不影响性能但需确保logging功能启用tmsh modify sys syslog remote-servers add { ... }或本地日志轮转正常。参数深挖log local0.后接字符串支持变量拼接但HTTP::uri包含问号及参数若 URI 含特殊字符如%20日志中会原样显示不影响解析pool命令直接指定池名无需/Common/前缀自动在当前分区查找但若跨分区调用需写全路径ends_with是大小写敏感匹配若需忽略大小写改用string tolower [HTTP::host]转换后再比较。3.2 验证 iRule 是否生效三步定位法确认绑定tmsh list ltm virtual /Common/vs_web_https rules查看规则是否在列表中且顺序正确多规则时按序执行确认启用tmsh list ltm rule /Common/irule_route_by_host中api anonymous字段为true表示已编译false表示语法错误未加载抓日志tail -f /var/log/ltm | grep DEBUG:实时观察请求日志。若无输出说明 iRule 未触发——常见原因是虚拟服务器 profile 中未勾选httpGUI或未在profiles add中包含http { context all }tmsh。避坑iRule 的 3 个血泪经验现象iRule 中HTTP::redirect后页面空白浏览器控制台报ERR_TOO_MANY_REDIRECTS原因重定向 URL 写成https://[HTTP::host][HTTP::uri]而[HTTP::host]返回的是客户端请求的 Host如www.example.com但 BIG-IP 自身监听 IP 是192.168.10.100重定向后浏览器再次请求https://www.example.com若 DNS 未解析到 BIG-IP形成死循环解决重定向 URL 显式写为https://example.com[HTTP::uri]或用HTTP::header replace Location https://example.com[HTTP::uri]现象HTTP::uri获取到的路径含重复前缀如/app/app/login原因虚拟服务器启用了Rewriteprofile 或其他 iRule 已修改 URIHTTP::uri返回的是当前阶段最终值解决用HTTP::request获取原始请求行再用scan提取路径或在HTTP_REQUEST最早阶段用set original_uri [HTTP::uri]缓存现象log local0.日志中出现乱码或截断如DEBUG: 192.168.1.100 - api.examp...原因F5 日志行长度默认限制 1024 字节超长自动截断解决tmsh modify sys db log.maxLineLength value 2048临时扩容或拆分log语句为多行如先 log IP再 log Host4. SSL 卸载不掉链证书链、SNI、OCSP Stapling 三者协同验证SSL 卸载不是“上传证书就完事”。线上常见问题浏览器提示证书无效、移动端白屏、curl 报SSL certificate problem。根源往往不在证书本身而在 BIG-IP 如何组装和传递证书链。本节聚焦三个关键协同点证书链完整性、SNI 服务一致性、OCSP Stapling 生效验证。4.1 证书链组装用 openssl 一行命令验真伪F5 要求cert、key、chain三者严格匹配。但上传后无法直观查看链结构。用以下命令在 BIG-IP 本地验证# 进入 bash 模式需启用 tmsh run util bash # 导出证书链假设 cert 名为 cert_web_f5 cp /config/filestore/files_d/Common_d/certificate_d/:Common:cert_web_f5_12345.crt /var/tmp/cert_full.pem cp /config/filestore/files_d/Common_d/certificate_d/:Common:chain_web_intermediate_67890.crt /var/tmp/chain.pem cat /var/tmp/cert_full.pem /var/tmp/chain.pem /var/tmp/bundle.pem # 验证链是否完整 openssl verify -CAfile /var/tmp/chain.pem /var/tmp/cert_full.pem # 输出 cert_web_f5.pem: OK 表示链有效 # 若报 unable to get local issuer certificate说明 chain.pem 缺少上级 CA逻辑说明openssl verify是黄金标准。F5 GUI 中的“证书管理”页面只校验格式不校验链有效性只有verify命令能暴露中间证书缺失、根证书未信任等问题。参数深挖CAfile指向中间证书文件不是根证书若 chain.pem 包含多级证书如 intermediate rootverify仍能通过若验证失败用openssl x509 -in /var/tmp/chain.pem -text -noout | grep Issuer\|Subject查看 Issuer 与 Subject 是否衔接下一级的 Subject 应等于上一级的 Issuer。4.2 SNI 服务一致性当多个域名共用一个 VIP若虚拟服务器需支持www.example.com和api.example.com两个域名且各自证书不同必须启用 SNItmsh modify ltm profile client-ssl /Common/clientssl_web \ serverssl-use-sni enabled \ sni-default yes \ sni-require yes # 为每个域名创建独立 clientssl profile tmsh create ltm profile client-ssl /Common/clientssl_www \ defaults-from /Common/clientssl_web \ cert /Common/cert_www \ key /Common/key_www \ chain /Common/chain_www tmsh create ltm profile client-ssl /Common/clientssl_api \ defaults-from /Common/clientssl_web \ cert /Common/cert_api \ key /Common/key_api \ chain /Common/chain_api # 在虚拟服务器中绑定 SNI 映射 tmsh modify ltm virtual /Common/vs_web_https \ profiles replace-all-with { \ /Common/tcp { context all } \ /Common/http { context all } \ /Common/clientssl_www { context clientside sni-host www.example.com } \ /Common/clientssl_api { context clientside sni-host api.example.com } \ }逻辑说明sni-host将域名与 profile 绑定BIG-IP 根据 TLS 握手时的 SNI 扩展选择对应证书。sni-default yes表示无 SNI 时回退到默认 profile此处为clientssl_wwwsni-require yes强制客户端必须发送 SNI现代浏览器均支持可防降级攻击。参数深挖sni-host值必须与客户端实际发送的 SNI 完全一致区分大小写、无端口可用tshark -i management -Y tls.handshake.extensions_server_name -T fields -e tls.handshake.extensions_server_name抓包确认若sni-require yes但旧设备不发 SNI连接直接拒绝TCP RST此时应设为no并用 iRule 兜底。4.3 OCSP Stapling 生效验证让浏览器秒判证书状态OCSP Stapling 可加速证书吊销检查。启用后需验证是否真正生效# 启用 stapling在 clientssl profile 中 tmsh modify ltm profile client-ssl /Common/clientssl_web \ ocsp-stapling enabled \ ocsp-auth-cache-timeout 3600 \ ocsp-auth-resp-timeout 10 # 验证 stapling 是否返回 openssl s_client -connect 192.168.10.100:443 -status -servername www.example.com 21 | grep -A 10 OCSP response # 若输出含 OCSP Response Status: successful (0x0) 且 This Update 时间在 1 小时内表示 stapling 生效逻辑说明ocsp-stapling enabled开启功能ocsp-auth-cache-timeout设缓存有效期秒ocsp-auth-resp-timeout设向 OCSP 服务器请求超时。关键验证点是openssl s_client的-status参数它模拟浏览器发起 OCSP 查询。参数深挖若openssl输出OCSP response: no response sent说明 BIG-IP 未获取到 OCSP 响应需检查tmsh list sys db ssl.ocsp.auth.enable是否为enabled及tmsh list ltm profile client-ssl /Common/clientssl_web ocsp-auth-*确认配置ocsp-auth-resp-timeout 10过小如 1 秒会导致频繁超时建议 ≥5 秒过大如 30 秒则拖慢首次握手。避坑SSL 配置的 3 个隐形雷区现象浏览器提示“您的连接不是私密连接”但证书显示有效且openssl verify通过原因证书链中缺少中间证书Intermediate CAF5 的chain字段未上传或路径错误导致浏览器无法构建完整信任链解决用openssl s_client -connect IP:443 -showcerts查看服务器实际发送的证书链对比cat cert.pem chain.pem | openssl crl2pkcs7 -nocrl | openssl pkcs7 -print_certs -noout输出是否一致现象iOS 设备访问 HTTPS 页面白屏Android 正常原因iOS 对 TLS 1.3 兼容性敏感若clientsslprofile 中options replace未禁用 TLS 1.2 以下版本而 iOS 客户端强制 TLS 1.3但 F5 版本v16.x对 TLS 1.3 的 OCSP Stapling 支持不完善解决tmsh modify ltm profile client-ssl /Common/clientssl_web options replace { no-tlsv1.0 no-tlsv1.1 no-tlsv1.2 }强制仅 TLS 1.3或升级至 v17.1现象openssl s_client验证 OCSP Stapling 时返回Error parsing OCSP response原因OCSP 响应服务器返回的 ASN.1 结构异常常见于某些私有 CA解决tmsh modify ltm profile client-ssl /Common/clientssl_web ocsp-auth-ignore-error enabled忽略解析错误继续提供 stapling 服务风险可控因主证书链仍有效5. 故障排查5 分钟内锁定是 LTM 还是后端的问题线上告警“用户反馈网页打不开”。你登录 BIG-IP看到虚拟服务器状态Enabled池状态Available池成员状态Up……但用户就是连不上。此时必须快速切分问题域是 F5 没收到请求F5 收到了但没转发还是后端收到了但返回了错误本节给出一套标准化排查路径每步耗时 ≤1 分钟。5.1 第一步确认请求是否抵达 BIG-IPLTM 入口层# 查看虚拟服务器统计实时计数 tmsh show ltm virtual /Common/vs_web_https statistics # 关键字段解读 # Clientside bits In/Out客户端侧收发字节数若为 0说明请求根本没到 BIG-IP防火墙拦截、DNS 解析错、客户端网络问题 # Current Connections当前连接数若为 0 但 Clientside bits In 0说明连接建立后立即断开如 TLS 握手失败 # RequestsHTTP 请求数若为 0 但 Current Connections 0说明 TCP 连接建立但未发 HTTP 请求客户端卡住操作指引若Clientside bits In为 0立刻跳转检查客户端网络ping 192.168.10.100、DNSnslookup www.example.com、防火墙策略BIG-IP 的net firewall规则或上游设备 ACL。不要在 F5 内部浪费时间。5.2 第二步确认请求是否被正确转发LTM 转发层# 查看池成员统计确认是否转发出去 tmsh show ltm pool /Common/pool_web_backend members # 关键字段解读 # Cur Sessions当前会话数若为 0 但虚拟服务器 Current Connections 0说明 LTM 未选择任何成员健康检查失败、负载均衡算法异常、池为空 # Serverside bits In/Out服务端侧即后端收发字节数若为 0 但 Cur Sessions 0说明连接建立但无数据交互后端进程僵死、端口监听异常 # 进阶抓取 LTM 侧 TCP 流量确认转发行为 tmsh run util tcpdump -i internal -nn -s 0 -w /var/tmp/ltm_forward.pcap host 10.1.1.10 and port 443 # 下载 pcap 后用 Wireshark 分析是否有 SYN → SYN-ACK → ACK 三次握手是否有 TLS Client Hello操作指引若Serverside bits In为 0但Cur Sessions 0立即登录后端服务器netstat -tuln | grep :443确认端口监听状态若监听正常tcpdump -i lo -nn port 443看是否有流量到达 loopback 接口。5.3 第三步确认后端响应是否被正确处理LTM 响应层# 查看 HTTP 统计确认响应内容 tmsh show ltm virtual /Common/vs_web_https http-statistics # 关键字段解读 # HTTP RequestsLTM 收到的 HTTP 请求数同 5.1 中 Requests # HTTP ResponsesLTM 发送给客户端的 HTTP 响应数若远小于 Requests说明后端返回非 HTTP 响应如 RST、空包或 LTM 丢弃了响应 # HTTP 5xx ErrorsLTM 记录的 5xx 错误数若此值高说明后端返回了 5xx但客户端看到的是连接超时因 LTM 未透传 5xx # 查看具体错误定位 5xx 来源 tmsh show ltm pool /Common/pool_web_backend members detail | grep -E (Status|Reason) # 若显示 Down: Monitor failure说明健康检查失败但虚拟服务器仍接收请求因 monitor 是异步探测操作指引若HTTP Responses≈HTTP Requests但用户看到空白页用curl -vk https://192.168.10.100看是否返回HTTP/2 200或HTTP/1.1 503若返回 503检查tmsh list ltm monitor中该 monitor 的recv是否匹配后端实际响应。避坑故障排查的 3 个致命惯性现象tmsh show ltm virtual ... statistics中Clientside bits In持续增长但HTTP Requests为 0原因客户端发起的是非 HTTP 流量如 WebSocket 握手未完成、TCP 扫描包或虚拟服务器 profile 中未启用httpprofile导致 LTM 不解析 HTTP 层解决tmsh list ltm virtual /Common/vs_web_https profiles确认http在列表中且context all若为 WebSocket需启用websocketsprofile现象tmsh show ltm pool ... members显示池成员Up但Serverside bits In为 0原因SNAT 未启用snat none后端服务器路由回包时直接发给客户端 IPBIG-IP 无法捕获响应形成单向流量解决tmsh modify ltm pool /Common/pool_web_backend snat automap现象curl -vk返回SSL certificate problem: unable to get local issuer certificate但openssl verify通过原因curl 使用系统 CA 证书库而 F5 的chain未包含 curl 信任的根证书或clientsslprofile 中ca-file未设置仅用于服务器验证不影响客户端解决curl --cacert /var/tmp/bundle.pem -vk https://192.168.10.100指定完整证书链验证6. 把配置变成可审计、可回滚、可批量的工程化实践配置手册的终点不是“能跑通”而是“能管住”。我见过太多团队一人离职整套 F5 策略无人敢动一次紧急发布因参数微调引发全站 SSL 故障每月安全扫描手工核对 200 个证书过期日。本节分享我在某金融客户落地的 3 个硬核习惯不依赖额外工具纯用 F5 原生能力。6.1 用 UCS 归档 Git 管理每次变更都是可追溯的 commitF5 的 UCSUnified Configuration Snapshot是完整配置快照但默认不记录变更人、原因。我们将其与 Git 结合# 每日自动备份加入 crontab 0 2 * * * /usr/bin/tmsh save sys ucs /var/local/ucs/$(date \%Y\%m\%d_\%H\%M\%S).ucs # 备份后自动提取关键配置片段供人工 review /usr/bin/tmsh list ltm virtual /var/local/config/virtuals.txt /usr/bin/tmsh list ltm pool /var/local/config/pools.txt /usr/bin/tmsh list ltm rule /var/local/config/rules.txt # 将 /var/local/config/ 目录推送到内部 Git 仓库每日 commit cd /var/local/config git add . git commit -m Daily config snapshot $(date) git push效果当某天vs_web_https突然 503git blame virtuals.txt3 秒定位到是 2 天前某次 commit 修改了pool名称git diff HEAD~3 virtuals.txt直观看到变更差异。UCS 文件本身不进 Git太大但文本摘要足够支撑 90% 的回溯需求。6.2 用 tmsh script 实现参数化部署告别复制粘贴针对多环境dev/staging/prod配置写一个可传参的 tmsh script# /var/tmp/deploy_vs.tcl proc script::run {} { set vs_name [tmsh::get_arg vs_name vs_default] set dest_ip [tmsh::get_arg dest_ip 192.168.10.100] set dest_port [tmsh::get_arg dest_port 443] set pool_name [tmsh::get_arg pool_name pool_default] tmsh::create ltm virtual /Common/$vs_name \ destination $dest_ip:$dest_port \ ip-protocol tcp \ profiles add { /Common/tcp { context all } /Common/http { context all } } \ pool /Common/$pool_name \ snat automap log local0. INFO: Virtual server $vs_name created for $dest_ip:$dest_port } # 执行传参 tmsh run /var/tmp/deploy_vs.tcl vs_name vs_web_staging dest_ip 192.168.20.100 pool_name pool_web_staging效果开发环境用dest_ip 192.168.10.100预发环境用192.168.20.100生产环境用192.168.30.100只需改参数脚本逻辑零修改。tmsh::get_arg提供健壮的参数默认值避免因漏传参数导致命令失败。6.3 用 iHealth 自动预警证书过期、配置漂移、CVE 匹配F5 iHealth 是免费服务但多数人只用它上传日志。我们启用其主动监控证书监控在 iHealth Portal 中添加设备自动扫描/Common/下所有证书提前 30 天邮件预警过期配置漂移检测iHealth 每周比对当前配置与上次快照生成Configuration Drift Report标红显示clientsslprofile 中options被手动修改的项CVE 匹配上传 UCS 后iHealth 自动匹配已知漏洞如 CVE-2023-46747并给出修复建议升级到 v17.1.1 或临时缓解措施。效果安全团队每月收到一份 PDF 报告不再需要登录每台设备tmsh list ltm profile client-ssl手工查证书运维人员收到邮件“clientssl_web的options字段与基线不一致请确认是否为预期变更”。最后说一句掏心窝的话所谓“最全的配置手册”从来不是堆砌所有参数的字典而是帮你建立一种肌肉记忆——看到一个报错脑中自动浮现排查树写一条命令手知道哪些参数必须核对改一处配置心里清楚下游影响面。我坚持在每台新交付的 BIG-IP 上运行那套 UCSGit 脚本不是为了炫技是给自己留一条退路当深夜告警响起我能闭着眼敲出git checkout HEAD~1而不是在黑暗中祈祷“应该没改错吧”。希望帮到你。本文还有配套的精品资源点击获取
