1. 企业级内网环境搭建的整体设计思路1.1 为什么企业需要一套自己的内网环境很多刚入行的朋友会问现在云服务这么方便为什么还要折腾内网环境这个问题我在几年前也问过自己。当时接手了一个为某中型研发团队做基础设施改造的项目团队大概八十多人分布在三个办公区日常要跑代码仓库、持续集成、内部文档、制品库、监控告警这一整套东西。一开始他们全部放在公有云上账单每个月都在涨而且研发同学拉一个几GB的依赖包要等很久跨区访问延迟高得让人抓狂。后来我们把核心服务逐步迁回办公区机房搭了一套完整的企业级内网环境情况立刻不一样了。内网环境的核心价值在于三点数据不出园区、访问延迟极低、成本可控。尤其是涉及代码资产、设计稿、客户数据这类敏感内容时放在自己可控的物理网络里心里踏实得多。所谓企业级内网环境说白了就是在企业办公区或自建机房里用一套规划好的网络架构把内部服务、存储、计算资源、安全策略全部串起来让员工在园区内高速访问在外也能通过合规方式接入。它解决的是资源集中管理、访问效率、安全隔离、成本优化这四个核心问题。适合谁来参考我建议是这几类人刚接手公司基础设施的运维工程师、想给团队搭一套自用环境的研发负责人、以及正在学习网络与服务部署的学生或转行者。哪怕你只有一台旧服务器这套思路也能按比例缩小使用。1.2 整体架构的分层设计搭内网最忌讳的就是“想到哪搭到哪”。我见过太多团队今天加一台机器明天插一个交换机最后网线像蜘蛛网一样IP地址冲突天天有。企业级内网一定要分层设计我习惯把它分成四层来看。第一层是物理与链路层包括机房环境、机柜、交换机、路由器、防火墙、布线。这一层是地基地基不稳后面全白搭。第二层是网络层核心是IP地址规划、VLAN划分、路由策略、DHCP与DNS。第三层是服务层也就是跑在里面的各种应用代码托管、制品库、CI/CD、文档、监控、日志。第四层是安全与运维层包括访问控制、认证授权、备份恢复、审计日志。这四层的关系就像盖楼物理层是地基和承重墙网络层是水电管线服务层是各个房间的功能安全运维层是门禁和物业。任何一层出问题整栋楼都不好用。我在实际项目里最深的体会是网络层的IP规划如果一开始没做好后面迁移服务的成本会高到让你想推倒重来。所以下面我会重点讲IP规划这块。1.3 方案选型的几个关键取舍搭内网绕不开几个选型问题我把常见的取舍列出来都是踩过坑之后的真实感受。选型维度方案A方案B我的建议网络设备商用品牌交换机软路由普通交换机50人以下用软路由方案成本低服务部署物理机直装虚拟化/容器强烈建议虚拟化资源利用率高存储方案本地磁盘网络存储核心数据必须网络存储备份认证方式本地账号统一目录服务超过20人必须上统一认证内网域名直接IP访问自建DNS一定要自建DNS否则后期维护痛苦这里重点说两个。第一个是虚拟化我强烈建议哪怕只有一台物理服务器也要装个虚拟化平台。原因很简单服务之间需要隔离一个服务崩了不能拖垮其他服务而且快照和迁移功能在出故障时能救命。第二个是自建DNS很多小团队图省事直接用IP访问内部服务等到服务多了、IP变了配置文件改到崩溃。自建DNS之后服务地址用域名表示IP变了只改一处解析记录。注意选型没有绝对的对错关键是匹配团队规模和预算。不要为了追求“企业级”三个字上来就买一堆用不上的设备那是浪费。2. 网络规划与IP地址设计的核心细节2.1 IP地址规划的具体计算方法IP规划是内网搭建里最容易被忽视、却最影响后期维护的环节。我见过一个团队内网用了192.168.1.0/24这一个网段结果服务器、打印机、员工电脑、访客设备全挤在一起广播风暴一来全网卡顿。正确的做法是按用途划分网段每个网段留足余量。先讲计算方法。假设公司现在有120人预计三年内扩展到200人。员工办公设备按每人2台算电脑手机需要400个地址。服务器和网络设备预留100个。访客和IoT设备预留100个。总共需要600个可用地址。一个C类网段/24只有254个可用地址不够。所以要么用多个/24要么直接上/23510个或/221022个。我的习惯是按功能划分每个功能一个VLAN对应一个网段管理网段10.10.0.0/24放交换机、防火墙、带外管理口服务器网段10.10.10.0/24放核心服务办公网段10.10.20.0/23容纳约500人访客网段10.10.30.0/24与内网隔离测试网段10.10.40.0/24研发测试用用10开头的私有地址段是因为它地址空间大方便后期扩展。192.168段太小172.16段也够用但10段最灵活。每个网段内部再细分前50个地址留给静态设备网关、服务器、打印机后面的用DHCP动态分配。2.2 VLAN划分与交换机配置要点VLAN的作用是把一个物理交换机切成多个逻辑网络不同VLAN之间默认不能直接通信必须经过路由。这样做的好处是隔离广播域、提升安全性、方便管理。配置VLAN的核心步骤我以常见的命令行交换机为例说明。首先创建VLAN# 进入配置模式 configure terminal # 创建VLAN 10服务器、20办公、30访客 vlan 10 name server vlan 20 name office vlan 30 name guest exit然后把端口划分到对应VLAN。这里有个关键点连接服务器的端口和连接员工电脑的端口配置方式不同。服务器通常固定接某个口用access模式而员工工位可能需要接电话、电脑、打印机用trunk模式配合语音VLAN更灵活。# 服务器端口设为access模式划入VLAN 10 interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 # 上行连接核心交换机的端口设为trunk允许所有VLAN通过 interface GigabitEthernet0/24 switchport mode trunk switchport trunk allowed vlan 10,20,30注意trunk端口一定要限制允许通过的VLAN列表不要图省事用all。我见过因为trunk放行所有VLAN导致访客网络的广播包窜到服务器网段引发服务抖动的案例。2.3 路由与网关的配置逻辑不同VLAN之间要通信必须经过三层路由。有两种做法用三层交换机做VLAN间路由或者用路由器/防火墙做单臂路由。50人以上的团队我建议用三层交换机转发性能高延迟低。三层交换机上配置VLAN接口SVI作为各网段网关interface Vlan10 ip address 10.10.10.1 255.255.255.0 interface Vlan20 ip address 10.10.20.1 255.255.254.0 interface Vlan30 ip address 10.10.30.1 255.255.255.0 # 开启路由功能 ip routing网关地址我习惯用网段的第一个可用地址.1这样记忆统一。配置完之后服务器网段的机器网关指向10.10.10.1办公网段指向10.10.20.1以此类推。这里有个细节访客网段要单独做访问控制只允许它访问互联网禁止访问内网其他网段。这个策略在三层交换机或防火墙上用ACL实现# 拒绝访客网段访问内网其他网段 access-list 100 deny ip 10.10.30.0 0.0.0.255 10.10.0.0 0.0.255.255 # 允许访客访问互联网 access-list 100 permit ip 10.10.30.0 0.0.0.255 anyACL的匹配顺序是从上到下一旦匹配就执行所以拒绝规则要放在允许规则前面。这个顺序搞反了访客就能访问内网安全形同虚设。2.4 DHCP与DNS服务的落地配置DHCP负责自动分配IPDNS负责域名解析这两个服务是内网体验的关键。我建议把DHCP和DNS都放在内网的Linux服务器上用开源软件实现可控性比用路由器自带的功能强得多。DHCP配置的核心是按VLAN分配不同网段。用isc-dhcp-server的话配置文件大概长这样# /etc/dhcp/dhcpd.conf subnet 10.10.20.0 netmask 255.255.254.0 { range 10.10.20.100 10.10.21.200; option routers 10.10.20.1; option domain-name-servers 10.10.10.10; option domain-name corp.internal; default-lease-time 86400; max-lease-time 604800; }这里range从.100开始是为了给静态设备留出.1到.99的空间。domain-name-servers指向内网DNS服务器。租期设成一天到一周避免频繁续租又不会长期占用。DNS我用的是dnsmasq或者bind小团队dnsmasq足够。核心是配置内网域名解析# /etc/dnsmasq.conf domain-needed bogus-priv local/corp.internal/ address/git.corp.internal/10.10.10.20 address/ci.corp.internal/10.10.10.21 address/docs.corp.internal/10.10.10.22 server223.5.5.5 server119.29.29.29local/corp.internal/表示这个域名只在本地解析不往外查。address把域名映射到内网IP。最后两行是上游DNS用于解析外网域名。这样员工访问git.corp.internal直接走内网访问外部网站走上游体验和公网一样顺滑。提示DNS服务器一定要配两个主备各一台。DNS挂了整个内网的域名访问全废这个故障我经历过一次教训深刻。3. 核心服务的部署与实操过程3.1 虚拟化平台的搭建与资源分配服务层的地基是虚拟化平台。我推荐两种方案预算充足用商用虚拟化预算有限用开源的Proxmox VE或者基于KVM的方案。这里以开源方案为例讲实操因为大部分中小团队用得起。安装虚拟化平台之前先规划资源。假设一台物理服务器配置为双路16核CPU、128GB内存、4块960GB SSD做RAID10、双万兆网卡。资源分配我一般这样切基础设施虚拟机DNS、DHCP、认证2核4GB共3台代码托管4核16GB存储需求大制品库4核8GB存储需求大CI/CD8核32GB跑构建任务吃CPU和内存监控日志4核16GB文档协作2核8GB加起来大概用掉26核、84GB内存留出余量给突发负载。存储方面SSD做RAID10兼顾性能和冗余容量约1.8TB可用够放代码和制品。如果数据量大再挂一台网络存储做冷数据归档。安装Proxmox VE的步骤不复杂制作启动U盘从U盘引导按提示选磁盘、设密码、配管理IP。装完之后通过浏览器访问管理界面默认端口8006。第一次登录后先做两件事配置存储池和上传ISO镜像。# 查看存储配置 pvesm status # 添加目录存储用于放ISO pvesm add dir iso-store --path /var/lib/vz/template/iso3.2 代码托管与制品库的部署代码托管是研发团队的心脏。我推荐用开源的Git服务方案部署在虚拟机上。以常见的GitLab社区版为例用Docker部署最省事# 创建数据目录 mkdir -p /srv/gitlab/{config,logs,data} # 启动容器 docker run -d \ --hostname git.corp.internal \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest启动后第一次访问会要求设置管理员密码然后就能建用户、建项目了。这里的关键配置是外部URL一定要设成内网域名git.corp.internal否则克隆地址会变成容器内部地址员工用不了。制品库我推荐用Nexus或者Artifactory的开源版用来存Maven、npm、Docker镜像。部署方式类似也是Docker跑起来然后配置仓库类型。制品库的价值在于统一依赖来源员工拉包走内网速度快且不受外网波动影响。我实测过一个200MB的依赖包从外网拉要两三分钟从内网制品库拉只要十几秒。3.3 CI/CD流水线的搭建要点CI/CD是把代码变成可部署产物的自动化流水线。我用的方案是GitLab Runner配合GitLab CI。Runner是执行构建任务的代理可以部署在多台机器上分担负载。安装Runner# 添加官方仓库并安装 curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash apt install gitlab-runner # 注册Runner gitlab-runner register \ --url http://git.corp.internal/ \ --registration-token 你的token \ --executor docker \ --docker-image alpine:latest \ --description docker-runner-01 \ --tag-list docker,linux注册时用的token在GitLab管理界面的Runner设置里获取。executor选docker这样每个构建任务跑在独立容器里互不干扰构建完容器销毁环境干净。.gitlab-ci.yml是流水线的定义文件放在项目根目录。一个典型的Java项目流水线分三个阶段构建、测试、打包镜像。stages: - build - test - package build-job: stage: build script: - mvn clean compile tags: - docker test-job: stage: test script: - mvn test tags: - docker package-job: stage: package script: - mvn package -DskipTests - docker build -t registry.corp.internal/app:$CI_COMMIT_SHORT_SHA . - docker push registry.corp.internal/app:$CI_COMMIT_SHORT_SHA tags: - docker only: - main这里only: main表示只有主分支才打包镜像避免每个分支都推镜像把制品库撑爆。$CI_COMMIT_SHORT_SHA是GitLab内置变量用提交哈希做镜像标签方便追溯。注意Runner的并发数要限制默认可能开太多把机器跑满。在/etc/gitlab-runner/config.toml里设concurrent 4根据机器配置调整。3.4 监控与日志系统的落地服务跑起来只是开始能不能及时发现问题是关键。监控我用Prometheus加Grafana的组合日志用Loki或者ELK。Prometheus负责采集指标Grafana负责展示告警通过Alertmanager发到内部通讯工具。Prometheus的配置核心是scrape_configs定义要抓取哪些目标scrape_configs: - job_name: node static_configs: - targets: [10.10.10.20:9100, 10.10.10.21:9100] - job_name: gitlab static_configs: - targets: [10.10.10.20:9090]每台被监控的机器上要跑一个node_exporter暴露系统指标。应用层面GitLab、Nexus这些服务大多自带metrics接口直接配到Prometheus里就行。Grafana的看板我建议至少配三个主机资源看板CPU、内存、磁盘、网络、服务健康看板各服务存活状态、响应时间、业务看板构建成功率、部署频率。告警规则设几条关键的磁盘使用率超85%、服务连续5分钟不可达、构建失败率突增。告警发到内部群值班的人第一时间能看到。日志系统我倾向用Loki因为它和Grafana集成好资源占用比ELK小。每台机器跑Promtail采集日志推到Loki在Grafana里用LogQL查询。查日志的时候按服务名、时间范围过滤比登录每台机器翻文件高效太多。4. 安全策略与访问控制4.1 统一认证与权限管理内网安全的第一道门是认证。小团队可能用本地账号但超过20人就必须上统一认证否则每个服务一套账号密码员工记不住管理员也管不过来。我用的是LDAP或者基于LDAP的目录服务所有内网服务对接它做认证。部署目录服务之后员工用一个账号登录所有系统。权限管理按组划分研发组、测试组、运维组、管理层。每个组对不同服务的权限不同。比如研发组能推代码到自己的项目但不能改生产环境配置运维组有生产环境权限但代码仓库只读。GitLab对接LDAP的配置在gitlab.rb里gitlab_rails[ldap_enabled] true gitlab_rails[ldap_servers] YAML.load -EOS main: label: Corp LDAP host: 10.10.10.10 port: 389 uid: uid bind_dn: cnadmin,dccorp,dcinternal password: 你的密码 base: ouusers,dccorp,dcinternal user_filter: EOS配好之后重启GitLab员工就能用目录服务的账号登录了。权限组在GitLab里再映射一次LDAP的组对应GitLab的组管理起来清晰。4.2 网络访问控制与防火墙策略网络层的安全靠防火墙和ACL。核心原则是默认拒绝按需放行。内网不同网段之间只开放必要的端口其他一律拒绝。防火墙策略我按这个思路配源网段目标网段允许端口用途办公网段服务器网段80,443,22访问Web服务和SSH办公网段服务器网段3306,6379数据库和缓存仅研发访客网段任意内网无完全隔离服务器网段互联网80,443更新和拉取依赖管理网段所有网段任意运维管理数据库端口只对研发网段开放而且最好再加一层只对特定IP开放。生产数据库更是要严格限制只有应用服务器能连。提示防火墙规则一定要有日志定期review。我见过规则越加越多最后自己都忘了哪条是干嘛的清理的时候不敢删安全隐患就这么积累下来了。4.3 数据备份与灾难恢复再稳的系统也可能出故障备份是最后的保险。备份策略我遵循3-2-1原则3份数据2种介质1份异地。内网环境下异地可以理解为不同机房或不同存储设备。备份分三类配置备份、数据备份、镜像备份。配置备份是各种服务的配置文件用Git管理起来每次改动提交天然有版本历史。数据备份是数据库、代码仓库、制品库的内容用定时任务导出。镜像备份是虚拟机的完整快照用于快速恢复。数据库备份用定时任务# 每天凌晨2点备份GitLab数据 0 2 * * * /usr/bin/gitlab-backup create CRON1 # 保留最近7天的备份 0 3 * * * find /var/opt/gitlab/backups -mtime 7 -delete备份完一定要验证可恢复性。我踩过的坑是备份文件天天生成看着挺正常真出事要恢复的时候发现备份是坏的。所以每隔一段时间要做一次恢复演练在测试环境把备份还原一遍确认能用。灾难恢复的流程要写成文档包括谁负责、第一步做什么、联系谁、恢复顺序是什么。真出事的时候人是慌的有文档照着做能少犯错。4.4 安全审计与合规检查审计日志记录谁在什么时候做了什么操作出问题能追溯。关键系统都要开审计目录服务的登录日志、GitLab的操作日志、防火墙的流量日志、服务器的登录日志。日志集中收集到日志系统设置保留期至少180天。审计日志要防篡改普通用户不能删改。我一般把审计日志单独存一份到只读存储或者用WORM一次写入多次读取特性的存储。定期做合规检查检查项包括弱密码、未打补丁的系统、开放的高危端口、过期的证书、权限过大的账号。这些检查可以手动做也可以用开源工具自动化。检查结果形成报告有问题的限期整改。5. 常见问题与排查技巧实录5.1 网络连通性问题的排查思路内网问题里网络不通占了一大半。排查要有顺序从下往上查物理层、链路层、网络层、应用层。先看物理层网线插好没、网口灯亮不亮、交换机端口状态。这些看着简单但实际故障里占比不低。我有一次排查了半小时最后发现是网线水晶头松了。链路层看VLAN配置端口划对VLAN没、trunk放行没。用show vlan brief和show interfaces trunk查看。网络层看IP和路由IP配对没、网关通不通、路由表有没有目标网段。用ping测网关traceroute看路径show ip route看路由表。应用层看端口和服务端口监听没、防火墙放行没、服务进程活着没。用telnet IP 端口测端口netstat -tlnp看监听systemctl status看服务。我整理了一个速查表现象可能原因排查命令ping不通网关IP/掩码错、VLAN错ip addr, show vlanping通网关但跨网段不通路由缺失、ACL拦截show ip route, show acl端口连不上服务没起、防火墙拦netstat, iptables -L域名解析失败DNS配置错、DNS服务挂nslookup, systemctl status dns时通时不通环路、广播风暴、IP冲突show mac, arp -a5.2 服务性能问题的定位方法服务变慢的原因很多定位要系统化。我按这个顺序查资源、网络、应用、数据库。资源看CPU、内存、磁盘IO、网络带宽。用top、free、iostat、iftop。CPU高看是哪个进程内存高看是不是泄漏磁盘IO高看是读还是写网络看带宽跑满没。网络看延迟和丢包。用ping测延迟mtr看路径质量tcpdump抓包分析。内网延迟正常应该在1ms以内超过5ms就有问题。应用看日志和线程。日志里找ERROR和WARN看有没有异常堆栈。Java应用用jstack看线程状态有没有死锁、线程池满。数据库看慢查询和连接数。开慢查询日志看哪些SQL执行时间长。连接数看是不是被打满了。我遇到过一个典型案例CI构建突然变慢从5分钟变成20分钟。查资源发现CPU不高查网络正常最后看日志发现是制品库响应慢再查制品库发现磁盘满了清理之后恢复正常。这个链条说明性能问题往往不在表象层要顺着依赖往下查。5.3 认证与权限问题的处理认证问题常见的有登录失败、权限不足、单点登录失效。登录失败先看账号密码对不对再看目录服务通不通最后看服务对接配置对不对。目录服务用ldapsearch测试查询能查到用户说明服务正常。权限不足看用户属于哪个组组的权限是什么。GitLab里用Admin Area看用户权限LDAP里用ldapsearch看组成员。单点登录失效看会话和token。会话过期时间设太短会导致频繁登录太长有安全风险。token失效看签名和有效期。注意权限问题不要靠“给管理员权限”来解决那是饮鸩止渴。要找到权限配置的根因该加组加组该改策略改策略。5.4 备份恢复失败的应急处理备份恢复失败是最让人紧张的因为往往是在真出事的时候才发现。常见原因备份文件损坏、恢复步骤错、目标环境不兼容。备份文件损坏的预防是定期验证。恢复步骤错要靠文档和演练。目标环境不兼容要注意版本匹配比如数据库备份从5.7恢复到8.0可能有问题。应急处理流程先确认备份文件完整性校验和、大小再在隔离环境试恢复确认没问题再恢复到生产。如果备份不可用看有没有其他副本比如从库、快照、异地备份。我个人的经验是备份的价值不在于备份本身而在于恢复。所以每次做完备份我都会抽时间做一次恢复测试哪怕只是恢复到测试环境验证一下。这个习惯帮我避免过一次重大事故。6. 内网环境的日常运维与优化6.1 日常巡检与健康检查内网搭好之后日常运维决定它能不能长期稳定。我习惯每天早上花15分钟做巡检检查项固定下来形成清单。巡检清单包括核心服务存活状态、磁盘使用率、备份任务执行结果、告警记录、证书有效期。这些在Grafana看板上都能看到扫一眼就知道有没有异常。每周做一次深度检查日志里的错误趋势、性能指标的变化趋势、安全补丁情况、账号权限review。趋势比单点更重要比如磁盘使用率每周涨5%那就要提前规划扩容。每月做一次演练恢复一个备份、切换一次主备、模拟一次故障。演练不是为了好看是为了真出事的时候手不抖。6.2 容量规划与扩展策略容量规划要提前做不能等资源用完了才着急。我按三个维度规划计算、存储、网络。计算看CPU和内存的使用率趋势。如果平均使用率超过60%就要考虑扩容。扩容可以是加物理机、加虚拟机、或者优化现有服务。存储看增长速度和剩余空间。代码仓库和制品库增长快要预留足够空间。我一般保持至少30%的剩余空间低于这个值就触发扩容流程。网络看带宽利用率和延迟。内网带宽一般不是瓶颈但跨机房、跨网段要注意。如果带宽利用率长期超过70%要考虑升级链路或做流量优化。扩展策略上我倾向横向扩展而不是纵向扩展。加机器比升级单机更灵活也更有容错性。服务设计上要支持多实例配合负载均衡。6.3 文档化与知识沉淀内网环境最怕的是“只有一个人懂”。这个人一休假出问题没人能处理。所以文档化是必须的。文档包括网络拓扑图、IP地址分配表、服务清单、部署文档、运维手册、故障处理流程、应急预案。这些文档放在内网文档系统里所有人能查。文档要定期更新每次变更都同步改文档。我见过文档和实际环境对不上的情况那比没文档还危险因为会误导人。知识沉淀靠复盘。每次故障处理完写一份复盘报告什么现象、什么原因、怎么解决、怎么预防。复盘报告积累起来就是团队的财富。6.4 持续优化的一些实用技巧内网环境不是搭完就完事要持续优化。我分享几个实用的优化点。DNS缓存优化内网DNS加缓存减少上游查询。dnsmasq默认有缓存调大cache-size能提升解析速度。镜像加速常用的Docker镜像、软件包在内网做镜像拉取速度快很多。Nexus可以配代理仓库自动缓存外网拉过的包。构建缓存CI构建时缓存依赖目录避免每次重新下载。GitLab CI的cache关键字能实现配置好之后构建时间能缩短一半。日志分级日志级别设合理生产环境用INFO或WARNDEBUG只在排查时临时开。日志量太大既占存储又影响性能。监控告警收敛告警不要太多多了就没人看了。只对真正重要的指标告警告警要有明确的处理动作。这些优化看着小积累起来对体验的提升很明显。我在实际项目里光是构建缓存这一项就让团队的日均构建时间从两小时降到四十分钟。最后分享一个我自己的体会内网环境搭建这件事技术本身不难难的是规划和坚持。规划好IP、规划好服务、规划好权限后面就顺坚持做备份、坚持做巡检、坚持写文档环境就稳。我见过太多团队搭的时候轰轰烈烈搭完就没人管半年后环境烂成一团。所以如果你正在做这件事把眼光放长一点前期多花的时间后面都会省回来。