以下我將根據這張圖片，來和大家走一次流程圖。
圖片引用自 mitmproxy 官方文件的 Modes of Operation 章節
Do you want to proxy traffic from a client or traffic to a single server ?
答案一定是 Yes，只是選擇 Client 或 Server 端而已。
如果問題一選擇 Server 端，就會進入這個模式。
Reverse Proxy 中文叫「反向代理」，對於需求和供給的關係是反轉過來的。
平常的關係是客戶端需要代理，所以設定代理伺服器。反向代理則顛倒過來，屬於代理伺服器需要客戶端來使用它。
Reverse Proxy 的另一層用意在於，客戶端不需要知道伺服器端背後的網路架構。
舉例來說，客戶端請求一段網址的時候，是一段一對一的關係。
但是對方背後的網路叢集有多麼複雜是你不知道的，你也不需要知道。
畢竟協定 ( HTTP 或 HTTPS )、子網域、路由都可以用來做分流，分流的時候甚至難以保證伺服器主機都是同一台。
舉個實際一點的例子，如果一台機器上你想要開兩個網頁伺服器，會遇到什麼問題 ?
網頁伺服器的預設 port 是 80，既然有兩個，那就搶 port 啦 !
這時候除了開在不同 port，就可以使用 reverse proxy 來解決問題。
比方說在網頁伺服器的設定檔寫 git.example.com 和 redmine.example.com 分流到不同網站的邏輯。
回歸正題，官方給的範例指令是這樣。
我個人建議用 mitmproxy 取代 mitmdump。
$ mitmdump --mode reverse:https://example.com
Reverse Proxy 啟動以後，mitmproxy 會變成網頁伺服器。
換句話說，localhost:8080 會和 https://example.com 等價。
而封包的所有內容，當然都可以從 mitmproxy 的界面看到，而且客戶端不需要安裝憑證。
這和一般的劫持連線又有些不同，因為 mitmproxy 此時是網頁伺服器，而不是中間人攻擊的代理伺服器。
缺點是如果客戶端的行為無法控制，就不適合使用這種方法。
假設是要撈網頁封包，網頁的網址可以自己輸入，網頁上的按鈕也可以自己點，屬於可控制的範圍。
如果是手機 APP，按鈕對應到的網址一定是寫死的，屬於不可控制的範圍。
Can you configure your client to explicitly use an HTTP proxy ? ( this is easier to set up )
假設這裡選擇 No。
Transparent Proxy 中文叫「透明代理」，不過我個人覺得這個翻譯挺怪的。
如果你想通過 Proxy 上網，那你就得先設定 Proxy 對吧 ? 就像問題二一樣。
Transparent Proxy 就是反其道而行，讓客戶端不需要調整網路設定，直接讓你強制通過 Proxy。
原理是在客戶端的任何上游網路開啟 Transparent Proxy 就好了，並且有把網路封包都導向 Transparent Proxy 就好。
比方說你的上網環境上游還有三個節點，那你在任何一個節點設定 Transparent Proxy 其實都可以。
mitmproxy 官方文件有教怎麼用 Linux 內建的 iptable來讓本地的封包都導向 mitmproxy。
我對該設定還不到完全熟悉，也幾乎不會使用到，所以就不多補充。
其實我個人認為，用 Transparent Proxy 來撈封包不是很實用。
因為大部分時候，我們都有辦法控制客戶端要通過 Proxy，所以不用搞的那麼麻煩。
不過針對像是 Docker container 或是 VM 等等的環境撈封包，或許 Transparent Proxy 就會有妙用。
理由是這兩種環境，可能很難讓你去設定 Proxy。
Do you want to add mitmproxy as a second proxy ?
假設這裡選擇 No。
Regular Proxy 中文叫「正向代理」，只要是客戶端手動設定連接的都算。
屬於最簡單常見的模式。沒什麼特殊情況的話，都是用這種模式在操作。
第一個問題選 Client，其他兩個都選 Yes，就會進入這個選項。
Upstream Proxy 其實就是 Proxy 的 Proxy，可以無限疊加，就這樣。
這個模式也是我覺得針對撈封包來說，比較不實用的部份，不實用到我無法想到它的使用情境。
iThome鐵人賽
看影片追技術