Category: Tech

  • 如何流暢的觀看奈飛

    最近一段時間糾結於看奈飛的問題,因為服務提供商很不穩定。

    現在的方案是,一台美國VPS,再購買一個解鎖服務,一個月的成本大概是5美金加上15元人民幣,總計一個月支出50元人民幣.

    如果辦理一張亞太電信的4G吃到飽,一個月199台幣,大約是46元人民幣,但是,就需要額外的配置,大約需要一台4G路由器,一台VPN路由器,一台可以運行代理的Server,恰好這些東西我手裡都有。

    拓撲圖如下所示,位於台北的4G路由器,提供網絡接入,NS5GT防火牆通過VPN連結到我位於拉斯維加斯的服務器,這一條VPN是固定的,主要用於遠程調試在台北的這台防火牆。

    為什麼?

    因為通過4G網路上網時,並不會分配公網IP地址,那麼位於台北的防火牆只能發起主動連結到拉斯維加斯,透過拉斯維加斯的服務器,我們現在增加一條VPN,從台北到上海的服務器,這一條VPN,由於大陸地區的不穩定性,可能會更換不同的服務器,所以才會有拉斯維加斯的那條VPN來進行保障性連結。

    當台北到上海的VPN連結成功建立後,我再從本地防火牆,建立一條到上海的VPN,在上海的這台服務器上,運行了相關代理和轉發,將互聯網請求通過VPN轉發到位於台北的Mini Proxy Server,完成觀看奈飛的任務。

    這個方案其實有很多隱性成本,例如,拉斯維加斯的服務器,上海的服務器,這都是我手裡現有的資源,一般人不太適用。

    如果使用類似於花生殼之類的內網穿透服務,可以免去拉斯維加斯服務器的這個角色,因為透過花生殼就可以直接對位於台北的防火牆配置進行修改。

    如果這個方案中,4G上網修改為寬頻上網,方案就會變得更簡單一些,因為台灣目前主要的寬頻服務都提供有免費的固定IP地址,可以免去上海的中轉服務器,和拉斯維加斯的調測服務器,從本地直接發起連結到台北就可以。但是,台灣的寬頻上網價格實在是,60M/20M的寬頻一個月至少要800台幣,比起大陸來還真是有點貴。

  • 更換家用防火牆,從NS5GT升級到SSG5

    更正:經過查閱資料和詢問各路英雄,我發現SRX110H的VPN性能低下是因為它默認使用了較高的mtu,當修改VPN鏈路的mtu為1350左右時,VPN吞吐可以得到極大提升,接近其標稱的數值。

    但是SRX110H的體積實在是太大了,發熱量也很高,我還是決定繼續使用SSG5。——2020/03/08

    最近糾結於觀看YouTube的速度,台灣大選完全沒有影響到中國網封天下的形勢,但這網絡總是時不時的卡一卡,我認真的想了想,可能是防火牆的VPN速度不夠,現在使用的防火牆是Juniper NS5GT,這是一款Netscreen被Juniper收購後,銷量極高的中小企業百兆防火牆,當年買它也是機緣巧合,我最早使用的企業級防火牆是思科的Pix501,它很好用,但是有一天,我多了一條鏈路,Pix501不支持雙線接入,我本來想繼續走思科的路線,但是挑選了許久,我實在是難以接受ASA5505非常醜陋的外形設計,反而發現了NS5GT,小巧而精緻,不但具備雙線接入能力,而且第一次讓我認識到session數量並不是防火牆的決定性標準,秒開session數量才是,可以毫不客氣的說,同樣參數標準下的防火牆,Netscreen一定是強於Cisco的。

    NS5GT安靜的服務了五年多的時間,作為一款十幾年前的防火牆產品,真是典範啊,經過認真的考察和研究,我打算換上SRX110,等等,

    我之前換過一款SRX100,花了我六百塊,但是沒折騰多久,它就掛掉了,時至今日,在研究了SRX110,查閱了大量文章後,我才明白為什麼,因為Juniper的新款SRX防火牆系列,使用的SRX系統和以前的設計不一樣,它不但繼承了FreeBSD的穩定性,也繼承了FreeBSD掉電壞磁盤的特性,我早前購買的SRX100正是在我無數次非正常斷電後掛掉的,我完全沒有想過,為什麼SRX系列防火牆要設計一個電源開關按鈕,現在我明白,正常關閉SRX系列防火牆,必須,必須,必須要正常關機,或者按一下電源按鈕,等待關機後再拔除電源,否則,可能出現板載flash損壞再也無法讀取的問題。

    在更換了SRX110之後,觀看YouTube的情況似乎改善不多,它的參數標稱VPN流量可以達到65M,但是我覺得不像,於是我做了一個測試,在我家和最近的大陸服務器之間建立一條ipsec VPN鏈路,然後使用iperf3測速,結果是讓人十分震驚的,SRX110的VPN吞吐量達不到它的標稱值,反而是NS5GT超過了它的標稱值,難道是ScreenOS和JunOS的差異?折騰了一段時間,情況無法得到改善,SRX110的配置是不錯,除去VPN功能,它依然是一款不錯的企業級防火牆,但是,我需要的功能它不能滿足。

    於是我更換了一台SSG5,它也是屬於Netscreen系列的產品,同樣是一款銷量極高的中小企業百兆防火牆,作為NS5GT的升級產品出現,觀察他們的參數,具有很明顯的設計性,在我測試完SSG5的ipsec VPN吞吐之後,我覺得,SRX的JunOS雖然語法非常優美,但是它的VPN就是渣,當然,這完全有可能是因為產品線的設計而故意讓它性能這麼低,但是,SRX是作為Netscreen系列的升級產品出現的,既然是升級,為什麼性能反而下降了呢?

    一些數據如下,供參考,SRX210和SRX300只是列了一下標稱參數,

    NS5GT:最大吞吐流量標稱70M,實測85M,VPN吞吐標稱20M,實測33M,普通版最大併發數2064,擴展版最大併發數4064

    SSG5:最大吞吐流量標稱90M,實際沒測,VPN吞吐標稱40M,實測52M,普通版最大併發數8064,擴展版最大併發數16064

    SRX110H:最大吞吐流量標稱200M(聚合端口),實際沒測,VPN吞吐標稱65M,實測42M,最大併發數32000

    從防火牆可以容納的併發數量,可以很明顯的看出來Juniper在產品階梯設計上的習性,總之,經過測試,我決定使用SSG5作為家用防火牆,NS5GT退役,SRX110先閒置起來,也許是我沒有搞清楚人家的配置呢?

    這次升級,防火牆最大併發數量從4064升級到16064,ipsec VPN吞吐從33M升級到52M,看YouTube果然要流暢多了……


    Product Name: NetScreen-NS5GT
    Serial Number: 0082024004008983, Control Number: 00000000
    Hardware Version: 1010(0)-(00), FPGA checksum: 00000000, VLAN1 IP (0.0.0.0)
    Software Version: 6.2.0r19.0, Type: Firewall+VPN
    Compiled by build_master at: Fri Dec 11 02:35:32 PST 2015
    Base Mac: 0010.cb88.5a62
    File Name: screenos_image, Checksum: c1dac30a

    Sessions: 4064 sessions
    Capacity: unlimited number of users
    NSRP: Lite
    VPN tunnels: 25 tunnels
    Vsys: None
    Vrouters: 3 virtual routers
    Zones: 8 zones
    VLANs: 10 vlans

    Product Name: SSG5-Serial
    Serial Number: 0146074030008273, Control Number: 00000000
    Hardware Version: 0710(0)-(00), FPGA checksum: 00000000, VLAN1 IP (0.0.0.0)
    Flash Type: Samsung
    Software Version: 6.3.0r26.0, Type: Firewall+VPN
    Feature: AV-K
    BOOT Loader Version: 1.3.3
    Compiled by build_master at: Tue Jul 10 02:06:00 PDT 2018
    Base Mac: 8072.2d1f.3a00
    File Name: ssg5ssg20.6.3.0r26, Checksum: ea1ccba7
    , Total Memory: 256MB

    Sessions: 16064 sessions
    Capacity: unlimited number of users
    NSRP: ActiveActive
    VPN tunnels: 40 tunnels
    Vsys: None
    Vrouters: 4 virtual routers
    Zones: 10 zones
    VLANs: 50 vlans

  • IPsec是什么

    https://en.wikipedia.org/wiki/IPsec
    https://www.cisco.com/c/en/us/td/docs/net_mgmt/vpn_solutions_center/2-0/ip_security/provisioning/guide/IPsecPG1.html
    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-ipsec-vpn-overview.html
    http://www.h3c.com/cn/d_200812/624140_30003_0.htm
    https://www.cnblogs.com/lolau/p/8746601.html

    IPsec(IP Security)是一系列为IP通信提供安全性的协议和服务的集合,工作在IP层,可以为上层协议和应用提供透明的安全服务。IPsec提供两种安全机制:认证和加密。

    认证机制使IP通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。
    加密机制通过对数据进行加密运算来保证数据的机密性,以防数据在传输过程中被窃听。

    IPsec提供的安全保护包括:

    用户数据加密,通过加密算法提供好数据私密性。
    消息完整性验证,通过摘要认证确保数据在传输路径上未经修改。
    防御特定类型攻击,通过序列号防数据重放、通过认证防中间人攻击。
    提供设备之间安全算法和秘钥的协商能力,提供安全的在线秘钥生成机制。
    提供隧道和传输两种模式,满足不同的网络结构需求。

    IPsec出现的原因
    网络安全问题日益严重,需要保证数据在网络上的传输是安全的。
    大多数保证数据安全的协议或技术都是在应用层,如SSL协议可以为WEB或FTP提供安全连接,但对于ping、Telnet、SNMP等无效。需要在IP层提供安全性的方法,可以使在传输层上层的所有协议受益。

    IPsec相关概念

    IPsec协议不是一个单独的协议,它给出了应用于IP层上网络数据安全的一整套体系结构,包括网络认证协议AH(Authentication Header,认证头)、ESP(Encapsulating Security Payload,封装安全载荷)、IKE(Internet Key Exchange,因特网密钥交换)和用于网络认证及加密的一些算法等。其中,AH协议和ESP协议用于提供安全服务,IKE协议用于密钥交换。

    SA(Security Association,安全关联):为安全目的创建的一个单向逻辑连接,所有经过同一个SA的数据流会使用相同的安全处理协议(AH或ESP)。对同一个数据流同时使用AH和ESP时需要两个嵌套的SA。双向的数据流需要通信实体之间维护一对出入彼此呼应的SA。

    SPD(Security Association Database,安全关联数据库):用于存放与SA关联的所有状态数据的存储结构。

    SPI(Security Parameters Index,安全参数索引):一个被携带在AH或ESP报文头中的32bit数值,用于在接收端识别数据流到SA的绑定关系。

    SPD(Security Policy Database,安全策略数据库):指明所有IP数据报文应该使用何种安全服务,以及如何获得这些服务的数据结构。SPD是一个有序的结构,用访问控制列表来描述数据流特性。

    AH(Authentication Headers,认证头协议):提供数据来源认证,数据完整性校验,保护通信免受篡改,但不能防止窃听,适合于传输非机密数据。AH协议使用事先协商好的算法和密钥计算报文数据部分的摘要值,然后作为报文完整性的证据保存在AH的头结构中。

    ESP(Encapsulating Security Payloads,封装安全载荷协议):提供加密,数据源校验,数据完整性校验。ESP协议将原始报文加密后作为负载携带在报文中。

    IKE(Internet Key Exchange,因特网密钥交换协议):用于动态建立SA,SA有生命周期,如果安全策略要求建立安全、保密的连接,但又不存在与该连接相应的SA,IPSec会立刻启动IKE来协商SA。

    ISAKMP(Internet Security Association Key Management Protocol,安全联盟密钥管理协议):定义了协商、建立、修改和删除SA的过程和包格式,只是提供了一个通用框架,并没有定义具体的SA格式,与IKE独立,可以被不同的密钥交换协议使用。IKE使用ISAKMP消息来协商并建立SA。

    注:由于AH提供数据来源确认,一旦源IP地址改变,AH校验失败,无法穿越NAT(NAT穿越在大陆的网络环境中显得尤为重要)。

    认证算法与加密算法

    认证算法

    认证算法的实现主要是通过杂凑函数。杂凑函数是一种能够接受任意长的消息输入,并产生固定长度输出的算法,该输出称为消息摘要。IPsec对等体计算摘要,如果两个摘要是相同的,则表示报文是完整未经篡改的。IPsec使用两种认证算法:

    MD5:MD5通过输入任意长度的消息,产生128bit的消息摘要。

    SHA-1:SHA-1通过输入长度小于2的64次方bit的消息,产生160bit的消息摘要。

    MD5算法的计算速度比SHA-1算法快,而SHA-1算法的安全强度比MD5算法高。

    加密算法

    加密算法实现主要通过对称密钥系统,它使用相同的密钥对数据进行加密和解密。目前大多数IPsec设备实现三种加密算法:

    DES(Data Encryption Standard):使用56bit的密钥对一个64bit的明文块进行加密。

    3DES(Triple DES):使用三个56bit的DES密钥(共168bit密钥)对明文进行加密。

    AES(Advanced Encryption Standard):使用128bit、192bit或256bit密钥长度的AES算法对明文进行加密。

    这三个加密算法的安全性由高到低依次是:AES、3DES、DES,安全性高的加密算法实现机制复杂,运算速度慢。对于普通的安全要求,DES算法就可以满足需要。

    IKE简介

    在实施IPsec的过程中,可以使用IKE(Internet Key Exchange,因特网密钥交换)协议来建立SA,该协议建立在由ISAKMP(Internet Security Association and Key Management Protocol,互联网安全联盟和密钥管理协议)定义的框架上。IKE为IPsec提供了自动协商交换密钥、建立SA的服务,能够简化IPsec的使用和管理,大大简化IPsec的配置和维护工作。

    IKE不是在网络上直接传输密钥,而是通过一系列数据的交换,最终计算出双方共享的密钥,并且即使第三者截获了双方用于计算密钥的所有交换数据,也不足以计算出真正的密钥。

    IKE的安全机制
    IKE具有一套自保护机制,可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA。

    数据认证
    数据认证有如下两方面的概念:

    身份认证:身份认证确认通信双方的身份。支持两种认证方法:预共享密钥(pre-shared-key)认证和基于PKI的数字签名(rsa-signature)认证。

    身份保护:身份数据在密钥产生之后加密传送,实现了对身份数据的保护。

    DH
    DH(Diffie-Hellman,交换及密钥分发)算法是一种公共密钥算法。通信双方在不传输密钥的情况下通过交换一些数据,计算出共享的密钥。即使第三者(如黑客)截获了双方用于计算密钥的所有交换数据,由于其复杂度很高,不足以计算出真正的密钥。所以,DH交换技术可以保证双方能够安全地获得公有信息。

    PFS
    PFS(Perfect Forward Secrecy,完善的前向安全性)特性是一种安全特性,指一个密钥被破解,并不影响其他密钥的安全性,因为这些密钥间没有派生关系。对于IPsec,是通过在IKE阶段2协商中增加一次密钥交换来实现的。PFS特性是由DH算法保障的。

    IKE的交换过程

    IKE使用了两个阶段为IPsec进行密钥协商并建立SA:

    第一阶段,通信各方彼此间建立了一个已通过身份认证和安全保护的通道,即建立一个ISAKMP SA。第一阶段有主模式(Main Mode)和野蛮模式(Aggressive Mode)两种IKE交换方法。

    Main mode交换方法

    第二阶段,用在第一阶段建立的安全隧道为IPsec协商安全服务,即为IPsec协商具体的SA,建立用于最终的IP数据安全传输的IPsec SA。

    IKE在IPsec中的作用
    因为有了IKE,IPsec很多参数(如:密钥)都可以自动建立,降低了手工配置的复杂度。

    IKE协议中的DH交换过程,每次的计算和产生的结果都是不相关的。每次SA的建立都运行DH交换过程,保证了每个SA所使用的密钥互不相关。

    IPsec使用AH或ESP报文头中的序列号实现防重放。此序列号是一个32比特的值,此数溢出后,为实现防重放,SA需要重新建立,这个过程需要IKE协议的配合。

    对安全通信的各方身份的认证和管理,将影响到IPsec的部署。IPsec的大规模使用,必须有CA(Certificate Authority,认证中心)或其他集中管理身份数据的机构的参与。

    IKE提供端与端之间动态认证,IKE是UDP之上的一个应用层协议,是IPsec的信令协议;

    IKE为IPsec协商建立SA,并把建立的参数及生成的密钥交给IPsec;

    IPsec使用IKE建立的SA对IP报文加密或认证处理。

    IPsec的工作原理

    封装模式

    传输模式(transport):只对IP数据报的数据部分进行加密,在原始IP报文头部与上层协议之间插入AH或ESP协议头。适用于主机到主机方式报文的处理。

    隧道模式(tunnel):对整个IP数据报进行加密,增加新IP头部而将原始IP数据包包括头部都作为负载。适用于转发设备上做封装处理的场景。

    两者的区别在于 IP 数据报的 ESP 负载部分的内容不同。在隧道模式中,整个 IP 数据报都在 ESP 负载中进行封装和加密。当这完成以后,真正的 IP 源地址和目的地址都可以被隐藏为 Internet 发送的普通数据。这种模式的一种典型用法就是在防火墙-防火墙之间通过虚拟专用网的连接时进行的主机或拓扑隐藏。

    安全协议数据封装格式

    工作流程

    两个IPsec实体之间的IKE协商分为两个阶段:

    第一阶段:建立ISAKMP SA

    两种模式:

    主模式(main mode):6条ISAKMP消息交互
    积极模式(aggressive mode):3条ISAKMP消息交互

    ISAKMP SA为第二阶段的ISAKMP消息提供安全保护

    第二阶段:建立IPsec SA

    一种模式:
    快速模式(quick mode):3条ISAKMP消息交互
    IPSec SA为IP数据提供安全保护
    ISAKMP报文头格式

    cookie: 用于帮助通信双方确认一个ISAKMP报文是否真的来自对方,对于一个SA,cookie是唯一的,即在协商过程中,cookie不能改变。cookie由各自实体的机密信息生成,该机密信息不能通过cookie推到出来。

    交换类型:表示该报文所属的交换类型,通常为主模式或积极模式。

    标志 :加密位(encryp):如果是1,表示ISAKMP头部后的所有载荷都被加密了;如果是0,表示是载荷是明文,没有被加密。
    提交位(commit):用于确保在发送被保护的数据之前完成协商。

    IPsec配置步骤(下面以Cisco为例)

    定义协商第一阶段ISAKMP策略
    定义ISAKMP消息的保护策略,包括加密算法、验证算法、验证方式等。

    定义协商第二阶段IPsec SA策略

    定义IP数据的保护策略,协议是使用ESP还是AH、加密算法、验证算法、封装模式是隧道模式还是传输模式等。

    定义要被IPsec保护的数据。

    定义crypt to map

    定义IPsec SA对端通信实体,并配置协商第二阶段IPsec SA策略和保护数据。

    在出接口上调用crypt to map

    确保路由表中的路由能将被保护的数据从配置了crypt to map的出接口转发出去。

    数据包经过IPsec实体时有三种处理方式:IPsec保护、丢弃或旁路(自由穿越,不受保护)。