Frps 家庭伺服器訪問解決方案

2022-01-10 12:30:50 字數 4600 閱讀 9788

位址塊起始

結束備註

10.0.0.0/8

10.0.0.0

10.255.255.255

區域網分配

172.16.0.0/12

172.16.0.0

172.31.255.255

區域網分配

192.0.0.0/24

192.168.0.0

192.168.255.255

區域網分配

169.254.0.0/16

169.254.0.0

169.254.255.255

兩台主機對等連線,當windows獲取不到ip位址的時候會自動分配此類位址

127.0.0.0/8

127.0.0.0

127.255.255.255

回環(loopback)位址,表示本機

255.255.255.255/32

255.255.255.255

255.255.255.255

廣播位址

這個100.64開頭的ip位址又是什麼鬼?搜尋維基百科的reserved ip address詞條才發現原來教科書上介紹的只是部分保留位址,整個保留位址家族的成員還是比較多的,那麼100.64打頭的ip位址對應位址塊為100.64.0.0/10,位址範圍為100.64.0.0~100.127.255.255,共包含有4,194,304個ip位址,這個保留位址也是用於內網,但是這個內網不是一般內網而是carrier-grade nat,這個英文對應的翻譯是「運營商級nat」。進一步搜尋得知2023年4月的 rfc 6598 (iana-reserved ipv4 prefix for shared address space) 將100.64.0.0/10(shared address space) 位址塊,用於給運營商isp使用:

netrange:       100.64.0.0 - 100.127.255.255

cidr: 100.64.0.0/10

originas:

netname: shared-address-space-rfctbd-iana-reserved

nethandle: net-100-64-0-0-1

parent: net-100-0-0-0-0

nettype: iana special use

據此可以推斷出電信的黑科技實際上是使用了乙個類似路由的裝置將我們的網路組織成乙個區域網,再通過**轉換nat技術來實現網路通訊,可以這麼理解吧,我們以前通過pppoe撥號獲取的是隨機分配的公網ip位址,這個ip位址是完全可以被網際網路上任何裝置訪問的無障礙位址,但是現在通過撥號獲取的只是乙個內網位址,也就是說我們自己的路由器或者電腦撥號連線到了電信運營商的「大路由器」上,再也沒有公網ip位址了。

為什麼電信要使用這種方式來管理使用者上網?首先我們要知道ipv4位址已經告枯竭,2023年2月4日全球頂級ip位址分配機構iana分配完了最後5個a級位址塊,因此iana宣告ipv4位址告罄。2023年4月15日,apnic宣布其剩餘的可自由分配的ipv4位址已全部分配完畢,亞太地區進入ipv4位址耗盡階段。隨後幾個月,中國各大運營商從apnic以會員資格申請到了最後的幾個c,至此各運營商也陷入了ipv4位址耗盡的困境。由於ipv6技術進展緩慢,為了解決ipv4耗盡對電信企業日益增長的使用者對於網路需求的影響,nat444/nat44的方案由此誕生。

nat444/nat44方案說白了就是將過去每個寬頻使用者獨立分配公網ip的方式改為分配內網ip給每個使用者,運營商再對接入的使用者統一部署nat裝置,nat的作用就是將使用者網路連線發起的內網ip,以埠連線的形式翻譯成公網ip,再對外網資源進行連線。這樣做以後,可以實現多個使用者共享乙個ip位址,在技術實現原理上和我們家用的路由器一樣,其中nat444對應傳統寬頻使用者,nat44則對應3g或者4g移動上網終端。

這樣做的好處顯而易見,首先延緩了ipv4耗盡對電信業務帶來的威脅並進一步為ipv6技術部署留足時間,其次是內網保護,所有接入網際網路的主機都不再直接接入,而是出於電信nat裝置的保護之下,沒有獨立的公網ip,所有端對端的遠控軟體將會失效,比如以前的灰鴿子木馬,由於主機喪失了公網ip,灰鴿子**的ip位址將是電信nat裝置所使用的公網ip,黑客無法以此定位到中了灰鴿子木馬的具體主機,不過這不影響第三方埠**的遠控軟體,比如teamviewer,但是對傳統遠控軟體殺傷力是巨大的。最後增強了隱私保護,對於遠端的**通過ip位址跟蹤等形式採集使用者資料,或者以後臺記錄ip的形式定位使用者身份的行為將不再有效,因為這個ip位址可以同一時間段內被大量使用者所使用,所以部分廣告商可能需要修改廣告跟蹤**的相關邏輯,這邊順帶說一句並不意味著處於電信nat保護的使用者可以做違法的事情,比較電信公司不是傻瓜,電信級nat裝置會有日誌記錄系統,所以處於其下的網路裝置的上網流量都是得到有效審計的。

