简介：面向内网或受限网络环境的 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 两条下载路径

做离线安装，第一步永远是在一台能联网、且系统版本尽量和目标机器一致的机器上，把安装包下载好。这一步没做好，后面全白搭。常见做法分两条路线：红帽系用yumdownloader，Debian 系用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指定输出目录，不写的话文件会散落在当前目录，后面拷贝容易漏。执行完会看到目录里多出两个关键的 rpm：tcpdump-<版本>.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.8

apt-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. 目标机器部署：三种安装方式与验证命令

安装包到了目标机器上，安装动作本身不复杂，但要分清系统类型再动手。红帽系用 rpm，Debian 系用 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*.deb

rpm 的-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 libpcap

ldd是验证利器，它会列出 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. 源码编译路线：没有网络也能从源码包编出 tcpdump

rpm 和 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 -D

tcpdump --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 包时不会主动触发ldconfig，deb 安装更是如此，导致系统搜索不到新装的位置。
• 解决：先跑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 tcpdump，apt 提示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 don't 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 2>&1; then echo "[INFO] RPM-based system detected" rpm -ivh libpcap-*.rpm rpm -ivh tcpdump-*.rpm elif command -v dpkg >/dev/null 2>&1; 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 2>&1; 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 还是源码编译，都能一次搞定。

本文还有配套的精品资源，点击获取