一

前言

ZTNA為以“網(wǎng)絡(luò)為中心”的傳統(tǒng)企業(yè)體系架構(gòu)向以“身份為中心”的新型企業(yè)安全體系架構(gòu)轉(zhuǎn)變，提供解決方案。隨著傳統(tǒng)網(wǎng)絡(luò)邊界不斷弱化，企業(yè)SaaS規(guī)?；找嬖龆?，給終端安全訪問接入創(chuàng)造了多元化的空間。其中BYOD辦公方式尤為突出，移動(dòng)化辦公確實(shí)為個(gè)人提升了效率，為組織節(jié)省了成本；但是給業(yè)務(wù)系統(tǒng)的安全接入，業(yè)務(wù)處理及時(shí)響應(yīng)上帶來了成本和挑戰(zhàn)。需要我們思考是否引入非傳統(tǒng)的技術(shù)點(diǎn)來解決用戶需求側(cè)的痛點(diǎn)，同時(shí)保障整體方案的穩(wěn)定性和可實(shí)踐性。

二

ZTNA實(shí)施過程中遇到了哪些問題

移動(dòng)化辦公場景下，特別在高鐵，地下停車場等基站變更頻繁或弱網(wǎng)等場景下，傳統(tǒng)TCP應(yīng)用接入模式下，會(huì)導(dǎo)致基于TCP創(chuàng)建的零信任通道在不斷地中斷，重新建鏈；導(dǎo)致業(yè)務(wù)訪問無法做到及時(shí)響應(yīng)，體驗(yàn)性很差。

ZTNA解決方案上特別提到了單包授權(quán)；而單包授權(quán)雖然解決了防火墻端口必須要默認(rèn)打開的弊端；需要先敲門后授權(quán)，減少業(yè)務(wù)系統(tǒng)的網(wǎng)絡(luò)攻擊面。但是單包授權(quán)在應(yīng)用過程中，還是存在需要改進(jìn)的點(diǎn)：

●單包授權(quán)模式下，業(yè)務(wù)報(bào)文往往都會(huì)伴隨著有敲門報(bào)文；UDP敲門報(bào)文必須要鑒權(quán)成功，打開相應(yīng)業(yè)務(wù)端口，業(yè)務(wù)報(bào)文才能具備有效性。往往實(shí)際落地過程中，由于中間轉(zhuǎn)發(fā)設(shè)備多路徑，以及QoS等問題，首個(gè)SYN包握手大概率失敗，增加了訪問時(shí)延。

●同時(shí)傳統(tǒng)單包敲門還有一個(gè)問題，就是無法解決nat網(wǎng)絡(luò)場景，導(dǎo)致敲門放大問題。帶來了網(wǎng)絡(luò)不確定性。而傳統(tǒng)模型下，只能借助縮小敲門有效時(shí)間來應(yīng)對。

如何來解決上述問題，提升ZTNA解決方案的穩(wěn)定性？我們最終選用QUIC協(xié)議來保障。

三

QUIC是什么

QUIC(Quick UDP Internet Connection)最開始是由Google提出的一個(gè)基于UDP的傳輸協(xié)議，為了解決傳統(tǒng)tcp協(xié)議固 有的性能瓶頸，它是下一代互聯(lián)網(wǎng)協(xié)議HTTP/3的底層傳輸協(xié)議。除了應(yīng)用于Web領(lǐng)域，它同樣適用于一些通用的需要低延遲、高吞吐特性的傳輸場景。IETF推進(jìn)其標(biāo)準(zhǔn)化工作，2021 年，QUIC 協(xié)議的正式標(biāo)準(zhǔn)化版本 RFC9000 發(fā)布。

四

選型QUIC的優(yōu)勢體現(xiàn)點(diǎn)

1. 握手建鏈相比較傳統(tǒng)TCP更快

