企业官网建设流程全解析

干了几年网络这块的活儿，一直觉得“日志”是个平时没人关注、出事才想起来的东西。尤其是防火墙，ASA也好PIX也好，本机那点buffer根本不够看，流量一大，旧日志直接被新日志冲掉。前几天在GNS3里搭了个实验环境，用PIX搭配Kiwi Syslog做集中日志，整个过程踩了几个不大不小的坑，今天把它完整写出来，希望能给正在折腾GNS3日志方案的朋友省点时间。这套玩法也是老生常谈，但真正从头到尾跑通的人不多，问题不在配置本身，而在链路设计和一些细节处理上。

1. 为什么要让PIX把日志交给Syslog服务器

1.1 防火墙日志不上送，问题出在哪

PIX防火墙自身能产生日志，这一点很多人知道，但也仅仅是知道。实际上PIX内存里能缓存的日志条数非常有限，默认情况下消息队列就那么点空间，级别设得高了容量不够，级别设得低了又什么都记不住。更麻烦的是，一旦设备重启，内存里的日志全部清空。你根本没办法事后回溯“那个时间点到底发生了什么”。

我自己在实验里验证过一次：用默认配置的PIX，不做日志上送，跑一个简单的ping和访问控制测试，几分钟下来再敲show logging，里边的记录已经被新的会话信息覆盖得七零八落。遇到真正需要排查ACL拒绝流量、接口翻转、用户登录失败这类问题的时候，靠PIX本地那点buffer几乎是盲人摸象。

把日志通过Syslog协议转发到独立的日志服务器之后，情况完全不同。日志不再受设备内存限制，可以按时间归档、按主机分类、设置报警，甚至可以导入到日志分析平台做长期留存。这才是防火墙日志的正确用法。

1.2 工具选型的逻辑：为什么是PIX + Kiwi这套组合

选GNS3作为实验环境，是因为它能把真实设备镜像跑起来，和单纯的模拟器比，指令输出、配置语法、报文行为都贴近物理设备。PIX虽然已经是老一代产品，但在GNS3里跑得很稳，而且它和后来ASA的日志架构一脉相承，把PIX的日志链路搞明白，之后再碰ASA基本就是换个型号操作的事。

日志服务器选Kiwi Syslog，主要是看重它部署成本低、对Windows用户友好。一套几台设备、几十条日志的实验规模，免费版完全够用。它的界面就是四个列：时间、来源IP、优先级、消息正文，看起来简单，但做实验和日常中小型环境足够了。后来我还在同一台机器上跑过其他开源方案，折腾成本明显高一截，Kiwi算是“装上就能用”的典型代表。

这套组合的技术关键点是：PIX作为Syslog客户端，把日志消息用UDP 514端口发出去；Kiwi作为Syslog服务器，监听同一个端口并把消息格式化、归档。中间只要网络通、端口通、两台设备的时间大体同步，日志就会像流水一样显示在Kiwi的实时窗口里。

2. GNS3环境准备与网络规划

2.1 让PIX镜像在GNS3里跑起来

在GNS3里加载PIX不像加载普通路由器那么简单。PIX是防火墙设备，本质上跑在QEMU平台上，需要先把PIX的磁盘镜像准备好。我在这次实验里用的是PIX 8.x的镜像文件，格式是解压后的某vmlinuz/initrd组合，或者一个完整的磁盘镜像，具体取决于你手头文件的打包方式。

关键操作是：在GNS3的“编辑”菜单里打开首选项，找到QEMU虚拟机模板，新建一个设备模板，名字随便起一个“PIX515E”之类的，然后把镜像路径指到你的PIX镜像文件。体系结构选择x86或i386，内存给到256MB就够跑了，不需要太多。特别要注意的是，PIX模板的网络接口类型要选对，一般选e1000或者rtl8139，选错会导致启动后接口不识别。

这里分享一个我踩过的坑：创建好模板后，第一次拖进拓扑里如果发现电源指示灯是灰的，或者启动后控制台一直没输出，十有八九是GNS3设置里的QEMU路径有问题，或者镜像权限不对。在Windows上还要注意路径里别有中文和空格，GNS3对这类路径处理起来有时候很别扭。

