简介面向内网或受限网络环境的 tcpdump 离线安装包专为运维工程师、网络管理员及测试人员提供一套免联网部署方案。tcpdump 是 Linux 下经典的网络封包分析工具可实时截取并解析 TCP、UDP、ICMP 等协议数据包广泛应用于网络故障定位、性能瓶颈分析、入侵检测和协议学习该离线包解决了无外网环境下的依赖获取难题可在 CentOS/RHEL 7 系列系统上直接安装使用。压缩包整体仅 543KB共包含 3 个文件主要内容为 tcpdump 与 libpcap 两个 RPM 包以及一个自动安装脚本用户解开压缩包后执行脚本即可完成依赖检查、安装与基础配置无需手动介入。目前已有 1963 人学习下载证明其在实际运维场景中的参考价值。借助这份资源读者既能快速搭建 tcpdump 抓包环境也能借 RPM 包与脚本逻辑理解 tcpdump 和 libpcap 的依赖关系为后续开展网络监控、安全审计与深度协议分析奠定扎实基础。1. tcpdump 离线安装先搞清楚它到底卡在哪一步一台内网机器出了网络故障你登录上去想抓个包看看敲tcpdump -i eth0结果 shell 直接告诉你command not found。更麻烦的是这台机器不在任何可用源里yum install或apt install全都超时。这就是 tcpdump 离线安装要解决的典型场景——不是不会装而是没有网络装不上。tcpdump 本身只是一个几百 KB 的二进制文件真正的难点在它的依赖 libpcap。tcpdump 抓包靠的就是 libpcap 这套用户态抓包库没有它tcpdump 连网卡都打不开。所以做 tcpdump 离线安装本质上是在做一件事在没有外网的目标机器上把 tcpdump 和 libpcap 这两个东西以及它们各自依赖的运行库完整地带进去。这篇笔记覆盖三种常用路线rpm/deb 离线包、源码编译、静态编译顺手把统信 UOS、麒麟这类国产系统上常见的坑也一并写清楚。2. 在有网机器上备齐安装包rpm 与 deb 两条下载路径做离线安装第一步永远是在一台能联网、且系统版本尽量和目标机器一致的机器上把安装包下载好。这一步没做好后面全白搭。常见做法分两条路线红帽系用yumdownloaderDebian 系用apt-get download。两条路线的核心逻辑都是同一个不只下 tcpdump 本体还要把它的依赖 libpcap 一起拉下来。2.1 用 yumdownloader 在联网机器上拉取 tcpdump 与 libpcap 的 rpm 包yumdownloader 是yum-utils包里的工具专门用来只下载不安装。在联网的 CentOS / Rocky / 麒麟arm64 或 x86_64机器上先确保 yum-utils 已安装# 确认系统版本目标机器的发行版和架构必须和这台机器一致或兼容 cat /etc/redhat-release uname -m # 安装 yum-utils只有第一次需要联网 yum install -y yum-utils # 创建存放 rpm 包的目录 mkdir -p /opt/tcpdump-offline cd /opt/tcpdump-offline # 下载 tcpdump 及其全部依赖 yumdownloader --resolve --destdir/opt/tcpdump-offline tcpdump这里--resolve是核心参数它的作用是让 yumdownloader 自动解析 tcpdump 的依赖树把依赖包一起下载到指定目录。--destdir指定输出目录不写的话文件会散落在当前目录后面拷贝容易漏。执行完会看到目录里多出两个关键的 rpmtcpdump-版本.rpm和libpcap-版本.rpm。2.2 用 apt-get download 为 Debian/Ubuntu 及统信 UOS 准备 deb 包Debian 系的操作不一样apt-get download只下载你指定的包不会自动拉依赖需要配合apt-cache depends手动确定依赖列表。统信 UOS 基于 Debian命令同样通用# 在联网的 Debian/Ubuntu/统信 UOS 机器上执行 mkdir -p /opt/tcpdump-offline-deb cd /opt/tcpdump-offline-deb # 先查 tcpdump 的依赖确认有哪些是需要一起下载的 apt-cache depends tcpdump # 下载 tcpdump 本体 apt-get download tcpdump # 根据上一步的输出下载依赖libpcap 是必选其他按版本实际情况 apt-get download libpcap-dev libpcap0.8apt-cache depends的输出里会列出 Depends、Recommends、Conflicts 三类关系我们只需要 Depends 里的包。以 tcpdump 为例通常依赖libc6和libpcap0.8。libc6 是系统自带的基础库目标机器上一定存在不需要带过去真正必须带的是libpcap0.8。这里容易犯的毛病是把 Recommends 的包也全下了白白增加拷贝体积没必要。2.3 用 rpm -qpR 确认依赖避免少拷一个包rpm 包还有一个保险动作在下载完成后、拷贝之前用rpm -qpR查一遍所有 rpm 包的依赖列表和下载目录里的文件做比对确认没有遗漏。# 逐个检查下载的 rpm 包依赖了什么库 cd /opt/tcpdump-offline for rpm in *.rpm; do echo $rpm rpm -qpR $rpm done这个命令会在联网机器上执行作用是读取 rpm 包头部信息里的 Requires 字段列出这个安装包在安装时需要的所有东西。常见输出是libpcap.so.1()(64bit)和libc.so.6()(64bit)这种形式。看到libc.so.6不用管那是 glibc 的符号任何跑得起来的 Linux 系统都有看到libpcap.so.1就必须确认目录里有对应的 libpcap rpm 包。这一步是给后面装包省时间的依赖没备齐到了目标机器上再发现缺文件那才叫真正的翻车。下载完后的文件用tar打包拷走最顺手tar czf tcpdump-offline.tar.gz /opt/tcpdump-offline拷贝方式可以是 U 盘、scp、内网共享目录看现场条件。拷到目标机器后再解压就能进入下一步安装环节了。3. 目标机器部署三种安装方式与验证命令安装包到了目标机器上安装动作本身不复杂但要分清系统类型再动手。红帽系用 rpmDebian 系用 dpkg顺序都是一样的先装 libpcap再装 tcpdump。顺序搞反了rpm 或 dpkg 会直接报依赖错误提示缺少libpcap.so.1。3.1 用 rpm -ivh 与 dpkg -i 安装本地包注意安装顺序先把 tar 包在目标机器上解开然后按依赖顺序安装# 解压离线包 tar xzf tcpdump-offline.tar.gz -C /opt/ # 红帽系 / 麒麟系统先安装 libpcap再安装 tcpdump cd /opt/tcpdump-offline rpm -ivh libpcap-*.rpm rpm -ivh tcpdump-*.rpm # Debian / Ubuntu / 统信 UOS同样先 libpcap 后 tcpdump cd /opt/tcpdump-offline-deb dpkg -i libpcap0.8*.deb dpkg -i tcpdump*.debrpm 的-i表示安装-v显示详情-h打印进度条普通场景这三个参数够了。如果目标机器的环境变量里缺了默认路径需要加--prefix指定但做离线安装时我一般不建议碰这个参数默认路径最安全因为 tcpdump 启动时会按编译时的路径去找 libpcap。dpkg 的-i是纯安装Debian 系有个好处同一个目录下如果还有没装完的依赖dpkg -i *.deb会按顺序尝试但缺依赖就是缺依赖不会像 apt 一样自动补这一点后面会专门说。3.2 验证 libpcap 是否被系统正确加载装完之后别急着抓包先确认 libpcap 真的被系统找到了。rpm 装完一般会自动运行ldconfig但离线场景下有时候装的是源码编译包或者 deb 包和已有的库版本冲突动态库缓存不会自动刷新# 检查 tcpdump 依赖的动态库是否全部就位 ldd /usr/sbin/tcpdump # 刷新动态链接库缓存 ldconfig # 确认 libpcap 在系统缓存里 ldconfig -p | grep libpcapldd是验证利器它会列出 tcpdump 运行时依赖的所有共享库。正常输出里应该看到libpcap.so.1 /usr/lib64/libpcap.so.1或类似路径而不是not found。如果出现not found说明 libpcap 装了但没进/etc/ld.so.conf的搜索路径跑一次ldconfig刷新缓存基本能解决。这一步是很多离线安装翻车的重灾区——包装了tcpdump 也起来了但一运行就报libpcap.so.1: cannot open shared object file。3.3 用 tcpdump -D 和一次小流量抓包确认工具真正可用验证安装是否成功的最终标准是它能抓包。先看 tcpdump 能不能枚举出网卡再随便抓几个包试试# 列出所有可用的抓包网卡 tcpdump -D # 在 eth0 上抓 5 个包抓完自动退出 timeout 5 tcpdump -i eth0 -c 5 -nn # 后台抓包写文件避免终端阻塞 tcpdump -i eth0 -c 20 -w /tmp/cap.pcap ls -lh /tmp/cap.pcap-D会打印网卡列表和索引输出类似1.eth0 [Up, Running]这种格式。-c 5表示抓到 5 个包就停止-nn不做 DNS 反解也不把端口号转成服务名离线环境下没有 DNS 解析这个参数能少踩一个超时坑。timeout 5是为了防止网卡上长时间没有流量导致命令一直挂在那。看到抓包文件大小不为零说明 tcpdump 安装完整抓包链路通畅这时才算真正装好了。4. 源码编译路线没有网络也能从源码包编出 tcpdumprpm 和 deb 路线的前提是能找到匹配的安装包。但有些场景下这条路走不通目标机器是冷门的 CPU 架构、系统版本太老、或者厂商源里根本没有对应包。这时候退路就是源码编译——在有网的机器上下载 tcpdump 和 libpcap 的源码包拷到目标机器上本地编译。4.1 编译环境预检没有 gcc 一切都白搭源码编译有一个硬性前提目标机器上必须有编译工具链。这一点必须提前查否则拷过去才发现没 gcc那才是真正的黑匣子。# 检查编译工具链是否齐全 which gcc which make gcc --version # 检查内核头文件是否存在libpcap 编译时可能需要 ls /usr/include/linux/if_packet.h如果目标机器上没有 gcc源码编译路线直接放弃回到 rpm/deb 路线或者想别的办法。这也是我通常优先推荐 rpm/deb 路线的原因生产服务器上一般不会装 gcc但离线包里不需要目标机器有编译器。这里提一句跟 linux 离线安装 mysql 是一个逻辑——离线包如果能做到二进制分发就尽量不要让目标机器参与编译少一个工具链就少一排雷。至于为什么有的 tcpdump 在 UOS 上源码编译失败一半以上是头文件路径对不上比如/usr/include/linux/if_packet.h不存在说明内核头文件包没装全。4.2 configure、make、make install 的编译顺序与参数源码编译的顺序是先 libpcap 后 tcpdump。下载源码包时记得同时拿这两个libpcap-版本.tar.gz和tcpdump-版本.tar.gz。版本选择上尽量选时间接近的两个版本比如 libpcap 1.10.x 配 tcpdump 4.99.x这是官方长期维护的组合。# 解压源码包 tar xzf libpcap-*.tar.gz tar xzf tcpdump-*.tar.gz # 编译安装 libpcap cd libpcap-*/ ./configure --prefix/usr make -j4 make install # 编译安装 tcpdump cd ../tcpdump-*/ ./configure --prefix/usr make -j4 make install--prefix/usr指定安装路径这样把可执行文件放到/usr/sbin/、库放到/usr/lib/正好在系统默认搜索路径里。用默认/usr/local也行但之后要确保/usr/local/lib在 ldconfig 搜索路径里否则又得手动配。make -j4是并行编译参数4 表示用 4 个进程同时编译为了压榨多核 CPU。如果目标机器内存小-j2更稳。整个编译过程通常在 5 分钟内结束libpcap 的 configure 脚本会自己探测系统能力比如是否支持 DPDK、是否支持蓝牙抓包等探测失败会自动禁用该功能不会中断编译。4.3 编译完必须跑的三个验证命令源码编译安装完成同样要验证# 查看版本号确认编译成功 tcpdump --version # 确认动态库路径正确 ldd /usr/sbin/tcpdump # 列出网卡确认能正常打开抓包接口 tcpdump -Dtcpdump --version的输出会同时打印 tcpdump 和 libpcap 的版本号比如tcpdump version 4.99.4和libpcap version 1.10.4。如果打印了版本号但ldd显示libpcap.so.1 not found那就是编译时候 libpcap 安装到了/usr/local/lib但系统的 ld 缓存没有刷新。别急着重新编译先跑ldconfig大部分情况下动态库缓存更新后就正常了。如果还不行检查/etc/ld.so.conf是否包含/usr/local/lib手动加上再跑ldconfig。5. tcpdump 离线安装避坑手册现象、根因、对策离线安装 tcpdump十个有九个栽在依赖问题上。这一章把最常见的几个坑按「现象 → 原因 → 解决」三件套拆开都是我实际处理过或者反复见过的场景。5.1 安装后运行报 libpcap.so.1 not found现象rpm -ivh tcpdump-*.rpm装完执行tcpdump -D报error while loading shared libraries: libpcap.so.1: cannot open shared object file。原因libpcap 装了但动态链接库缓存没有刷新。rpm 安装 deb 包时不会主动触发ldconfigdeb 安装更是如此导致系统搜索不到新装的位置。解决先跑ldconfig如果问题还在用find / -name libpcap.so*找库文件装在哪个目录确认该目录写进/etc/ld.so.conf或在默认搜索路径内。我在离线安装时习惯装完所有包后统一跑一次ldconfig养成习惯后这个问题基本绝迹。5.2 rpm 安装时提示依赖缺失直接 --nodeps 硬装现象执行rpm -ivh tcpdump-*.rpm时提示libpcap.so.1()(64bit) is needed by tcpdump-...终端上一行行红字看起来非常慌。原因极大概率是离线包里漏了 libpcap 的 rpm 包或者 libpcap 的版本和 tcpdump 的期望不匹配。还有一种情况是 libpcap 用 deb 包方式装了但 rpm 元数据里认不到这个文件。解决用rpm -qpR tcpdump-*.rpm在联网机器上查依赖清单确认缺什么补什么。坚决不要用rpm -ivh --nodeps强装。--nodeps只是跳过依赖检查动态库缺失的问题不会消失装完 tcpdump 还是跑不起来而且后面排查起来更乱。唯一用到--nodeps的场景是 libpcap 已存在但 rpm 数据库里查不到这种时候优先考虑用rpm -ivh --replacefiles而不是--nodeps。5.3 统信 UOS 和麒麟系统上源里没有 tcpdump 或版本太老现象在统信 UOS 上执行apt-get download tcpdumpapt 提示Unable to locate package tcpdump在麒麟 ky10 上执行yum list tcpdump结果为空。原因国产系统的软件仓库收录范围和 Debian/CentOS 官方源有差异tcpdump 不是总会进默认源。有时候源里只有 libpcap 没有 tcpdump或者 tcpdump 版本停留在两三年前。解决不要在目标系统上纠结去源码编译路线。从 tcpdump 官网下载 tarball在目标机器上本地编译。国产系统本质上还是 Linux 内核gcc 编译没有障碍。如果目标机器没装 gcc就回到 rpm 路线从相邻发行版比如 CentOS 或 openEuler 的源里找对应的 rpm 包再用rpm -qpR检查兼容性。5.4 安装成功但抓包没有权限或者找不到网卡现象tcpdump -i eth0报You dont have permission to capture on that device或者tcpdump -D的输出里根本没有期待中的物理网卡。原因权限问题的根因是当前用户不在抓包允许组里tcpdump 在 Linux 上需要 CAP_NET_RAW 或 root 权限。网卡找不到通常是因为网卡命名规则不同——新的 systemd 系统把网卡命名成enp0s3、ens33不再是eth0。解决权限问题用sudo tcpdump运行或者把用户加入wireshark组再重新登录。网卡名问题先跑tcpdump -D看到实际网卡名再用-i指定。注意离线安装的场景通常也是生产环境不要在抓包命令上使用-p参数关掉混杂模式那样只能抓到本机进出的流量抓不到局域网内其他设备的包。5.5 容器里做的离线包拷到目标机器上架构对不上现象在 x86_64 的容器里用 yumdownloader 做好了 rpm 包拷到一台 ARM 架构的麒麟机器上安装提示Wrong architecture x86_64。原因rpm 和 deb 包头部都写死了架构x86_64 的包不可能装到 aarch64 的系统上。这个坑在混合架构机房和国产化迁移项目里特别常见——k8s 节点里既有 x86 服务器也有 ARM 服务器。解决做离线包之前先在目标机器上跑uname -m确认架构。aarch64 架构必须在 aarch64 的机器或容器里制作离线包。用 docker 离线安装的思路可以救急在有网且架构匹配的机器上拉取对应发行版镜像进容器里做离线包再把包导出。这个方法本质是把有网机器的环境搬到跟前但架构必须是同一套。6. 进阶把离线安装做成一条命令顺带掌握静态编译如果你的环境里要装 tcpdump 的机器不止一台手动敲命令就没效率了。这里分享两个进阶做法一是把安装流程写成一个 install.sh跑一遍就完事二是做静态编译编出一个不依赖任何动态库的单文件 tcpdump彻底告别依赖问题。6.1 写一个 install.sh 脚本自动适配 rpm 与 deb 两种系统脚本的核心是判断系统类型然后走对应的安装分支。这个脚本跟随离线包一起拷贝到目标机器上。#!/bin/bash # tcpdump 离线安装脚本 # 判断系统使用哪种包管理器 if command -v rpm /dev/null 21; then echo [INFO] RPM-based system detected rpm -ivh libpcap-*.rpm rpm -ivh tcpdump-*.rpm elif command -v dpkg /dev/null 21; then echo [INFO] DEB-based system detected dpkg -i libpcap*.deb dpkg -i tcpdump*.deb else echo [ERROR] No rpm or dpkg found, switch to source compile exit 1 fi # 刷新动态库缓存 ldconfig # 验证安装 if tcpdump -D /dev/null 21; then echo [OK] tcpdump installed successfully else echo [FAIL] tcpdump cannot run, check ldd output ldd /usr/sbin/tcpdump fi脚本的逻辑很直接command -v rpm判断红帽系command -v dpkg判断 Debian 系两个都没有就提示转源码编译并退出。最后的验证段用tcpdump -D作为探测命令能列出网卡说明安装和动态库都正常。注意脚本必须在离线包所在目录运行因为*.rpm和*.deb用的是相对路径匹配。如果你有十几台机器要装把这个脚本和离线包一起放到内网共享目录每台机器wget下来跑一遍比手工敲命令省一小时。6.2 编译一个静态链接的单文件 tcpdump静态编译更绝——把 libpcap 直接编进 tcpdump 可执行文件里拷过去就是一个文件不需要任何动态库。# 先静态编译 libpcap cd libpcap-*/ ./configure --prefix/usr --disable-shared make -j4 make install # 再编译 tcpdump链接静态 libpcap cd ../tcpdump-*/ ./configure --prefix/usr --disable-shared make -j4 make install # 验证ldd 输出 not a dynamic executable 就说明静态链接成功 ldd /usr/sbin/tcpdump关键在于--disable-shared它让 configure 不生成.so动态库而是生成.a静态库tcpdump 编译时会把 libpcap.a 直接链接进可执行文件里。ldd的输出如果显示not a dynamic executable那就证明整个文件是静态的拷到任何同架构的 Linux 机器上都能直接跑跟系统里有没有 libpcap 毫无关系。这个单文件 tcpdump 大小大约 1MB 左右比动态链接版本大一些但换来的是一劳永逸的部署体验。我自己的习惯是重要服务器的离线包固定做两个版本一个随系统源的动态链接版一个静态单文件版。动态版用于常规场景静态版用于拿不准系统环境的场景。这些年下来静态编译版救过我太多次而且多花的时间不过十分钟。希望这篇笔记能帮你把 tcpdump 离线安装这条路走顺不管是 rpm、deb 还是源码编译都能一次搞定。本文还有配套的精品资源点击获取