QUIC建鏈時(shí)間大約0~1 RTT，其在兩方面做了優(yōu)化：●傳輸層使用了UDP，相比TCP需要三次握手，減少了1個(gè)RTT延遲?！馫UIC底層使用tls1.3進(jìn)行加密通信，相比tls1.1和tls1.2， 通過ClientHello和ServerHello的擴(kuò)展進(jìn)行密鑰交換，省去了1.2版本中KeyExchange的過程，又省去了一次握手。

2. 支持連接遷移

相比傳統(tǒng)的TCP使用5元組來區(qū)別一個(gè)連接，QUIC在握手階段隨機(jī)生成connection id，不在通過五元組來區(qū)分，這樣當(dāng)網(wǎng)絡(luò)發(fā)生改變導(dǎo)致五元組發(fā)生變化后，依舊可以通過握手階段的connection id關(guān)聯(lián)連接。

3. 可插拔的擁塞控制

QUIC在應(yīng)用層協(xié)議實(shí)現(xiàn)了Cubic、BBR、Reno等擁塞控制算法，用戶可以根據(jù)不同的網(wǎng)絡(luò)場景選擇合適的擁塞控制算法，也可以自己實(shí)現(xiàn)私有的擁塞控制算法。

4. 避免隊(duì)首阻塞的多路復(fù)用

QUIC 一個(gè)連接支持多個(gè) stream，stream之間相互獨(dú)立，一個(gè)stream丟了一個(gè)packet，并不影響其他stream。

5. 解決弱網(wǎng)場景

● tcp重傳報(bào)文導(dǎo)致rtt無法準(zhǔn)確計(jì)算?！?tcp擁塞控制在丟包場景會(huì)進(jìn)行退讓，導(dǎo)致發(fā)生窗口減少，但丟包有可能是網(wǎng)絡(luò)狀況差，不一定是發(fā)生擁塞。

五

QUIC落地ZTNA場景下實(shí)踐效果

1. 確認(rèn)通道穩(wěn)定性明顯提升

從上圖表面，當(dāng)網(wǎng)絡(luò)發(fā)生切換后，零信任通道還是可以正常使用，不需要重新連接。

2. 確認(rèn)訪問速度顯著提升

六

QUIC落地ZTNA場景下實(shí)踐效果

1. 相比較TCP服務(wù)側(cè)處理CPU偏高

相比于TCP的ack是在內(nèi)核處理，QUIC的ack報(bào)文需要從內(nèi)核提到用戶態(tài)處理，增加了額外的用戶態(tài)內(nèi)核態(tài)切換和數(shù)據(jù)拷貝，并且QUIC的ack報(bào)文也是加密的，增加了tls加解密，所以cpu負(fù)載更高。

2. 運(yùn)營商UDP流量限速

由于UDP無連接，中間設(shè)備無法進(jìn)行連接跟蹤，當(dāng)中間網(wǎng)絡(luò)帶寬瓶頸時(shí)，TCP有擁塞控制主動(dòng)讓出帶寬，而UDP沒有擁塞控制，運(yùn)營商中間設(shè)備會(huì)對UDP報(bào)文QoS限速丟包。

七

總結(jié)

技術(shù)本身均有其優(yōu)勢和劣勢，這個(gè)都是技術(shù)選型橫向比較中確實(shí)存在的。技術(shù)的落地關(guān)鍵點(diǎn)還是要來源于結(jié)合落地場景的分析，什么樣的場景或者需求驅(qū)動(dòng)力下，采用哪種技術(shù)會(huì)更加穩(wěn)妥。例如在局域網(wǎng)辦公場景下，網(wǎng)絡(luò)環(huán)境趨于穩(wěn)定，選擇QUIC驅(qū)動(dòng)力則不強(qiáng)，可以選用傳統(tǒng)TCP進(jìn)行應(yīng)用訪問建鏈即可。而我們整體ZTNA解決方案中，均具備靈活可配置，讓用戶在技術(shù)落地和用戶場景上找到最優(yōu)解。

審核編輯 黃宇