2.2 一个能落到实处的IP规划

拓扑结构不复杂，但IP规划必须提前设计好，否则后面配置全是乱的。我这次用了最典型的方案：PIX分成inside和outside两个区域，outside接模拟公网/上联区域，inside接内网区域，日志服务器放在inside侧。

具体IP规划如下：

• PIX设备配置两个接口：
  • ethernet0：outside接口，IP地址为 192.168.1.2 / 24，安全级别0。
  • ethernet1：inside接口，IP地址为 10.0.0.1 / 24，安全级别100。
• 日志服务器（Kiwi所在的机器，也就是宿主机）：IP地址为 10.0.0.100 / 24。
• GNS3里的测试终端（VPCS）接在inside区域：IP地址为 10.0.0.10 / 24，网关指向10.0.0.1。

之所以把日志服务器放在inside，是因为inside区域安全级别高，配置简单直接。内网设备访问日志服务器不需要额外做ACL放行，PIX自身的本地流量（比如Syslog）也不会被NAT转换，属于直接通信，链路风险最小。

2.3 Cloud节点打通模拟器与宿主机

这是整个实验里最容易卡住的一环：PIX在GNS3的虚拟网络里，Kiwi在宿主机Windows上，两边怎么互通？答案是用GNS3的Cloud节点。

从设备列表里拖一个Cloud节点进拓扑，双击打开它的配置界面，在“Network”参数里选择一个网卡。如果你像我一样是单机实验，Kiwi和PIX在同一个物理机上，那Cloud就绑定本机的物理网卡或虚拟网卡。这里要特别注意：Cloud节点自身不需要配置IP地址，它只是一个桥接工具，把所有它连接的网络流量转发到实际物理网卡上。

为了让PIX的inside接口能到达宿主机10.0.0.100，我在拓扑里把PIX的ethernet1连接到Cloud节点。由于Cloud绑定的是物理网卡，宿主机又在这个物理网卡上有10.0.0.100这个地址，PIX内的虚拟设备就和宿主机在同一个二层广播域里了。云节点启动后可能要多等几秒，让链路状态从down转成up，我习惯性地在PIX里敲一下show interface确认接口是up状态再继续。

当这个链路打通后，剩下的就是Kiwi和PIX两边配置的事了。很多人卡在这一步，其实只要记住一句话：“Cloud是没有脑筋的网线，它的作用就是把模拟器里的设备接到真实网卡上。”理解到这一层，就通了。

3. Kiwi Syslog服务器端的配置要点

3.1 安装与UDP 514监听

Kiwi Syslog Server的安装过程没什么好说的，一路Next就行。装完后第一次启动，它会自动在后台监听UDP 514端口，实时日志窗口会自动弹出。你不需要手动创建什么“接收器”，软件默认就监听所有网卡的514端口。

为了确认监听状态，我习惯在命令行里执行一条命令检查：

netstat -ano | findstr "514"

正常情况下你会看到类似下面这样的输出，说明Kiwi已经在正常监听了：

UDP 0.0.0.0:514 *:* 1024

如果这条命令什么都没输出，那说明Kiwi服务没有在运行，或者被系统服务管理器停掉了。打开服务管理器找到Kiwi Syslog Server服务，确认它的状态是“正在运行”。

3.2 日志归档与查看视图

Kiwi的主界面分成两大块：上面是实时接收的日志列表，下面是消息详情或状态信息。第一次打开可能觉得信息量不大，但只要PIX一发声，列表就会滚动起来。

为了让日志能够持久保存，我建议在Kiwi的“File”菜单里打开Setup配置，找到“Log Archive”选项卡。在归档设置里，可以指定日志保存到本地目录和文件名模板，比如按天生成一个文件，路径类似：

C:\Syslog\archive\2025-01-15.log

