Linux中網路界面速度的調整方式

最近剛好工作上有需要, 需要針對一些網路情況不佳的裝置去做一些實驗; 但問題來了, 要在實務上去真的找到這種裝置其實蠻難的, 這時候Linux 提供了一些很好模擬的方式來對特定的網路界面模擬上述情境…

限制網路界面的速率

再做了一些快速的瀏覽以後, 看起來在Linux中主要是透過 tc 這個指令來做 traffic control, 不過社群中有人提供了一個更簡便的方式 wondershaper, 如果OS是ubuntu 的話可以用 sudo apt-get install wondershaper 就可以安裝了.

一些常見的指令範例有:

設定eth1 的download=256kbps, upload=128kbps

sudo wondershaper eth1 256 128

清除 eth1的流量設定

sudo wondershaper clear eth1

設定網路界面的packet lost 機率

這個情境下, 我們可以模擬網路掉包在不同嚴重程度的情況下的情境; 主要是透過 iptables 來達成, 可以參考以下範例:

設定來源ip為 123.123.123.123 且封包到這台電腦的 local port為 3000時, 其packet drop的機率為 5%

sudo iptables -I INPUT -s 123.123.123.123 -p tcp --dport 3000 -m statistic --mode random --probability 0.05 -j ACCEPT

reference:

使用sshuttle來連接不同環境下的機器

最近由於專案快上線了,所以頻繁的連接在不同的環境下的機器,或是監看機器的使用狀態;在這樣的使用情境下,之前有試著使用Socks5 + SwitchyOmega 的組合來連接,這樣的組合在只用來連接內網的dashboard時是蠻堪用的,但如果其它類型的連線就無法了。

每當要使用像是TCP連線到內網的機器(像是連資料庫之類的),就都要在先連一次VPN,然後才再連線;但連線完VPN以後,又要把SwitchyOmega的設定關閉,不然VPN +Socks5 + SwitchyOmega 的組合無法讓我連到特定的Dashboard…
這其實蠻惱人的,尤其是頻繁的切換使用VPN網路時,或是在開會過程中,又需要連到特定環境下的機器…

通常這問題大概可以使用幾種方式克服:

VPN – Partial Routing

若是使用OpenVPN的話可以在導入Profile時加入以下設定來讓client端可以自訂路由的規則。

route-nopull
route X.X.Y.Z 255.255.255.255

這邊的範例是只有往x.x.y.z 時才會經由vpn。

但這個方案的缺點是,同時間也只能連到一台OpenVPN 伺服器,所以代表同時間也只能連到同一個環境下的機器。

但優點就是所有TCP/UDP的封包都可以經由路由連接到那個環境下的機器。

SSH Tunnel Proxy

其實ssh 已經提供了一個方便的解決方案了,即是使用-L 這個flag,讓我們可以透過中介的jump/proxy server,讓我們的本地主機與遠端主機建立一個虛擬通道。

ssh -NL 5432:staging-postgres.your-domain.com user@jumper-server.your-domain.com

(使用-f 可以讓這個tunnel 在背景下執行。)

透過上面的指令,我們就可以執行下面的psql 指令來連接staging postgres這個資料庫。

psql -U postgres -d postgres -h 127.0.0.1 -p 5432

這個方案的缺點就是,如果有多台主機需要連的話,可能要設定多個Tunnel Proxy。

sshuttle

在Stackoverflow 上剛好看到了這篇文章,其中回應有提到了sshuttle 這個開源的專案可以透過ssh tunnel導流所有TCP的流量到遠端的jump server,也就是類似TCP Proxy的功能。

試了以後還蠻方便的,它底層的原理即是使用了ssh tunnel proxy,所以也是需要一台中介的ssh jump/proxy server。除此之外,它可以讓使用者用根據網段來轉送流量,所以基本可以解決原本在ssh tunnel proxy的一些不方便之處。

安裝

# For Mac
brew install sshuttle

# For ubuntu
sudo apt-get install sshuttle

使用上的基本指令

sshuttle -vr user@jumper-server.your-domain.com 10.0.0.0/8

上面這指令即是把所有往10.0.0.0/8的TCP流量都自動轉往jumper-server.your-domain.com上送…

Reference:

Socks5 proxy server的設定

今天跟DK開會時,他利用些片段時間分享了他的工作環境設定,主要是關於他怎麼透過設定他的環境來同時可以連接dev, stage, production的環境。
會有這個分享主要也是因為我們在切換環境時,相對較笨拙點,都是透過連接不同的vpn server來切換到不同的環境下,但同時也只能在同時間點,只能連接到某個環境。

那就來進入主題了,他分享的方式,主要是透過在本機端建立socks5 proxy server, 將對於特定目標位址的流量,proxy到遠端預先設定好的jump server,再到對應的最終目標位址。

Step 1. 建立遠端的jump server

只要遠端的server有開啟ssh server的,就已經可以當成jump server了,而我們的stag jump server 就是這樣設定的。

Step 2. 設定 ~/.ssh/config (optional)

為了更容易的連接jump server,而不用每次都打一大串的ssh 指令,我們可以把連接jump server的相關設定寫到 ~/.ssh/config下,範例如下:

Host staging_jumper
   HostName our-jump-server.com
   IdentityFile ~/.ssh/jump-server.key
   User my-username

