換一個思維解決問題:希望在轉角
前段時間困擾我的一個網絡攔截請求的問題,終于被巧妙地解決了。
我之前開發了一個net proxy,專門用于對特殊網絡環境的模擬,以此測試一個工作中需要測試的軟件。簡單來說就是用mitmproxy實現一個網絡流量代理服務,對網絡請求域名進行攔截功能,只有指定的一些域名可以正常訪問,其他域名訪問就直接返回403。
本來功能都實現得很好,用起來非常絲滑。但后面因為工作網絡有了新的要求,必須用工作的虛擬網絡通道(簡稱SXNN)。
在網絡通道連接之后,它直接接管了路由,導致流量繞過本地運行的mitmproxy,我的域名攔截就無效了。
而如果先開啟net proxy,則又無法順利連接SXNN的網絡服務。
后面想了很多辦法,比如通過修改net proxy項目代碼,嘗試讓流量還是走代理攔截。基本把AI服務都用了個遍,vibe coding了2個月,依然無法解決問題。
而且因為涉及了工作要求,我也不能對SXNN的客戶端進行改造,比如把網絡改為Split Tunnel模式。也就是讓指定域名/IP 走本地網絡(從而經過 mitmproxy),其他走SXNN。
而且我用來進行對特殊網絡環境的模擬的應用也無法再Docker容器里面進行使用,這里面涉及到了更復雜的構建工作以及測試。
AI甚至建議我在連接SXNN之后,把net proxy設置為上游代理,通過一系列復雜的網絡命令來實現。我嘗試了一下,并沒有讓流量走mitmproxy。
我在多次的失敗之下也短時間放棄了研究,直到這兩天在山中修行,夜間無事打開電腦繼續和AI進行探討。
硬碰硬是走不下去的,涉及到底層網絡協議和工作安全性的限制,注定是一個死胡同。我需要調整思路,如果先A后B不行,那么先B再A呢,是否就能走出新的路?
我突然想到,如果我沒法在連上SXNN之后讓mitmproxy成功攔截網絡請求,那為什么不先運行net proxy,讓網絡流量先走我本地的proxy,然后再去接入SXNN。
我唯一要實現的就是,在net proxy運行的條件下,讓SXNN服務能連接上個網絡即可。于是通過net proxy的網絡請求日志,我發現了7個需要加入白名單的域名,它們是用來連接SXNN網絡的中間服務域名。
當我把這7個域名加到白名單后,終于順利實現了SXNN網絡連接和net proxy并存了,我的代理服務終于又可以正常工作了。
從這次思維改變,我把一個困擾我長達三個的難題解決了,我內心是激動的,這是多年工作之后很少遇到的頓悟時刻。
有時候困難并沒有那么大,只是我們給自己加了太多預設條件和“心墻”,推不倒南墻,但希望在轉角。

浙公網安備 33010602011771號