發表文章

公網 ASN 勸退文

我擁有自己的 ASN 一段時間了。 自從踏入 DN42 接觸到網路的世界,到擁有公網 ASN 在網路世界上留下自己的足跡 經過一段時間,我的網路也經由各位朋友的幫忙, transit 到當地上游。 內網也搭好了,anycast unicast multicast 也都實驗過,只差沒有 ipv4 了 經過群友的指點,我也更加了解這個世界的眉眉角角 以前我會說: 先玩 DN42 ,熟悉了玩公網 現在我會說: 玩 DN42 熟悉網路挺好的,別玩公網 DN42 和公網主要差異在發表: 首先複習一下 peer 和 transit 的差別: 一般來說每個 AS 都視為一個主體,peer 和 transit 是兩個相對的詞。 peer 是指兩個 AS 之間互相交換流量,這個 bgp session 交換的路由,不包含第三方 AS transit 是指有一個 AS 在中間,「A-B-C」,A和C通訊要經過B,我們就可以說「B正在幫A/C做transit」 DN42 交流時,其實一直都是誤用這個詞 大家都說來 peer ,但實際上大部分都是互相幫對方 transit 而公網主流這三種協議: 上游/對等/下游 下游付錢,相對於下游,自己就成為了上游。 上游具體做的事情則是「幫下游 transit」。所以是做這兩件事: 1. 從下游收來的路由,轉發給其他人 2. 從其他人收到的路由,轉發給下游 就能整理出這樣的表: 發給上游: 下游 發給對等: 下游 發給下游: 全表 收上游表: 發給下游 收對等表: 發給下游 收下游表: 發給其他所有人 (自己的路由表也算是下游的表) 所以兩個網路互相 peering ,只會互相發自己&下游的表,單純只能讓兩邊網路+下游可以互通 不像 DN42 ,說是互相 peering ,其實都在做 transit ,接一個人就通全網了 (當然也可以自己設定,不做 transit,比較少人這樣做) 擁有公網 ASN 個實體,我們大概可以分成兩類: ISP/IDC/雲服務商/雲供應商 物理機 使用 Cisco/Juniper/華為 等路由器 使用 物理光纖/海底光纜/dark fiber/專線傳輸 之類,「實體存在的」網路線來做內網互連和外網的路由交換 做 peering 使用的是物理上真的光纖 Player 節點是虛擬機 使用 linux+bird/frr

Wireguard + Babeld 內網搭建

圖片
玩DN42,igp有很多方案。 使用L2 VPN,鏈路層和igp綁定在一起。由VPN軟體來負責選路 我是使用etherguard搭建內網,由etherguard負責選路。 這樣的話,igp和etherguard綁在一起了。我一直以來都這樣用 還有一種方案,鏈路層和內網路由分開,鏈路層隨意,上面再跑一層OSPF/babel 假設你有abcd四個節點,就可以這樣搭配 a-b走wireguard b-c走openvpn c-d走v2ray a-c走gre a-d走無線電/wifi b-d拉實體光纖 優點是靈活搭配,根據不同網路情況建立不同隧道 缺點則是配置繁瑣,每個元件都是互相獨立的 還有一個方案,就是在鏈路層上面做內網路由,例如我的etherguard,或是zerotier/tinc之類 他們會在內部建立起路由表,然後根據MacAddress尋路 缺點就是鏈路層和igp綁定了,要用只能用全套的。 如果某節點針對UDP的限速很嚴重,單獨對這個節點我想換別的鏈路層就十分麻煩 理論上eg的過牆性能和wg應該是一樣的。 現在wg正常使用,但不知道哪天會被封。加上wg協議本身沒有隱蔽性,很容易被識別 為了縮MTU,eg的header被我魔改過,長得有點不一樣 最近某群友贊助了我一台江蘇的server 為了未雨綢繆,哪天etherguard無法連線,我決定把igp和鏈路層分開,使用babeld來維護內網路由 如果用上了 igp , ibgp 的設定就很不一樣了 我們的路由表,又稱作RIB,一定要變成轉發表,又稱作FIB,封包才能真正地送出去 路由表的資料結構有以下這些欄位: 1.prefix 2.device(optional) 3. nexthop(optional) 而轉發表非常類似,有這些欄位: 1. prefix 2. device 3.MAC address (note: L2 裝置比如tap,或是物理網卡才有 mac address。 L3裝置比如 tun,沒有 MAC address) 我們可以看到,只有第三點不一樣: nexthop vs MAC address 。這和一個概念很相關: 「直接可達」 IP地址代表了某台電腦。nexthop 填入的是一個IP,但是不能隨便填。nexthop的IP,必須要是「直接可達」的IP。 甚麼是直接可達的IP呢? 就是「可以被轉換

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