Step 3. 在本機端啟動socks5 server

由於剛剛在上一步有設定好連接jump server時,需要的ssh user 與 key,所以這邊可以很簡單的用下面的ssh指令啟動socks5 server

ssh -D 1081 -C -N -f staging_jumper

-D 1080 代表要將連往本機端 port 1081的流量轉送到staging_jumper上。
-f 代表要在背景執行
-C 代表要壓縮資料
-N 代表不執行任何遠端指令,通常做port forwarding 都會代入這flag

如果要關閉在背景的socks5 server,則可以用ps -aux 找出剛啟用的socks5 server pid,接著再使用kill指令去停掉正在運行的sock5 server process。

Step 4. 檢查是否有socks5 server是否有運作正常

curl --socks5 localhost:1081 http://your-staging-service.com

可以簡單透過curl 指令,來發起一個http的request到我們剛啟用的socks5 server port上。 如果成功的話,理論上會看到我們預期的html 網頁了。

Step 5. 設定SwitchyOmega

這是一個browser extension,主要是可以讓我們連接不同的網頁時,可以使用預先設定好的條件或方式來連接。
舉例來說,我們可以設定當接http://192.168.10.2:8080這個位址時,就自動透過我們預先設定好的socks5 server 與jump server 連接,此外,它還可以透過wildcard的方式來導流特定網段或特定domain 的網頁。

如以下範例

當我們啟用本機端的socks5 server以後,就可以到下面的SwitchyOmega頁面去設定代理伺服器。

之後,只需要再設定auto switch來決定哪些目標網頁要使用哪些代理伺服器就完成了

reference:

Kubernetes 的安全強化指南

Hacker Daily News上看到的新資訊,美國的National Security AgencyCybersecurity and Infrastructure Security Agency 出版的一個Kubernetes安全強化指南;雖然很久沒用kubernetes了,但對於這相關的資訊還是些記錄一下,以後說不定有機會用到。

CTR_KUBERNETES HARDENING GUIDANCE.PDF (defense.gov)

放在dropbox的備用連結

AWS egress 的費用

某天剛好看到了這篇文章AWS’s Egregious Egress (cloudflare.com),才知道原來AWS在頻寬這邊的計價(outgoing)真的蠻貴的,尤其是當你所用的AWS region是在一些已開發國家。

https://blog.cloudflare.com/aws-egregious-egress/
https://blog.cloudflare.com/aws-egregious-egress/

這邊算下來的數字來看,同樣的頻寬,如果是使用一般跟ISP租用每個月XX Mbps來相比,在北美這邊可以貴到約ISP 價錢的那邊的80陪。

hmmm…. 真的是蠻貴的…

雖然說AWS 的ingress是不計算費用的,但蠻多資料相關服務,其本身的egress 費用看來是無法避免的,所以這篇文章可以拿來參考一下一些AWS在營運上,頻寬費用上應該要注意的事項…

TCP BBR

最近聽到DK提到TCP BBR這個名詞時,才知道原來它是一種新的TCP 機制,主要可以提高在網路不穩定下的TCP傳輸品質。
當下聽了覺得蠻神奇的,後來去查了以後才發現,這技術已經發表有幾年了,現在才知道真的有點感到汗顏阿0rz…

TCP BBR

TCP BBR 全名為 TCP Bottleneck Bandwidth and Round-trip propagation time,是Google 在2017年所發現的TCP 擁塞控制演算法,適用於在網路不可靠的環境下,可以有效的提升傳輸效率。

而Google他們那時也宣稱,在他們導入Youtube以後,整個infra的網路傳輸效率平均提升了4%以上。

而相關的演算法原理可以參考這裡,基本上就是控制TCP資料的傳送端,透過演算法來控制更適合的傳輸速率,進而到讓傳輸的資料速率可以到達目前傳送與接收端之間的實際最大值,也因為這樣子,所以在真實不穩定的網路下,它可以更好的讓資料傳輸量不會過大而造成網路擁塞…

設定TCP BBR

目前只要Linux Kernel 的版本大於4.9以上,就可以直接透過更改sysctl的方式來啟用目前主機上的TCP BBR,詳細的設定如下:

透過以下的設定來確定目前的tcp 擁塞演算法:

sysctl net.ipv4.tcp_available_congestion_control

在還未設定使用bbr之前,通常應該會顯示cubic

接著加入以下的設定到/etc/sysctl.conf

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

最後執行以下指令來套用bbr的設定

sudo sysctl -p

理論上,這時候再次用下面的指令時,目前的TCP 設定時,應該就會是bbr

sysctl net.ipv4.tcp_available_congestion_control

一些注意事項

由於TCP BBR的運作模式是主動地計算目前兩端點之前的傳輸頻寬,然後用最佳的方式去想辦法灌滿這段連線,所以從上面模式看來,要啟用的TCP BBR的機器最好是傳送資料端,這樣每次傳送時就會使用這套演算法來強化傳輸效率了。

當然,如果兩端的機器都可以啟用的話,那就沒這個問題了…

何時該套用TCP BBR呢

TCP BBR也不是萬能的,它為了提高在網路不穩定的情況下的傳輸效率,但同時也會在一些情況下,表現不如預期;這篇文章描述了一系列的情境來說明,何時套用TCP BBR會得到更好的傳輸效率。

Reference: