發表文章

5月的多事之秋

圖片
5月開始,我的電腦不知道為什麼突然開始大量當機... 而且開始了一種新的當機方式 我的電腦問題從買來就有 當初買的時候,每1~2個月會自己重開 前3次還以為是忘記關windows update,用了半年才發現這不正常 後來灌成 linux 問題依舊,系統會不定時凍結(不是kernel panic,是凍結,所以沒有錯誤訊息可以看) 再後來灌回windows,直到我親眼遇見,才確定是硬體故障。(不是BSoD,是畫面突然卡住不能動,10~20秒以後畫面黑掉重開,所以也沒有錯誤訊息可以看) 後來拿回原價屋檢修保固,燒機2周無異常 + memtest無異常,原價屋判定機器正常沒有損壞(不過有幫我免費把CPU從R5 1400換成R5 2400G),就退回來了 然後這台有問題的機器就一直用到現在 這些是買來開始就有的老毛病,依照發生機率排序 1: windows in vmware 隨機BSoD 每天1~2次 2: windows host 隨機凍結,自動重啟 2~3個月一次 3: linux host 隨機凍結,需人為重啟 2~3個月一次 4: 7zip 解壓縮,突然 CRC Error,隨後BSoD 共發生過2次 5: youtube 看到一半,解碼器錯誤,隨後藍屏 共發生過一次 我覺得第一個症狀真的是最奇怪的,只有 vmware 裡面的 windows 會一直BSoD 其他組合都不會。linux in vmware / windows in vbox 都正常運作 但是從今年5月開始,故障頻率突然大幅增加。而且出現了一種全新的故障方式: (遠端)我用到一半,突然就失去連線了 打電話回家請媽媽檢查,螢幕打開顯示「無訊號」 請媽媽重新開機, 神奇的事情來了:  按下電源鈕,燈光瞬間熄滅。而不是強迫關機所需要的按住10秒 再按一次就正常開機了 最近的當機紀錄 唉,為什麼運氣這麼不好,買到一台故障一半的電腦呢... 完全不能開機,至少有地方檢查哪邊壞 壞一半,拿去保固,只要燒機期間不發作,對方就說沒故障。 自己用,又用的很不開心...

紀錄一下DN42內網搭建的過程

圖片
紀錄一下DN42搭建內網的過程 鏈路層 內網路由 Anycast+DNS/RDNS Looking Glass+AutoPeer 鏈路隧道 首先要搞定的就是各節點的內網互連手段。 在DN42網路中,一般是使用VPN隧道。 真實網路則是光纜/網路線/無線電/wifi/衛星,當然你也可以在DN42中用這些 但DN42是用來低成本學習網路的,VPN最便宜 我自己用的VPN是我自己刻的 Etherguard-VPN 這是一個Layer2 VPN,能根據 單向延遲 來選路,而不是雙向延遲。具體 工作原理 隧道有分Layer2和Layer3,在這之上又分許多不同的軟體 L2和L3最大的差異就是是否攜帶了EtherFrame,EtherFrame裡面攜帶的是Src MacAddr和Dst MacAddr L2 VPN有帶,L3 VPN沒帶 假設今天來了一個封包,我們本地看到這個封包,有3個下一跳可以選 如果是L2 VPN,選擇完以後,我們只須把下一跳的MacAddr填入EtherFrame,然後送入VPN即可。只建立一個隧道,後面多個下一跳很容易做到 如果是L3 VPN,因為沒有EtherFrame,我們必須對每個下一跳,分別建立各自的VPN隧道 有n個下一跳,就要建立n條隧道。然後根據下一跳,送入指定的隧道。只建立一個隧道,後面對應多個下一跳是不可能的 在我們的情境中 L2 VPN像是一台switch,所有電腦接入就在相同內網了 L3 VPN則像是 單根網路線 ,p2p只有兩端。多台電腦互聯,就需要多根網路線了 L3 VPN,一對多連線模式也是存在的。像是openvpn/wireguard多個peer。但是在此種情境中,路由表示固定好的。wg設定檔的allowed ips,openvpn發配的ip,就已經決定好這個ip段該發去的peer節點了,由vpn server執行路由 但是DN42這裡,路由功能必須在自身節點上執行,而不是VPN server執行 所以L3 VPN只能使用p2p模式 但我自己覺得L3不是很方便,以 這位群友 為例,他的拓樸,內網就要配9條wg隧道 iBGP要求任意2節點的iBGP session兩兩互相可達,iBGP沒有維護內網路由的功能 L2 VPN 由VPN自身提供斷線繞路功能。但是在網路拓樸上,所有節點都是嚇一跳可達。繞路的行為被隱藏起來了 L3 V