归档格式可以选Kiwi自己的格式，也可以选纯文本格式。如果你后续打算写脚本分析日志，纯文本格式更方便，直接拿awk或者PowerShell处理就行。Kiwi提供的实时过滤器也很有用，比如只显示某个IP或某个优先级的日志，排查问题的效率会明显高不少。

我这里要特别说一句：不要嫌归档麻烦。实验里日志量不大，你可能觉得不归档也无所谓。但当你把PIX的loggng trap调到informational级别之后，日志量会迅速膨胀，没有归档就等于在扔证据。

3.3 Windows这边最容易漏的两件事

第一个，也是最大的坑：Windows防火墙默认会拦截UDP 514入站。Kiwi监听了514端口没有用，Windows防火墙在系统层面把包丢掉，日志就是进不来。解决办法有两种，一种是在防火墙高级设置里新建入站规则，协议选UDP、端口填514、勾选允许连接；另一种是直接在管理员命令行执行：

netsh advfirewall firewall add rule name="Allow_Syslog_UDP514" dir=in action=allow protocol=UDP localport=514

我推荐用netsh，因为它可以写进部署脚本里，而且不会漏掉配置界面里“网络类型”的坑。Windows防火墙默认有三种网络配置文件：域、专用、公用。如果你在配置界面里勾错了网络类型，宿主机在公用网络下还是会把包丢掉。

第二个容易被忽略的点是Kiwi的“Log to Screen”开关。Kiwi默认会在实时窗口显示收到的日志，但如果你在Setup里不小心把“Display”相关的选项关掉了，日志照样会归档，但屏幕上不显示，你会误以为没有收到。我第一次跑的时候就因为这个以为自己配置失败，实际文件里已经有了。所以排错时先看一眼归档目录里有没有文件生成，比盯着屏幕更可靠。

4. PIX端的日志配置命令详解

4.1 从on到host，一行行拆开讲

PIX的日志配置命令在7.x以上的版本里和ASA几乎一致，核心就是几个logging命令。下面是我这次实验里用的完整配置段：

configure terminal logging on logging timestamp logging facility 21 logging trap informational logging host inside 10.0.0.100

逐条拆开来说：

• logging on：开启日志功能。这条命令不执行，后面全白搭。
• logging timestamp：让日志带上时间戳。不加这条，Kiwi收到的日志只有消息本体，没有发生时间，很多分析工作根本没法开展。
• logging facility 21：设置日志设施号。21对应的是local5，这只是个分类标签，不影响内容，但配合Kiwi的过滤或不同设备分流时很有用。
• logging trap informational：设置上送日志的级别门槛。informational是最低级别之一，意味着除了debug之外几乎所有日志都会上送。这个级别在调试时合适，日常使用可以改成logging trap warnings，减少无用信息。
• logging host inside 10.0.0.100：指定日志服务器地址。在这个命令里，第一个参数是关键中的关键——它告诉PIX“我通过哪个接口能到达日志服务器”。我在实验里写的是inside，因为日志服务器10.0.0.100就在inside区域。

这里有一个值得提醒的细节：logging host命令后面还可以加端口号参数，格式是logging host inside 10.0.0.100 514。如果你不写端口，PIX默认发到UDP 514；但如果Kiwi改过监听端口，PIX这边必须一致。

4.2 关于facility和severity的选择

Syslog消息里有一个“优先级”字段，由两部分拼成：设施（facility）和级别（severity）。PIX默认一般用local4或者local6作为日志设施，我这次特意改成local5，是为了在Kiwi里做区分。

如果你后面有多台设备都要上送日志，建议每一类设备用不同的facility：比如PIX用local4、路由器用local5、Linux主机用local6。这样Kiwi收到大量日志时，可以一眼看出来源方向，也可以按设施号设置不同的归档目录或报警策略。

severity级别的选择则更实际。informational级别会包含大量正常的会话建立、策略命中等信息，在调试期间非常有价值；但如果你只是日常运维，日志会很快被正常信息淹没，重点的警告反而找不到了。我个人的做法是：平时保持warnings或notifications，真出问题再临时把级别调到informational甚至debug，排查完改回来。这是很多老网络工程师的习惯，也是我最推荐的做法。

