十二月 2021 – 資安部落客

架構
free5gc 192.168.40.132
UE 192.168.40.135
gNB 192.168.40.136

#############三台網路的設定#######內容小心空白字元搭配tab
#vim /etc/netplan/01-network-manager-all.yaml

# Let NetworkManager manage all devices on this system
network:
version: 2
# renderer: NetworkManager
ethernets:
ens32:
addresses: [192.168.40.132/24] ############這邊不同主機記得改不同IP
gateway4: 192.168.40.2
nameservers:
addresses: [8.8.8.8,8.8.4.4]
dhcp4: no

#netplan apply
測試三台互ping是否通

###################安裝參考資料###########################
free5gc
https://github.com/free5gc/free5gc/wiki/Installation
https://www.free5gc.org/installations/stage-3-free5gc-install-tw/
https://www.free5gc.org/installations/stage-2-standalone-5g/
go run /root/free5gc/webconsoleserver.go & ###########free5GC啟動指令

http://192.168.40.132:5000/#/
admin / free5gc

——————————————————————

UEranSIM
https://github.com/aligungr/UERANSIM/wiki/Installation
https://github.com/aligungr/UERANSIM/wiki/Configuration
https://www.free5gc.org/installations/stage-3-sim-install-tw/

#############以下為設定檔與啟動指令############
UE部分
#cd /root/UERANSIM
#vim config/free5gc-ue.yaml

supi: ‘imsi-208930000000003’
mcc: ‘208’
mnc: ’93’

key: ‘8baf473f2f8fd09487cccbd7097c6862’
op: ‘8e27b6af0e692e750f32667a3b14605d’
opType: ‘OP’
amf: ‘8000’
imei: ‘356938035643803’
imeiSv: ‘4370816125816151’

gnbSearchList:
– 192.168.40.136

uacAic:
mps: false
mcs: false

uacAcc:
normalClass: 0
class11: false
class12: false
class13: false
class14: false
class15: false

sessions:
– type: ‘IPv4’
apn: ‘internet’
slice:
sst: 0x01
sd: 0x010203

configured-nssai:
– sst: 0x01
sd: 0x010203

default-nssai:
– sst: 1
sd: 1

integrity:
IA1: true
IA2: true
IA3: true

ciphering:
EA1: true
EA2: true
EA3: true

integrityMaxRate:
uplink: ‘full’
downlink: ‘full’

#build/nr-ue -c config/free5gc-ue.yaml———–啟動指令

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gNB部分
#cd /root/UERANSIM
#vim ~/UERANSIM/config/free5gc-gnb.yaml

amfConfigs:
– address: 192.168.40.132
port: 38412

slices:
– sst: 0x1
sd: 0x010203

ignoreStreamIds: true

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
free5gc部分
若依 https://www.free5gc.org/installations/stage-3-free5gc-install-tw/
裡面的第五部分測試無誤則:

#cd /root/free5gc
#./run.sh

啟動順序部分依序為 free5gc – gNB – UEranSIM

以上

家裡設vpn

https://sites.google.com/site/kudos53cocc/word-of-the-week/dan-nao-ying-yong/vpn-ci-fu-qi-zi-ji-jia-she

DHCP原理和解釋

DHCP原理和解釋

2018-07-12 由 我是陸小皓 發表于程式開發

一、DHCP的含義?

DHCP，動態主機配置協議，前身是BOOTP協議，是一個區域網的網絡協議，使用UDP協議工作，常用的2個埠：67(DHCP server),68(DHCP client)。DHCP通常被用於區域網環境，主要作用是集中的管理、分配IP位址，使client動態的獲得IP位址、Gateway地址、DNS伺服器地址等信息，並能夠提升地址的使用率。簡單來說，DHCP就是一個不需要帳號密碼登錄的、自動給內網機器分配IP位址等信息的協議。

二、DHCP協議中的報文

DHCP報文共有一下幾種：

DHCP DISCOVER ：客戶端開始DHCP過程發送的包，是DHCP協議的開始
DHCP OFFER ：伺服器接收到DHCP DISCOVER之後做出的響應，它包括了給予客戶端的IP（yiaddr）、客戶端的MAC地址、租約過期時間、伺服器的識別符以及其他信息
DHCP REQUEST ：客戶端對於伺服器發出的DHCP OFFER所做出的響應。在續約租期的時候同樣會使用。
DHCP ACK ：伺服器在接收到客戶端發來的DHCP REQUEST之後發出的成功確認的報文。在建立連接的時候，客戶端在接收到這個報文之後才會確認分配給它的IP和其他信息可以被允許使用。
DHCP NAK ：DHCP ACK的相反的報文，表示伺服器拒絕了客戶端的請求。
DHCP RELEASE ：一般出現在客戶端關機、下線等狀況。這個報文將會使DHCP伺服器釋放發出此報文的客戶端的IP位址
DHCP INFORM ：客戶端發出的向伺服器請求一些信息的報文
DHCP DECLINE :當客戶端發現伺服器分配的IP位址無法使用（如IP位址衝突時），將發出此報文，通知伺服器禁止
使用該IP位址。

