原因:更換路由器后網(wǎng)段發(fā)生變化被攔截

解決方法:

關(guān)閉QuFirewall或更改下面的端口

問(wèn)題描述

• 局域網(wǎng)內(nèi)使用固定IP訪問(wèn)顯示訪問(wèn)被拒絕

• QfinderPro一直找不到設(shè)備，使用網(wǎng)線直連NAS依舊沒(méi)有任何反應(yīng)

• NAS剛啟動(dòng)的時(shí)候是可以訪問(wèn)的，但是等到進(jìn)程全部啟動(dòng)之后連接斷開(kāi)

• 外網(wǎng)訪問(wèn)可以連接到NAS

問(wèn)題定位

• 家中的網(wǎng)絡(luò)結(jié)構(gòu)比較復(fù)雜，開(kāi)始以為是網(wǎng)絡(luò)的問(wèn)題，但是嘗試使用網(wǎng)線直連NAS依舊無(wú)法訪問(wèn)

• 經(jīng)過(guò)幾天的嘗試發(fā)現(xiàn)，在NAS剛啟動(dòng)起來(lái)的時(shí)候可以訪問(wèn)到，但是等到進(jìn)程啟動(dòng)之后又?jǐn)嚅_(kāi)了連接，顯示訪問(wèn)被拒絕

• 局域網(wǎng)無(wú)法訪問(wèn)但是外網(wǎng)訪問(wèn)可以，說(shuō)明硬件是沒(méi)有故障的

• 想到NAS啟動(dòng)的時(shí)候是可以訪問(wèn)到的，但是一些進(jìn)程啟動(dòng)之后就拒絕訪問(wèn)了，問(wèn)題可能出在某些軟件進(jìn)程上，好在外網(wǎng)訪問(wèn)還可以連接到NAS，于是開(kāi)始逐個(gè)停止后臺(tái)進(jìn)程

• 當(dāng)停止QuFirewall進(jìn)程之后電腦網(wǎng)頁(yè)端恢復(fù)正常自動(dòng)刷新進(jìn)入到了登錄界面

• 隨后重新啟動(dòng)NAS，復(fù)現(xiàn)了之前的問(wèn)題，在只停止QuFirewall進(jìn)程之后訪問(wèn)恢復(fù)正常，終于定位到了問(wèn)題

問(wèn)題分析

• 問(wèn)題出現(xiàn)在QuFirewall，這是QNAP的防火墻進(jìn)程，通過(guò)系統(tǒng)日志發(fā)現(xiàn)Network & Vitual Switch頻繁警告，QuFirewall事件數(shù)量飆升，部分網(wǎng)絡(luò)服務(wù)被攔截

• 想到之前啟用了ubuntu工作站，構(gòu)建ubuntu工作站之后會(huì)改變NAS中的虛擬網(wǎng)絡(luò)結(jié)構(gòu)，從而觸發(fā)QuFirewall的配置規(guī)則導(dǎo)致局域網(wǎng)訪問(wèn)被拒絕，需要注意的是NAS的三大操作（虛擬化Virtualization、容器站Container Station以及ubuntu工作站）都會(huì)改變NAS中的虛擬網(wǎng)絡(luò)結(jié)構(gòu)導(dǎo)致此問(wèn)題的發(fā)生

• 經(jīng)過(guò)反復(fù)嘗試發(fā)現(xiàn)，只要在開(kāi)啟ubuntu工作站之前開(kāi)啟了QuFirewall都會(huì)導(dǎo)致無(wú)法訪問(wèn)的問(wèn)題出現(xiàn)，不知道這算不算是QTS的bug，比較慶幸的是QuFirewall并沒(méi)有拒絕DDNS訪問(wèn)，不然沒(méi)有任何方式可以訪問(wèn)到NAS只能進(jìn)行重置

• 暴露出的QNAP NAS的一個(gè)安全問(wèn)題，QuFirewall在系統(tǒng)啟動(dòng)時(shí)并沒(méi)有啟動(dòng)，此時(shí)系統(tǒng)不受QuFirewall保護(hù)，防火墻規(guī)則沒(méi)有建立，存在被網(wǎng)絡(luò)攻擊的可能性，但是從NAS開(kāi)機(jī)到QuFirewall啟動(dòng)之間的時(shí)間間隔很短，并且NAS的開(kāi)關(guān)機(jī)頻率極低，一般不會(huì)造成很大的安全問(wèn)題

參考資料:https://blog.csdn.net/qq_29688717/article/details/128740998?spm=1001.2101.3001.6650.3&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EYuanLiJiHua%7EPosition-3-128740998-blog-126887528.235%5Ev27%5Epc_relevant_3mothn_strategy_and_data_recovery&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EYuanLiJiHua%7EPosition-3-128740998-blog-126887528.235%5Ev27%5Epc_relevant_3mothn_strategy_and_data_recovery&utm_relevant_index=4