4.3 要不要开NAT，本地流量会不会被翻译

这是一个我当初花了点时间才搞明白的问题：PIX向日志服务器发包时，源地址是我配置的接口IP，目标是日志服务器IP。那PIX会不会对这个包做NAT？答案是不会。

PIX生成的本地控制平面流量，比如SNMP、日志、NTP，这类流量在PIX自身的策略里属于“自身流量”，不经过正常的NAT规则匹配。也就是说，我在PIX上配置的global和nat指令并不会影响到Syslog报文的源地址转换。

但反之要特别小心：如果你的日志服务器不在inside区域，而是放在了DMZ或者outside区域，PIX发往那个区域的日志报文就可能涉及路由、ACL、甚至需要在相应接口上放行控制平面流量。我实验里始终让日志服务器待在inside，就是这个原因——不折腾路由、不折腾ACL、不折腾NAT，链路最干净。

验证配置是否生效，可以在PIX上执行：

show logging show logging | include host

如果看到如下输出，说明配置生效了：

Syslog logging: enabled Timestamp logging: enabled Hostname logging: enabled Console logging: disabled Monitor logging: disabled Buffer logging: disabled Trap logging: level informational, facility 21, 4 messages logged

其中“4 messages logged”就是你自启动日志配置以来，发往日志服务器或本地缓存的累计消息数。这个数字如果一直不涨，说明日志链路还有问题。

5. 验证链路与常见故障排查

5.1 三处确认：PIX侧、链路侧、Kiwi侧

配置完成后不要急着完事，按顺序做三处确认，哪一步不对就停下来排查：

第一处是PIX侧。在PIX上执行了前面那些logging命令后，再敲show logging，确认日志状态是enabled、trap级别是informational、目标host已经有一行记录。然后可以手动触发几条日志，最简单的方法是故意输错一个管理员密码，或者执行clear arp、开启/关闭一个接口，这类行为都会立刻产生日志。

第二处是链路侧。在PIX上ping一下日志服务器：

ping 10.0.0.100

能ping通说明路由没问题。这里要注意Windows宿主机默认会响应ICMP回显，如果你之前改了防火墙规则禁ping，PIX的ping测试可能会失败，但那不代表UDP 514不可达。所以在确认网络通的时候，也要去Windows防火墙里顺带看下ICMP回显规则是不是被禁了。

第三处是Kiwi侧。打开Kiwi的实时窗口，看有没有来自10.0.0.1（PIX inside接口地址）的新消息。如果看到了，说明整条链路是通的。

5.2 “收不到日志”三层排查链路

这是这篇博文里我最想讲透的部分。很多人配置完发现Kiwi里一片空白，就开始乱改PIX配置，越改越乱。正确的排查思路是由近及远，分成三层。

第一层：PIX配置。检查logging on是否开启，检查trap级别是否设置得过高导致过滤掉日志，检查logging host后面的接口名是否正确。特别容易犯的错误是接口名写错，比如日志服务器其实在inside接口后，但你写的是outside，PIX会试着从outside路由去找一个不可能到达的地址。

第二层：网络链路。用GNS3自带的抓包功能，在Cloud节点的接口连接线上右键选择“Start Capture”，然后抓包看有没有UDP 514的报文从PIX发出来。这一步是判断“PIX有没有发”还是“Zwischen设备没转发”的分界线。

如果抓包发现有发往10.0.0.100的UDP报文，那说明PIX侧正常，问题在宿主机或Kiwi。如果什么都没有，就要回第一层看PIX配置，或者检查PIX路由表里有没有10.0.0.0/24网段的路由。PIX直连inside网段，理论上10.0.0.0/24就是直连路由，但如果你的拓扑网络更复杂，这里就可能出现路由黑洞。

第三层：宿主机侧。确认Kiwi监听UDP 514，用前面说的netstat命令验证；确认Windows防火墙放行了UDP 514入站；确认Kiwi的实时显示和归档功能没有关闭。