DHCP 的工作流程：

3、DHCP 協議包的組成

Xid :隨機生成的一段字符串，兩個數據包擁有相同的xid說明他們屬於同一次會話
Ciaddr :客戶端會在發送請求時將自己的ip地址放在此處
Yiaddr :伺服器會將想要分配給客戶端的ip地址放在此處
Siaddr :一般來說是伺服器的ip地址.但是注意！根據openwrt源碼給出的注釋，當報文的源地址、siaddr、option>server_id欄位不一致（有經過跨子網轉發）時，通常認為option>srever_id欄位為真正的伺服器ip，siaddr有可能是多次路由跳轉中的某一個路由的ip （下圖中wireshark抓包中也有標明siaddr為nextserver ip address）
Chaddr :客戶端的mac地址
Giaddr :如果需要跨子網進行DHCP地址發放，則在此處填入經過的路由器的ip地址
Sname :伺服器主域名
Options :可以自由添加的部分，用於存放客戶端向伺服器請求信息和伺服器的應答信息DHCP 客戶端

一、DHCP 原理

1、什麼是DHCP 客戶端

DHCP客戶端一般來說是區域網中獨立的PC主機。

DHCP客戶端發出的DHCP DISCOVER包是DHCP協議的開始。

延續租期、發現、釋放IP位址等大多數DHCP中的行為都是由DHCP客戶端主動發起。

2、DHCP 自動狀態機

DHCP獲得ip地址的4步驟：discover>offer>request>ack(nak)

DHCP刷新租期的步驟：request>ack(nak)

DHCP釋放ip的步驟：release

wnr2000v5 1.0.0.8的代碼中沒有發現rebooting、initreboot狀態。所以DHCP client的狀態一般從init開始，完整的狀態機如下圖（紅色代表客戶端的狀態跳轉）：

DHCP Server

一、DHCPD 原理

1、簡述

DHCP SERVER指的是伺服器端，在路由器上體現的就是給LAN端動態分配IP的功能。DHCP SERVER負責接收客戶端的DHCP請求，管理LAN端所有的IP網絡設定資料，相比於BOOTP，DHCP通過「租約」來實現動態分配IP的功能，實現IP的時分復用，從而解決IP資源短缺的問題。其地址分配方式有三種，分別是人工配置（由管理員對每台具體的計算機指定一個地址），自動配置（伺服器為第一次連接網絡的計算機分配一個永久地址），動態配置（在一定的期限內將地址租給計算機，租期結束後客戶必須續租或者停用該地址），而對於路由器，經常使用的地址分配方式是動態配置。

2、兩個租約表

靜態租約表：對應一個靜態租約存儲文件，server運行時從文件中讀取靜態租約表。
動態租約表：對應一個周期存儲文件，server周期性將租約表存進該文件，在程序開始時將會讀取上次存放的租約表。（租約表記錄了當前所有分配的租約，包括靜態連結的）。

3、基本邏輯

原則上DHCP SERVER是一直處在被動接受請求的狀態，當有客戶端請求時，伺服器會讀取獲得客戶端當前所在的狀態以及客戶端的信息，並在靜態租約表和動態租約表中進行檢索找到相應的表項，再根據客戶端的狀態執行不同的回覆。當收到客戶端的首次請求時，DHCP伺服器先查找靜態租約表；若存在請求的表項，返回這個客戶的靜態IP位址；否則，從IP位址池中選擇可用的IP分配給客戶，並添加信息到動態資料庫中。此外，伺服器將會周期性的刷新租約表寫入文件存檔，在這個過程中會順便對動態租約表進行租期檢查。

執行回復動作：