(轉載) Linux内核Policy Routing & iptables 的不完美实现

圖片
最近看到這篇好文,讓我對linux kernel有了更深一層的理解,轉載一下 原文連接:  https://blog.csdn.net/dog250/article/details/86706256

Rootless Router(After): App Service真的很靈

圖片
RootlessRouter系列: Rootless Router(Part: 0): 用戶態DN42節點 Rootless Router(Part: 1): wggo-vpp Rootless Router(Re: 0): VPP Host stack Rootless Router(Part: 2): BIRD-vpp Rootless Router(Part: 3): EtherGuard Rootless Router(Extra):蒐集的Userspace 網路棧 Rootless Router(Part: 4): 被VPP Host Stack衝康 Rootless Router(Part: 5): 完結 Rootless Router(Fin): UML版本上線啦! Rootless Router(Afterword): Azure App Service真的很靈 名詞解釋: 在VPS裡,一款VPS如果被稱作 靈車 ,意思是服務很不穩,容易跑路 可以當作形容詞使用,例如: 這家很靈,意思是這家服務很不穩 相信你也猜到... 我會寫這篇,是因為 Azure App Service真的很靈 玩玩可以,生產環境建議別用。除非你選用Dedicated CPU以上的方案 前情提要 Rootless Router  終於搞定了,目前都是部屬在Azure app service裡面,F1 tier免費層 屬於Azure services that are free always類別 我的 Rootless Router 上線也有些時日了。正式部屬上線以後,過兩天發現了些問題 Update: App Service SLA,微軟公司保證有 99.95% 之時間,將提供客戶訂閱中執行之 App。 在免費或共用層下之應用程式並未提供 SLA。 本文稱微軟產品不穩定,系指 未提供 SLA服務 之自身使用經驗, 不能概括微軟有提供SLA之其他產品 ,特此刊誤 Part: 1 首先了解免費層的限制:  CPU time: 60min/day Traffic: 165MB/day CPU 100%運作,就是消耗全部的CPU time。 每天24小時,cpu time一小時, 意味著平均CPU不能超過4% 首先,我的香港節點CPU消耗特別快。一下子就用光我的所有時數 比起其他節點,

網友免費送了我一個域名

在這篇帖子  https://hostloc.com/forum.php?mod=viewthread&tid=893162 這位好心網友送了我一個域名: https://wget.date 我最後也如同帖子裡面提到的,把服務搭建起來了 服務我最後選擇搭建在azure web service裡面,屬於azure always free的服務 和 RootlessRouter 搭建在一起 十分感謝這位網友送我的域名,還續費到2027年。使我擁有的「付費產品」+1了 我家境較嚴也較傳統,又因新聞上卡奴的負面消息太多。 父母對於信用卡,還有網購一直以來都抱著十分負面的態度 到目前為止,柴米油鹽電費瓦斯,家中所有買賣都是現金交易。 非常長一段時間,連信用卡都沒有 後來因為一些需求,實屬無奈,父母才辦了一張VISA信用卡 對於我來說,真的十分不便 從域名,VPS,以及各種各樣的線上消費,都離不開信用卡 也不是說窮到付不出錢。但是,能動用信用卡,真的是很不容易的一件事 必須經過重重難關,才能使用父母同意,使用信用卡消費一次 使得這次送我的域名額外有意義,我為數不多的「付費產品」+1了! 在以往, 每次的+1,背後都有一則絞盡腦汁的故事,和一篇激動人心的演講 目前的手上持有的「付費產品」 韓國甲骨文(信用卡驗證用,沒實際扣錢) azure帳號(信用卡驗證用,沒實際扣錢) a1p域名(全局還在+域名已失效)x1 + a1域名x2 本次網友送的域名 這次,直接就+1了,開心~與此同時也十分感謝houzai這位mjj 最後,wget.date的原始碼我放在這邊:  https://github.com/KusakabeSi/http-date-server

