KusakabeShi's Space

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搭建內網的過程 鏈路層 內網路由 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 kernel有了更深一層的理解，轉載一下 原文連接:  https://blog.csdn.net/dog250/article/details/86706256

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

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的時候，還什麼都不懂 只會抄配置，抄來了也不懂意思。經過了好幾個月，才搞懂他到底在幹嘛 我當初的癥結點，是卡在「 不知道他的交互對象 」 一旦搞懂這些，剩下的就迎刃而解了。 但我當初不知道，摸了很久才發現這點。 所以想花三分種講說明一下 路由是一個長類似這樣的資料結構(加上一些額外標記) [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