DHCPOFFER：
靜態租用：首先匹配MAC地址，看是否能在靜態租約表中找到對應的項，若能找到就把IP分配給他。靜態表中的IP不能被其他客戶使用。
動態租用：
1.server試圖分配給client上次分配過的IP，在這之前檢查這個IP是否正在使用。
2.discover中含有request ip 時，檢查該IP是否在地址池範圍，是否正在使用，是否到期，是否是靜態IP，網絡上是否已經存在。
3.discover不含request ip，從地址池上尋找一個最小的可用IP分配。
DHCPACK: 根據是否含有request ip和server ip識別客戶端現在init_reboot,selecting,renewing/rebinding中的哪個狀態，並根據以下規則執行DHCPACK回覆：
1.若client處於selecting狀態，驗證request ip和server ip是否同伺服器中的匹配。
2.若client處於init_reboot狀態，驗證request ip是否符合租約記錄。
3.若client處於renewing/rebinding狀態，驗證client ip address是否符合租約記錄。
DHNAK:
1.請求的IP是靜態IP，但是MAC地址無法與其對應。
2.上面DHCPACK中驗證失敗。
伺服器還可能會收到其他包:
DHCPDECLINE:server會把租約表中相關client硬體地址置空，並保存這個地址一段時間。
DHCPRELEASE:清空租期回收IP。
DHCPINFORM:回復DHCPACK，數據包含有關於server的信息。

mobsF & andorid x86 emulator docker-compose.yml

version: '3'
services:
  mobsf:
    #image: "opensecurity/mobile-security-framework-mobsf:latest"
    build: /.
    container_name: mobsf
    volumes:
      - ./MobDir:/root/.MobSF
    networks:
      adb-bridge:
        ipv4_address: 172.28.0.3
    ports:
      - "8000:8000"
      - "1337:1337"
  android:
    image: "budtmo/docker-android-x86-8.1"
    container_name: android-container
    environment:
      DEVICE: "Samsung Galaxy S8"
    privileged: true
    networks:
      adb-bridge:
        ipv4_address: 172.28.0.2
    ports:
      - "6080:6080"

networks:
  adb-bridge:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/24

[Cisco] 網路流量側錄功能教學-SPAN( Switched Port Analyzer)

如果有封包側錄或偵測是否網路是否有異常行為的的需求，可能會需要用到複製流量的功能，這時候SPAN就登場啦!

什麼是Mirror Port?

好一點的Switch大多內建有流量側錄功能

一般稱為Port Mirroring、Port Monitoring或Mirror Port。

在Cisco的流量側錄功能稱作 : SPAN( Switched Port Analyzer)

SPAN可以設定要把指定的Port都複製一份流量到另一個的Port上 ,還可以設

定只要複製進或出的流量。

舉例來說，SW 的Port 1接著對內外的流量，我想要側錄這段分析，

所以我可以將Port 1進與出的流量都複製一份到Port 2並將錄製或監控封包的

設備接到Port 2，完全不需要插拔線路。

接下來介紹一下Cisco 的交換器做流量側錄指令。

Command:

switch> enable
switch> show ip interface brief
switch# conf t

進入Global configuration mode 後

config# monitor session 1 source interface Fa0/2 both

// config# monitor session [自定義代號] [來源或目的地] interface [介面代號] [錄製進來流量或出去流量又或者全部]

這裡的來源=source =被監聽的port

反之目的地就是把監聽的port流量要丟到哪個port出去

你也可以選擇多個來源port要錄製:

monitor session 1 source interface fa0/11–12 , Fa1/13

//介面2–13與15都被複製一份流量

monitor session 1 source interface fa0/2 , fa0/4

//介面fa0/2 與 4 被複製

設定複製到指定Port:

config# monitor session 1 destination interface fa1/15

示意圖(Port的設定不同):

check一下設定值是否正確

1.退回P mode : exit

2. Show monitor session [號碼] or show monitor

show monitor session 1

舉例:

要移除SPAN的設定，只要在Global configuration mode下設定來源與目的的指令前面加上no

no monitor session 1

若您喜歡我的文章，歡迎按下「拍手」與Liker按讚給我支持並轉發給你的朋友們(可以多拍幾下手喔)，或是「Follow」我，讓我提供更多文章給您。

另外可以加入我的LinkedIn 希望認識各位閱讀者

加入後歡迎跟我打招呼認識一下我每年都會參加社群

例如HITCON或COSCUP 樂意認親

其他聯絡方式 : https://kuronetwork.me/contact/

所有文章: https://kuronetwork.me/posts/

free5gc /5gc

https://zhuanlan.zhihu.com/p/138629674

https://weiyu.dev/free5gc-ueransim-5g/

https://www.free5gc.org/

https://github.com/III-5GC/III-5GC.github.io

LTE基本架构

https://blog.csdn.net/starperfection/article/details/78719935?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522164005640816780271512265%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=164005640816780271512265&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~baidu_landing_v2~default-1-78719935.first_rank_v2_pc_rank_v29&utm_term=LTE+%E6%9E%B6%E6%A7%8B&spm=1018.2226.3001.4187