这个三层排查思路，覆盖了90%“收不到日志”的场景。剩下的10%往往出在GNS3本身：Cloud节点没绑定正确的网卡，或者宿主机上装了多块网卡导致绑定到了错误的物理接口。用抓包定位到具体是哪个网卡，一下就能发现问题。

5.3 时间戳错乱与日志量刷屏

日志链路通之后，紧接着会面对两个新问题。

第一个是时间戳错乱。PIX本身没有电池和实时时钟芯片，在GNS3环境下每次启动后时间都会回到一个固定值。如果你不手动设置，Kiwi收到的日志时间和你实际实验时间会对不上，甚至可能出现“日志时间比现实时间早几十年”的情况。解决办法是手动给PIX设置当前时间：

clock set 15:30:00 2025年1月15日

这里的语法会随版本不同有微小变化，7.x以上一般是clock set hh:mm:ss day month year。GNS3重启后时间照样丢，所以我的习惯是：每次启动实验，先把PIX的clock set命令作为第一条配置来执行，再开始后面的调试。你也可以把clock命令写进启动配置，但PIX重启后还是会丢时间，这个是无法绕过的。

第二个问题是日志量刷屏。当你把trap级别设成informational之后，一个ping包就会产生好几条日志，比如从inside发起的“Built inbound TCP connection”等等。日志多的时候，Kiwi实时窗口刷得飞快，反而找不到你想看的那条。我的做法是：实验验证阶段用informational没问题，但稳定跑的时候把trap级别改成warnings或notifications，并且在Kiwi里设置过滤规则，只显示特定优先级或特定来源IP的消息，这样窗口干净多了。

6. 进阶用法与一点个人体会

6.1 facility分级和远程归档的实际用法

链路通了、日志能正常收了，这套架构才算落地。接下来可以琢磨怎么让它更好用。

在实际环境里，日志服务器不会只服务一台PIX。至少我在实验后就把拓扑扩展到了三台设备：一台PIX、一台交换模拟器、一个Linux虚拟机模拟服务器。三台设备同时往Kiwi发日志，如果不做区分，你会看到信息来源都是不同IP，但消息类型混在一起，分析起来很累。

所以我在Kiwi的Setup里，给不同设备配置了不同的归档目录规则，或在日志文件名上添加来源IP变量：

C:\Syslog\archive\[IP]-2025-01-15.log

这样Kiwi收到日志后，会自动按来源IP生成独立文件。配合PIX端不同的facility设置，日志的归类就很清晰了。比如PIX用local4，Linux的rsyslog默认用local0，在网络里连一次，你就能看到Kiwi对不同来源的日志做了默认解析。看懂这些字段之后，你设置过滤、报警和归档的时候心里就更有底了。

6.2 把日志用起来的几个技巧

日志收到只是开始，真正发挥价值的是后续的处理。我这里分享几个自己用得顺手的小技巧：

第一，在Kiwi里设置特定关键字的弹窗提醒。当PIX日志里出现“Deny”字样，或者登录失败的标志时，弹出一个提示框，这样不用一直盯着窗口，出现风险操作立刻就能知道。

第二，把Kiwi的归档目录做成“可查询索引”。我习惯按天生成文件，然后配合一个简单的PowerShell脚本，对指定时间范围内的某个IP做关键词检索。人眼在实时窗口里盯日志是盯不过来的，但脚本能秒级出结果。

第三，不要把日志精确到秒级去做分析。很多时候看一个小时的趋势比看一条消息的细节更重要。Kiwi虽然不能画图，但归档文件导出来后，用Excel或者任何表格工具打开，做个简单的统计透视，什么问题高发、哪个IP最活跃立刻一目了然。

从GNS3模拟器到PIX防火墙，再到Kiwi Syslog服务器，这套组合搭建起来不难，但每一环都有值得琢磨的细节。我把它写下来，也是给以后自己留个备忘——日志链路这东西，配置命令就那么几行，但真正把它用起来，靠的是对整个链路的理解和对细节的把握。希望这篇文章能让你少走几步我走过的弯路。