這樣做的壞處是什麼呢?首先喪失了公網ip讓極客們的生活失去了不少樂趣,比如原先通過花生殼動態網域名稱解析服務可以定位到我們家的上網裝置,然後可以在上面架設一些服務等,從最原始的**服務(電信封鎖了80埠)到遠端私有雲儲存,甚至是個人vpn等等,現在都不能直接使用了,因為動態網域名稱服務解析的ip位址是電信級nat裝置所使用的公網ip,同時也是若干電信使用者所共享的ip位址,nat並不會**你的請求到特定的電信使用者,所以這些服務都失效了,其實這對於安裝遠端網路監控的公司或者個人帶來的麻煩最大,原來只要配置好動態網域名稱解析就可以在任何地方使用網路進行監控檢視,現在都不可以了。其次共用ip位址容易讓部分網路服務提供商誤殺合法使用者,比如一位非法的資源濫用電信使用者和你在共享同乙個公網ip位址,非法的資源濫用者由於濫用某個網路服務商資源從而被加入黑名單,注意這裡只有將你們所共享的公網ip位址加入了黑名單,所以導致你這個合法的使用者也不能正常使用該網路服務商所提供的資源了。最後這樣做的壞處還有影響到電驢等p2p軟體的使用,因為處於內網下導致電驢等軟體一直是lowid,影響傳輸速度。

如何解決此問題?要想重新獲取公網ip,最後還是要聯絡電信運營商,不行只有進行投訴解決了。

後來發現這種現象普遍存在,甚至有電信運營商直接分配172或者10開頭的內網ip位址,但這種分配方式容易與使用者自己的路由器ip位址衝突,所以還是100.64開頭這種好一些,畢竟新設立專用於isp運營的保留位址,個人網路裝置占用的可能性較低。

希望ipv6能夠盡快全面推廣開,從而解決現在尷尬的局面。

frp穿透方案

(1)準備工作

(2)配置伺服器端

伺服器端只需要兩個檔案frps和frps.ini,其中frps為可執行檔案,frps.ini為配置檔案,是不是很方便?配置檔案如下圖(很簡單):其中bind_addr為本機ip,bind_port為frp對客戶端的埠號,auto_token是客戶端連線伺服器端的口令。

配置好後即可執行伺服器端:./frps -c ./frps.ini

執行成功如上圖,現在就可以配置客戶端啦!

(3)配置客戶端

同樣將客戶端解壓後有七個檔案,只需要frpc和frpc.ini,配置檔案如下:

注意:server_addr是伺服器端的公網ip位址,server_port是frp服務埠號,auto_token是連線伺服器的口令,必須和伺服器保持一致。[ssh_208]是客戶端通過伺服器與使用者之間的通道名,每個客戶端必須不一樣,remote_port是伺服器端對外提供本機服務的埠號,即使用者連線60.12.220.16:10085,相當於連線127.0.0.1:22,即arm板上的ssh服務

執行客戶端:./frpc -c ./frpc.ini

(4)測試

現在我們用外網主機來遠端登陸到我們的arm板子,ssh 60.12.220.16 -p 10085

可以看到,完美成功!!

(5)補充後期遇到的問題!!!

注意:客戶端的時鐘不能和伺服器端時鐘相差太大!否則會出現認證超時的錯誤:authorization timeout

這個超時時間可以在配置檔案中通過 authentication_timeout 這個引數來修改,單位為秒,預設值為 900,即 15 分鐘。如果修改為 0,則 frps 將不對身份驗證報文的時間戳進行超時校驗。

使用命令:date 檢視當前計算機時間

使用命令:date -s "yyyy-mm-dd hh-mm-ss" 設定時間

使用命令:hwclock -w 寫入flash

檔案伺服器解決方案

一 採用流方式讀取文件並儲存到資料庫中。採用這種方式似乎極為方便,但若文件大小相差懸殊,會造成資料庫字段冗餘,且若要檢視文件內容,必須通過程式讀取。且也不利於文件的備份。二 把文件儲存到應用伺服器工程中某檔案下,資料庫中只儲存該文件對應的路徑。這樣即不會造成資料庫儲存的冗餘,也可以隨時從server...

伺服器負載均衡解決方案

一 需求分析 隨著網際網路的高速發展,作為web email sql ftp erp dns 集群等等常見伺服器的請求資料量越來越大,同時對應用的高可用性提出了更高的要求,伺服器主備冗餘模式已經不能滿足當前需求,部署伺服器負載均衡裝置勢在必得。作為應用交付行業內最為成熟的方案提供商f5,其產品技術先...

伺服器負載均衡解決方案

伺服器負載均衡解決方案 一 需求分析 隨著網際網路的高速發展,作為web email sql ftp erp dns 集群等等常見伺服器的請求資料量越來越大,同時對應用的高可用性提出了更高的要求,伺服器主備冗餘模式已經不能滿足當前需求,部署伺服器負載均衡裝置勢在必得。作為應用交付行業內最為成熟的方案...