这篇文章主要介绍LTE的最基础的架构，包括LTE网络的构成，每一个网络实体的作用以及LTE网络协议栈，最后还包括对一个LTE数据流的模型的说明。

LTE网络参考模型

这是一张非常有名的LTE架构图，从图中可以看出，整个网络构架被分为了四个部分，包括由中间两个框框起来的E-UTRAN部分和EPC部分，还有位于两边的UE和PDN两部分。
在日常生活中，UE就可以看作是我们的手机终端，而PDN可以看作是网络上的服务器，E-UTRAN可以看作是遍布城市的各个基站（可以是大的铁塔基站，也可以是室内悬挂的只有路由器大小的小基站），而EPC可以看作是运营商（中国移动/中国联通/中国电信）的核心网服务器，核心网包括很多服务器，有处理信令的，有处理数据的，还有处理计费策略的等等。
下面详细地介绍每一个组件的名称与作用

UE
全称是User Equipment，用户设备，就是指用户的手机，或者是其他可以利用LTE上网的设备。

eNB
是eNodeB的简写，它为用户提供空中接口（air interface），用户设备可以通过无线连接到eNB，也就是我们常说的基站，然后基站再通过有线连接到运营商的核心网。在这里注意，我们所说的无线通信，仅仅只是手机和基站这一段是无线的，其他部分例如基站与核心网的连接，基站与基站之间互相的连接，核心网中各设备的连接全部都是有线连接的。一台基站(eNB)要接受很多台UE的接入，所以eNB要负责管理UE，包括资源分配，调度，管理接入策略等等。

MME
是Mobility Management Entity的缩写，是核心网中最重要的实体之一，提供以下的功能：

NAS 信令传输
用户鉴权与漫游管理（S6a）
移动性管理
EPS承载管理
在这里所述的功能中，NAS信令指的是三层信令，包含EMM, ESM 和NAS 安全。然后移动性管理的话主要有寻呼，TAI管理和切换。承载的话主要是EPS 承载（bearer）的建立，修改，销毁等。

S-GW
是Serving Gateway 的缩写，主要负责切换中数据业务的传输。

P-GW
是PDN Gateway的缩写，其中PDN是Packet Data Network 的缩写，通俗地讲，可以理解为互联网，这是整个LTE架构与互联网的接口处，所以UE如果想访问互联网就必须途径P-GW实体，从另外一方面说，如果想通过P-GW而访问互联网的话，必须要有IP地址，所以P-GW负责了UE的IP地址的分配工作，同时提供IP路由和转发的功能。此外，为了使互联网的各种业务能够分配给不同的承载，P-GW提供针对每一个SDF和每一个用户的包过滤功能。（也就是说在P-GW处，进出的每一个包属于哪个级别的SDF和哪一个用户都已经被匹配好了。这里的SDF是服务数据流Service Data Flow的缩写，意思就是P-GW能区分每一个用户的不同服务的数据包，从而映射到不同的承载上去。以后会有关于SDF的更详细的说明）。此外，P-GW还有其他的一些功能，比如根据用户和服务进行不同的计费和不同的策略，这部分对于每个运营商都会有差异，在此不做多的赘述。

HSS
是Home Subscriber Server的缩写，归属用户服务器，这是存在与核心网中的一个数据库服务器，里面存放着所有属于该核心网的用户的数据信息。当用户连接到MME的时候，用户提交的资料会和HSS数据服务器中的资料进行比对来进行鉴权。

PCRF
是Policy and Charging Rules Function的缩写，策略与计费规则，它会根据不同的服务制定不同的PCC计费策略。

SPR
是Subscriber Profile Repository的缩写，用户档案库。这个实体为PCRF提供用户的信息，然后PCRF根据其提供的信息来指定相应的规则。（这个我也不是很明白其具体内容）

OCS
是Online Charging System 的缩写，在线计费系统，顾名思义，应该是个用户使用服务的计费的系统

OFCS
是Offline Charging System 的缩写，离线计费系统，对计费的记录进行保存。

上面介绍完了图中所有的实体的名称以及作用，其实真实的核心网中远远不止这些实体，还有很多，鉴于我也不是很懂，在此就不多说了。

然后下面针对图中主要的几个接口说说

LTE-Uu
LTE-Uu接口是位于终端与基站之间的空中接口。在这中间，终端会跟基站建立信令连接与数据连接，信令连接叫做RRC Connection，相应的信令在SRB上进行传输，（这里，SRB有三类，分别是SRB0, SRB1和SRB2，SRB可以理解为是传输信令的管道），而数据的连接是逻辑信道，相关的数据在DRB上传输。这两个连接是终端与网络进行通信所必不可少的。