Rootless Router(Fin): 計畫終於完成,上線啦!

圖片
RootlessRouter系列: Rootless Router(Part: 0): 用戶態DN42節點 Rootless Router(Part: 1): wggo-vpp Rootless Router(Re: 0): VPP Host stack Rootless Router(Part: 2): BIRD-vpp Rootless Router(Part: 3): EtherGuard Rootless Router(Extra):蒐集的Userspace 網路棧 Rootless Router(Part: 4): 被VPP Host Stack衝康 Rootless Router(Part: 5): 完結 Rootless Router(Fin): UML版本上線啦! Rootless Router(Afterword): Azure App Service真的很靈 不知道RootlessRouter是什麼的人,請點上面第一篇,了解整個故事線 最後,RootlessRouter終於上線了! 完結灑花! 在放棄VPP以後,最初我的計劃長這樣: 自己刻一個Simple Router代替原本的VPP,大致架構不變 原本VPP的LD_PRELIAD的kernel bypass部分拿掉,改成端口轉發。把遠端端口179轉發到localhist:10079 然後BIRD就和localhost:10079 建立session,同時把遠端發往SimpleRouter的179端口轉發到localhost:179 同時也不忘看看 這裡 一些其他選項,在我看UML的時候,其中一句話吸引了我: You can get extremely high performance for anything which is a “kernel specific task” such as forwarding, firewalling, etc while still being isolated from the host kernel. 我決定相信他所謂的extremely high performance。而且BIRD正好不怎麼fork,完美適合UML發揮的場景! 現在的架構長這樣: BIRD是運作在UML裡面的,圖片沒畫好又有點懶得改,附註一下 同時我決定把計畫更名,從原本的Ro

三分鐘搞懂DN42 wiki裡面的BIRD2範例設定檔

圖片
當初知道DN42的時候,還什麼都不懂 只會抄配置,抄來了也不懂意思。經過了好幾個月,才搞懂他到底在幹嘛 我當初的癥結點,是卡在「 不知道他的交互對象 」 一旦搞懂這些,剩下的就迎刃而解了。 但我當初不知道,摸了很久才發現這點。 所以想花三分種講說明一下 路由是一個長類似這樣的資料結構(加上一些額外標記) [1] 192.168.1.0/24 → dev eth0 [2] 192.168.2.0/24 → via 192.168.1.1 [3] 192.168.3.0/26 → dev eth0 via 169.254.42.1  以上面的三條路由為例,假如我們 kernel 內有這三條路由,然後 kernel 依序收到以下封包,這是接下來會發生的事情: 1. 任何封包發送時,首先第一步就是決定要往哪張物理網卡送。畢竟網卡是網路連線的渠道 DstIP=192.168.1.9。查詢到路由表裡的 [1],就會把這個封包送往eth0 DstIP=192.168.2.9。查詢到路由表裡的 [2]。 但是路[2]裡面沒有指明具體網卡 ,只有寫「請找192.168.1.1」,所以他又去找 192.168.1.1 了,匹配路由 [1]。路由[1]指定了網卡eth0,最後這個封包就會送往eth0了。這個步驟叫做 遞迴查詢 DstIP=192.168.3.9。查詢到路由表裡的 [3]。但是[3]同時指定了網卡和IP。這個時候 [3]和[1] 的行為非常像,都是送入 eth0。不一樣的是下一步 2. 封包發送時,找到對應網卡以後,接下來就是填入目標的 mac address 了,這個時候不僅要查詢路由表,還要查詢 arp table 路由[1] 沒有指定IP,那麼DstIP是多少,就填入那個IP的 MAC 地址。 然而路由[3]比[1]多了「via」選項:「169.254.42.1」,那麼就會改為填入 169.254.42.1 的MAC地址 那麼我們要怎麼知道某IP的mac address呢? 電腦首先會在一個本地資料庫「arp table」裡面查詢。如果查不到,那電腦對那張網卡發出 arp request ,在區網內廣播「who has 169.254.42.1」,對面應答以後,就知道對面的 mac address,並存入本地的 arp table 「169.254.42.1 的 MA