X2（控制面）
X2是两个基站之间的接口，利用X2接口，基站间可以实现SON功能（Self Organizing Network），比如PCI的冲突检测等。

S1（控制面）
S1是基站与MME之间的接口，相关NAS信令的传输都必须建立在S1连接建立的基础上。

X2（用户面）
X2用户面的接口是建立在GTP-U协议的基础上，连接两个基站，传输基站间的数据。（X2 handover等）

S1（用户面）
S1用户面的接口是建立在GTP-U协议的基础上，连接基站与MME，传输基站与MME之间的数据。（S1 handover，上网的数据流等）

剩下的接口在我个人的工作中没有接触，不是很了解，这里就不多说了。

LTE协议栈
说协议栈，就得分开从两方面来讲，分别是用户面与控制面。
先从用户面开始说起

上图是用户面的协议栈，下面详细地介绍每一个层（主要功能）

LTE-Uu 接口
PDCP
PDCP协议针对传输地数据包执行以下的操作：

数据包头压缩（ROHC）
AS层的安全（包括加密与完整性检验）
包的重排序和重传
RLC
RLC层针对传输地数据包执行以下的操作：

在发送端，提供数据包的分段与串联
在接收端，提供透明，确认模式与非确认模式三种模式
RLC层也执行对RLC PDU的重排序与重传
MAC
MAC层对从高层传来的MAC PDU和从底层传来的包做以下的处理：

在物理层和RLC层之间提供逻辑信道的连接
逻辑信道的复用与解复用
对逻辑信道根据QoS来进行调度和分配优先级
S1-U/S5/X2 接口
GTP-U
GTP-U协议主要是用来转发用户的IP数据包，GTP-U协议还有个特点，只要GTP-U连接建立后传输数据，那么在数据结束之后总会有END Marker来标志着数据流的结束。

下面是控制面的协议栈

上面是关于控制面的总图，包含了LTE-Uu，S1-MME，S11等接口的，由于本人业务限制，对其他的不了解，就只简单地介绍下面几个

LTE-Uu接口
NAS
提供移动性管理和承载管理，比如说eNB的信息的更新，或者MME的配置信息的更新会触发Configuration Update信令的下发或者上载，然后E-RAB的建立，修改，销毁都是属于NAS管理的范围之内。

RRC
RRC协议支持传输NAS信令，同时也提供对于无线资源的管理

广播系统消息，例如MIB，SIB1，SIB2 ……
RRC连接的建立，重建立，重配置和释放
无线承载(RB)的建立，修改与释放。
X2 接口
X2AP
X2AP协议支持无线网（E-UTRAN）中的UE移动性管理和SON功能。比如通过X2AP的数据转发（在X2 Handover的时候的数据转发），SN status的转发（Handover时），或者时eNB之间的资源状态消息交换等。

S1-MME
S1AP
S1AP协议如前所述，是S1 连接建立的时候用来传输信令的协议，该协议负责S1接口的管理，E-RAB的管理，还有NAS信令的传输，以及UE上下文的管理。

一个简单的例子
这里通过一个简单的例子来全盘地看一下LTE系统是怎么样运转地。

首先是从终端到Internet的方向传输，也就是我们通常所说的“上行传输”

上面这个例子记述了包从UE是怎么一步一步地通过LTE系统传输到Internet的。
首先，UE发出一个包时，包上面会打上UE的地址作为源地址，要去的因特网上的服务器的地址作为目的地址，传送给基站eNB，然后基站给包封装到GTP 隧道里可以传输的GTP包，每个包的源地址会被换成基站的地址，而目的地址则是被换成将要到达的Serving Gateway，然后，每个包也会包含他们所在传输隧道的隧道ID：UL S1-TEID。当包到达Serving Gateway时，源目地址被分别换成了Serving Gateway和P-GW的地址，同时，传输的隧道也由S1 GTP 隧道变成了S5 GTP隧道，当然隧道ID也会随之变化。最后，当包到达P-GW后，这时P-GW讲GTP解开，查看其真正的目的地址，然后将包送到互联网上。这样子就完成了一个数据包从终端的互联网的上传。

下面看一下下行的传输

下行的情况与上行的情况正好相反，经过P-GW，S-GW，eNB时会对数据包打包，在eNB处会解封装，然后直接把数据包传输给UE。
————————————————
版权声明：本文为CSDN博主「轻舞飞扬SR」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/starperfection/article/details/78719935

free5gc

https://zhuanlan.zhihu.com/p/138629674

一、前语

知乎上有个提问，“自已拥有一台服务器可以做哪些很酷的事情”，这里的服务器，可以是云服务器VPS，有人用来搭梯子翻墙，有人用来搭博客，有人用来做网盘，各种各样的用途，只要脑洞够大，借助开源软件和一定的动手能力，都可以尝试。而我之前看到一新闻说某软件厂商已经在公有云上部署了一套5GC，我也一直想试试能不能也在公有云上搭建一个实验用的5GC供个人学习和体验。随着自己对云计算和5GC的了解，这件事也逐渐进入了实施层面。

二、背景知识

首先需要把涉及的知识梳理一下。

大体上来说涉及电信网的NFV/5GC和云计算google公司开源的K8s相关知识。当然，我不会傻到用Z的5GC软件来做实验，我选择了台湾国立交通大学免费开源的free5GC/free5gmano项目进行实验。这里结合github上的介绍以及自己的理解进行说明。

1、free5GC的总体架构

free5GC/mano的总体架构和现在电信业内通用的NFV/5GC架构没有什么差别，都是用虚拟化方式实现网元功能，虚拟层由MANO、VIM对硬件资源进行管理并抽象成通用的计算、网络、存储资源供VNF使用，由VFNM对VNF生命周期进行管理，NFVO提供接口进行编排。 free5GC的VIM可支持k8s或者openstack，经个人测试，openstack太重，果断弃之使用k8s，也就是创建k8s集群的方式由k8s对硬件资源进行统一管理，将一台（或几台）主机安装成K8s控制节点，其他主机作为工作节点join到集群中承载工作负荷，其他的实体（如VNFM、NFVO、各VNF等）以k8s pod的方式进行运行。

2、K8s集群默认的POD网络结构

上面提到所有的NFV/5GC实体都以k8s pod的方式运行，这里就带来一个问题，k8s pod时所在的网络结构是怎么样的？

google在设计k8s之初，就对pod的网络结构提出了一个理念，就是pod运行时，无须pod去关心自己运行时的网络架构，在不同计算节点运行的pod之间的网络互通，无需pod去操心，由k8s虚拟出一个互通网络，pod能看到的，就是这个互通网络，这其实是通过SDN Vxlan等方式实现的。在k8s集群上，典型的安装方式下，运行一个flanneld的程序通过Vxlan虚拟出一个pod互通的网络：

如上图，HOST1/HOST2上运行的k8s pod只看到172.16.x.x段的IP，pod之间互访，也是以172.16的网段互访，由k8s运行的flannel/docker等软件对数据包进行封装、传递和解封。

那么，这就带来一个问题，pod运行时绑定的IP地址是一个虚拟出来的网络中的地址，pod之间可以这样互通，但是，pod和外部网络如何互通？在目前Z等电信设备商的方案中，是由实际运行的各个VNF的相关接口部件再定义对外互通的地址，然后通过SDN Vxlan或其他组网技术经过承载网与外部网络互通，也就是VNF是直接可见对外互通的地址的。 k8s的方案是，另外再通过一个service或ingress的方式对外暴露端口和服务，简单的一个示意图：

可以把ingress/service理解成负载均衡设备，他们负责把外部流量经过nat转换和其他处理后导入到各个pod中，这样，对于pod来说，无需关心和绑定外部地址，对于5GC VNF(如smf)的部署，如果以k8s这种方式部署的话，应该是这样：

SMF业务处理模块以POD方式运行在多个计算节点上；k8s service向外暴露smf的业务地址和端口；k8s service把外部http流量均衡转发到smf的各个pod上；

从交付的角度来说，这无疑是一种更简洁、更高效的方式，这种方式下，各个局点无需进行内部网络设计，业务地址无需直接配置在5GC VNF上，可以简单将分配的业务地址和端口写入yaml文件进行部署，各个局点处理能力不同是根据smf运行的Pod个数进行区分，可以通过k8s方便进行扩容和缩容，实现真正的弹性伸缩。

3、mults实现pod的多网卡功能

默认情况下，k8s创建的Pod只有一块网卡，虽然free5gc项目的部署完全也可以通过一块网卡的pod来进行部署，但是从不同接口的安全隔离的角度来说，即便作为一个个人实验用的5GC，也需要考虑各个接口所在的网络的隔离。那么，对于pod来说，如果只有一块网卡，虽然还是能再通过子接口等方式进行隔离，但是太麻烦，有没有更简单的方式？一块网卡不够，那就再加一块虚拟网卡呗，在k8s上，本次搭建使用的是intel提供的mults插件方式，原理图：

4、openvswitch

pod通过mults创建了多块网卡，这些新增的pod如何通过这些虚拟的网卡互通，这就要用到openvswitch，openvswitch的原理示意图：

通过openvswitch，其实创建的是一个虚拟的二层网络，比如创建一个虚拟二层网桥br1，把pod新增的虚拟网卡再绑定到这个网桥br1。

5、公有云VPS自身所在的网络结构

因为要在公有云上进行部署，还需了解公有云的云服务器VPS（虚拟化服务器）的组网方式，如下是典型的组网图：

VPS自身的网卡IP也是一个私网地址，该私网地址由云服务厂商负责进行NAT转换与公网互通；创建VPS时，云服务厂商默认也会创建一个VPC虚拟网络，实现不同部署AZ区域的VPS互通，如一台VPS创建在美国，一台VPS创建在日本，这两台VPS之间可以以私网地址在VPC内部实现互通。

三、设计和规划

本次公有云5GC的实际部署，根据github上free5GC的部署介绍，结合自身对5GC的理解，设计和规划如下：

1、VIM和硬件设计

使用2台运行Ubuntu 18.04的VPS，CPU至少1核、内存1G以上，一台作为k8s控制节点+工作节点，一台作为工作节点。当然，也可以只使用一台VPS，CPU 2核+内存2G以上，同时作为k8s控制节点+工作节点。

本次使用GCP(谷歌云平台）的免费账号创建VM作为底层硬件平台。

2、组网设计
本次设计的组网图：

要点：

GCP VPS上启用两个VPC内部网络：VPC网络1关联公网地址，作为amf/upf对外对接的公网地址；VPC网络2仅限于内部通讯，作为k8s控制程序和k8s内部各组件通讯的网络平面； POD网络1为k8s用flanneld虚拟出的pod互相访问的网络平面，mano、nfvo、数据库、5gc网元都连接到此网络平面； vswitch网络为用vswitch虚拟出的网络，br1设置IP地址为该网络的网关，作为5gc网元http访问的业务网络； 不要被上图给吓坏了，其实组网非常简单，全是程序虚拟出来的逻辑网络，严格来说应该叫子网（即只有一个逻辑网络），这些子网内的地址是可以互通的。

3、IP地址等逻辑资源规划

说明：amf、upf本次不通过k8s部署，直接编译后运行，主要是考虑到，这两个网元需要对外通讯，如果是通过k8s部署，实际上需要调用iptables 进行nat转换，在进入VM之前，已经有一次GCP防火墙的nat转换，如果在ubuntu iptables上再进行一次转换，既影响性能且iptables对sctp的nat转换支持并不是很好。当然，amf、upf也完全可以通过k8s部署（注意在k8s初始化时选择支持SCTP）。

四、实际部署过程

根据上面的规划，实际部署过程（以下示例仅以单机部署为例）是：

1、gcp部署VM

在gcp上另外部署一个VPC网络，VM虚拟机创建时关联这两个VPC网络，选择ubuntu 18.04操作系统，cpu 2核、2.5G内存、20G硬盘，具体创建过程很简单，这里就不细说了。

2、更换ubuntu的Linux内核到5.0.0-23-generic

由于upf运行必须使用5.0.0-23-generic的linux内核，首先进行linux内核跟换，具体指令：

apt-get update

apt-get install linux-image-5.0.0-23-generic

apt-get install linux-headers-5.0.0-23-generic

dpkg –get-selections |grep linux-image //检查安装的内核

sudo apt-get remove xxx//移除多余内核

update-grub //更新启动项

reboot

3、安装docker

在升级好内核的VM上安装docker，具体指令：

sudo apt-get -y install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add –

sudo apt-key fingerprint 0EBFCD88

sudo add-apt-repository “deb [arch=amd64] Index of linux/ubuntu/ $(lsb_release -cs) stable"

sudo apt-get update

sudo apt-get -y install docker-ce docker-ce-cli containerd

4、安装k8s并初始化集群

安装好docker后，即可开始安装k8s和初始化集群，具体指令：

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add –

cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

EOF

sudo apt-get update

apt-get install -y kubelet kubeadm kubectl

kubeadm init –apiserver-advertise-address=xx.xx.xx.xx –pod-network-cidr=10.244.0.0/16 //pod网络地址段

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml //安装flanneld

5、安装openvswitch和ovs-cni容器多端口插件

后续步骤所有配置脚本我都已发布在github上，可git clone本地后执行。

git clone zhujq/free5gc-s3-docker

apt install openvswitch-switch -y

ovs-vsctl add-br br1

kubectl apply -f ovs-cni.yaml

kubectl apply -f ovs-net-crd.yaml

//br1的IP地址设置为192.168.3.254/23，作为k8s 5gc网元的vswitch网口的网关

vi /etc/netplan/50-cloud-init.yaml

//修改50-cloud-init.yaml设置br1 ip地址

sudo netplan apply

6、安装 etcd-operator 和 Node Exporter

cd etcd-cluster/rbac/

./create_role.sh

cd ..

kubectl apply -f ./

cd ..

kubectl apply -f prom-node-exporter.yaml

7、部署mysql、mano、nfvo

kubectl apply -f service-account-agent.yaml

kubectl apply -f mysql-agent.yaml

kubectl apply -f kube5gnfvo.yaml

kubectl apply -f 5gmano-deploy.ymal

8、部署除AFM/UPF外的5GC

可以借助free5GC项目的mano进行5GC网元的实例化部署，也就是根据提供的mano接口进行5gc网元的VNFD定义、模板导入等后，由mano调用k8s接口进行部署，free5gc的mano的接口目前仅支持命令行接口，这里我就跳过mano，直接编写k8s yaml文件进行部署。具体指令：

kubectl apply -f unix-daemonset.yaml

kubectl apply -f free5gc-mongodb.yaml

kubectl apply -f free5gc-configmap.yaml

kubectl apply -f free5gc-nrf.yaml

kubectl apply -f free5gc-ausf.yaml

kubectl apply -f free5gc-smf.yaml

kubectl apply -f free5gc-nssf.yaml

kubectl apply -f free5gc-pcf.yaml

kubectl apply -f free5gc-udm.yaml

kubectl apply -f free5gc-udr.yaml

9、部署amf/upf

sudo sysctl -w net.ipv4.ip_forward=1 //启用Ipv4转发

sudo iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE //iptables nat配置

git clone PrinzOwO/gtp5g

cd gtp5g

make

sudo make install

//amf、upf编译过程省略

编译完成后改好配置文件中的ip地址等信息后直接运行：

nohup ./amf &

nohup ./upfd &

10、谷歌云VPC防火墙放通SCTP等对外暴露的协议和端口

11、部署后的效果

运行的各pod和主机上的路由：

amf、upf绑定的端口：

经模拟工具测试，到AMF偶连建立正常，到UPF GTP Echo测试正常。

五、总结

本次在公有云的5GC部署实践，对个人来说，在体验了一种原生态的NFV/5GC产品后，对NFV/5GC的理解，当然可以更本质、更全面，可以更清晰地看到mano/5gc这些具体实体是如何协同工作的。github上有free5gc项目的go源码，有时间的话，可以仔细去看VNF是怎么划分各个模块以及具体实现的。

MANO、5GC目前已完全软件化，换句话说，它们和nginx、office这种软件没有什么差别。软件和硬件的本质差异是什么，就个人理解，软件相比硬件，最明显的一点区别是，软件可以无成本的复制。就free5gc这个项目来说，虽然从功能和商用角度来说，显然它很原始，但是，从软件角度来看，它比目前像Z公司这样的传统电信设备商提供的5GC更符合目前云计算的趋势。参照上面的步骤（甚至可以整理成批处理脚本自动运行），基本上可以在一小时内搭建出一套5GC出来，如果需要大量的计算节点，也很easy，一条指令加入k8s集群（成百上千台物理服务器加到集群进来也是很容易的事情），然后通过k8s service进行内部VNF在计算节点的负载均衡。更重要的是，这种部署方式是完全可复制的，就是说在A大区这样布置，在B大区可以完全复制过去，仅需要简单修改k8s servcie yaml对外暴露的端口和地址即可，它对于底层物理网络的需求是非常简单的，因为已经通过程序在逻辑上进行了网络组网。这就像一套office，你从来不用关心office在什么样的物理组网下才能很好地运行，安装很简单，这样，对现场交付来说，可以把精力都放在5GC具体业务上而不是把耗费大量精力花在如何部署5GC上。

六、附录

free5GC项目网址：https://github.com/free5gc

free5GMANO网址：https://github.com/free5gmano

个人本项目的输出：https://github.com/zhujq/free5gc-s3-docker

docker script

portainer – docker linux gui

docker volume create portainer_data

docker run -d -p 8000:8000 -p 9443:9443 –name portainer \
–restart=always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
cr.portainer.io/portainer/portainer-ce:2.9.3

Burpsuite 1.7 pro crack

https://www.52pojie.cn/thread-691448-1-1.html

java -Xbootclasspath/p:burp-loader-keygen.jar -jar burpsuite_pro_v1.7.37.jar

systemd ubuntu

docker run -d –name systemd-ubuntu –privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro jrei/systemd-ubuntu

openvas docker

docker run -d -p 443:443 --name openvas mikesplain/openvas

月份: 十二月 2021

Kubernetes 30天學習筆記

UE+gNB+free5GC.setup