對某些人來說，VPN是允許他們安全地生活和工作的重要工具。在使用公共WiFi時，它們是增加一點額外安全性的好方法。無論目的是什么，VPN泄漏都會妨礙并造成嚴重危險。

在某些情況下，這可能意味著更嚴重的后果，可能意味著一個人有爭議的互聯網活動與他們聯系在一起。這就是為什么了解VPN泄漏并學習如何避免這些泄漏非常重要的原因。

什么是VPN泄漏？

使用VPN是提高隱私和安全性的第一步，但它并不能自動保證這兩種屬性。VPN可能會泄漏，意味著數據未得到適當保護，互聯網活動鏈接搜集到你的身份，或者信息可能會暴露給窺探者。

VPN背后的想法是，它們在您的計算機（或設備）上的客戶端與VPN服務器之間創建加密隧道，其中數據在前往目的地（例如網站）之前被解密。

當一切正常時，此設置可防止任何人在互聯網活動鏈接搜集到你的身份，并阻止攻擊者在您的設備和VPN服務器之間的路徑上攔截您的數據。

第三方能夠訪問的只是一堆混亂無意義的密文。這意味著除了您的VPN提供商之外，沒有人可以告訴您在線查看的內容，或者您??發送和接收的數據。

當設置不能正常工作時會發生VPN泄漏，并且暴露的數據允許攔截器將您的活動與您的身份相關聯。如果發生這種情況，任何監視您的人都可能能夠找到您實際在做的事情，使用VPN的整個過程可能毫無意義。

如果您的VPN泄漏，您可能與不使用VPN的人一樣容易受到攻擊。對于政治活動家和持不同政見者來說，這可能意味著當局能夠獲得他們正在做的一切。如果您在使用公共WiFi時VPN泄漏，黑客可能會獲得您的數據。

VPN泄漏尤其危險，因為當人們認為他們的VPN正在保護他們時，他們通常會更加自信地參與有風險的在線活動。如果VPN在用戶不知情的情況下泄漏，他們可能會遇到嚴重問題。

VPN可能泄漏的不同方式

有幾種不同類型的VPN泄漏，包括DNS泄漏，WebRTC泄漏，IP地址泄漏和流量泄漏。

DNS泄漏

當域名系統（DNS）請求發送到ISP而不是VPN提供商時，會發生DNS泄漏。域名系統是將域名轉換為IP地址的目錄。

在正常情況下，例如訪問thesslstore.com這樣的站點時，計算機會向DNS服務器發送DNS查詢，該DNS服務器會將URL轉換為站點的IP地址107.23.230.173。整個過程基本上只是將我們語言中的東西翻譯成機器語言。

當使用VPN時， DNS請求應該轉到VPN提供商，這樣ISP就無法找到您要做的事情。如果VPN工作不正常并且DNS請求發送到ISP，則會將訪問的站點暴露給ISP和任何窺探的人。如果您正在做一些需要絕對隱私的事情，DNS泄漏可能非常危險。

您可以檢查DNS是否在DNS泄漏測試中泄漏。如果是，您可以通過重新配置網絡，編輯.ovpn文件，禁用Teredo（適用于Windows）或安裝插件來解決問題。

WebRTC漏洞

Web實時通信（WebRTC）允許我們在不必安裝插件的情況下觀看或收聽內容。特別是，WebRTC通常用于基于瀏覽器的VoIP應用，如Skype for Web，Discord和Google Hangouts。這是一個有用的項目，但它有一個嚴重的缺陷，影響VPN用戶。此漏洞將個人的真實IP地址暴露給他們通過javascript訪問的網站。

這個問題有一個相對簡單的解決方案。可以通過更改廣告攔截器上的設置來保護自己。否則，Firefox用戶可以安裝Disable WebRTC插件，而Chrome用戶可以安裝WebRTC Block擴展。

這樣做可以消除使用WebRTC的網頁上的某些功能，但至少IP地址將不再泄露給網站。

IP地址泄漏

Internet協議（IP）地址是用于建立Internet連接的路由器的地址。在正常情況下，當連接到網站時，站點管理員， ISP和任何窺探的人都可以看到路由器的IP地址。顯然，這不是很私密。

當VPN正常工作時， ISP將能夠看到正在連接到VPN服務器，但他們將無法看到流量后來的位置。

在VPN的另一端，站點管理員將看到來自VPN出口服務器的數據，但他們將無法確定數據來源的IP地址。此設置可防止IP地址暴露。

有兩種不同的IP協議，IPv4和IPv6。自八十年代以來一直使用IPv4，而IPv6則是2017年成為標準的新版本。大多數人仍在使用IPv4，因此一些VPN尚未趕上并為IPv6配置適當的服務。這可能導致這些服務的IPv6用戶發生IP地址泄漏。

可以在WhatIsMyIP站點上檢查您是使用IPv4還是IPv6 。如果只使用IPv4，那么在這種情況下無需擔心。

如果有IPv6并且IP地址通過VPN泄漏，則可以在不更改提供商的情況下解決問題。可以使用以下Windows或Mac OSX教程禁用IPv6并恢復為IPv4 。

交通泄漏

這些是最糟糕的泄漏，它們涉及到VPN隧道外泄漏的全部流量。如果有流量泄漏，您的ISP和任何監視的人都將能夠看到所有數據。

當連接中斷時，通常會發生流量泄漏。這就是選擇為其客戶提供kill開關的VPN提供商的重要性。如果VPN出現故障，這些kill開關會啟動并中止連接。如果VPN在沒有停止開關的情況下發生故障，互聯網連接可能會繼續，并且所有流量都將暴露持續性與觸發性泄漏，這些泄漏有三種主要形式：預先存在的持續性泄漏 VPN或其配置問題可能導致預先存在的持續泄漏。如果有其中一個，一些數據將一直泄漏，可以通過上面提到的測試來獲取它。

觸發持續性泄漏

這些泄漏是由某些事件觸發的，例如Internet連接中斷或VPN崩潰。一旦觸發發生，VPN將繼續泄漏數據，直到問題得到糾正。如果事件已經發生，這些泄漏將在測試中輕松顯示。

臨時觸發泄漏

在某些中斷事件發生后發生臨時觸發泄漏，但數據僅暫時泄漏。這些是最難檢測的，因為除非在測試時實際發生觸發事件，否則本文中的任何測試都不會進行檢測。 這使得這些泄漏特別成問題，因為用戶可能永遠不會發現他們的VPN在某些條件下容易泄漏。

如何阻止VPN泄漏 有些VPN配置不當，比其他VPN更容易泄漏。這就是為什么在開始之前選擇可靠的VPN服務很重要。

一旦知道是什么導致泄漏，可以嘗試我們談到的一些補救措施。如果它們不起作用，請嘗試搜索VPN提供商和特定問題，以查看其他用戶是否也遇到此問題。他們可能能夠提供安全瀏覽所需的解決方案。

以上就是“VPN可能泄漏的不同方式和解決方法”所有內容，如有需要歡迎登陸GDCA數安時代官網咨詢客服。

概述

最近處理了一個拖了我差不多一個月的問題，因為win不是很擅長，所以這里記錄下大概的解決過程。

異常現象

服務器 telnet其他服務器端口和本機端口都無法telnet通，且無法訪問網頁，但可以正常ping通服務器，更奇怪的是每次只需要重啟服務器就可以解決

說明：其他服務器端口都是正常的，也不存在防火墻問題

無法訪問百度或者自己的網頁。

1、考慮防火墻

這里確認是已經關閉防火墻了。

2、考慮是網卡問題

禁用網卡，然后重開網卡，但是還是不行，這里要注意如果禁用網卡就不能遠程服務器了（忽略過一次）...

不要問我怎么禁網卡...

3、檢查操作系統日志

沒有什么有效信息。

下面開始有進展了。

4、漏洞?

微軟上看到有提示相關漏洞，當Windows2008R2系統運行時間超過497天，TCP/IP的網絡資源（端口）就不會再自動釋放，在運行一段時間后，本機的網絡資源就會被全部用光。這樣就會造成系統中任何需要網絡資源的組件都無法正常工作。

官網提示解決辦法為打一個SP1的補丁，和一個修補程序。

下載補丁windows6.1-KB976932-X64.exe(sp1補丁)和442685_intl_x64_zip.exe

SP1的補丁可以去官網下載http://www.microsoft.com/zh-cn/download/details.aspx?id=5842442685_intl_x64_zip.exe官網下載

這兩個補丁我已共享在我的百度網盤

鏈接：https://pan.baidu.com/s/1IzoeO3f8b82TaM65OjnHkw 
提取碼：wy5t 
復制這段內容后打開百度網盤手機App，操作更方便哦

補充說明：打了補丁后重啟服務器觀察了幾天還是有這種情況。

5、調整動態端口范圍

5.1、默認的動態端口范圍：

在Windows vista和windows server 2008以前的系統中動態的客戶端端口范圍是1025到5000；在Windows vista和windows server 2008中，為了遵守IANA的推薦，把范圍擴展成49152到65535。在Windows vista和windows server 2008的環境中，可以用如下命令查看這些配置：

netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp

5.2、重新配置

使用如下命令可以重新配置：

netsh int set dynamic start=number num=range

修改如下：

netsh int ipv4 set dynamicport tcp start=1025 num=60000
netsh int ipv4 set dynamicport udp start=1025 num=60000
netsh int ipv6 set dynamicport tcp start=1025 num=60000
netsh int ipv6 set dynamicport udp start=1025 num=60000

如上所示，可以為每種傳輸層協議及每個版本的IP協議進行單獨的設置，start的最小值是1025，num指的是范圍，最小值是255。

5.3、測試服務器是否能正常telnet和訪問

好吧，問題臨時解決。

可以看到百度也可以訪問了。

6、調整TCP連接快速回收時間

操作系統默認TIME_WAIT的TCP連接回收時間是4分鐘，TCP默認動態端口范圍為開始端口49152，結束端口65535。這樣會使回收TCP過慢導致系統吞吐量下降，甚至出現502訪問失敗問題。

在Windows開始菜單中，單擊“運行”，在“運行”對話框中，輸入“regedit”后按“Enter”打開注冊表編輯器。

在“注冊表編輯器”中打開“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters”路徑。

在“編輯”菜單中，選擇“新建 > DWORD （32-位）值”，輸入名稱“TcpTimedWaitDelay”。

右鍵單擊TcpTimedWaitDelay，選擇“修改”。

在“編輯 DWORD（32位）值”對話框的“基數”區域中，選擇十進制值為“30”，并“確定”。（將4分鐘修改為2分鐘）

7、監控網絡連接使用情況

netstat -ano >> c:\cmd.txt

因為輸出有點多，所以拿到外面來具體分析。

內容如下：

可以看到88這臺服務器（zabbix）有很多time_wait的連接

說明：time_wait狀態的tcp連接：

1.這是一種處于連接完全關閉狀態前的狀態；

2.通常要等上4分鐘（windows server）的時間才能完全關閉；

3.這種狀態下的tcp連接占用句柄與端口等資源，服務器也要為維護這些連接狀態消耗資源；

4.winserver解決這種time_wait的tcp連接只有讓服務器能夠快速回收和重用那些TIME_WAIT的資源：修改注冊表[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]添加dword值TcpTimedWaitDelay=30（30也為微軟建議值；默認為2分鐘）和MaxUserPort：65534(可選值5000 - 65534)；

8、zabbix為什么會出現這么多TIME_WAIT？

表格中的state是TCP連接在agent和server不同階段時的狀態。我們假設每個階段，agent和server都會得到正確的狀態！

passive agent通信的過程如下：

• 1: tcp連接是通過socket通信的，每個socket都是為唯一的，address:port--address:port
• 2: 第二行的SYN/ACK如果沒有發送，那么第一步的SYN會重新發送。在缺省的timeout設置中，如果丟了這個SYN/ACK過程，連接將會被重置(RST),并且這個獲取數據的過程將會失敗！
• 3: 當前的連接是全雙工的工作模式
• 4: PUSH標志表明當前正在傳送數據！
• 7: 沒有其它事要做，關閉連接。在接下來的關閉過程中，agent會保留TIME_WAIT狀態！請去看下TCP連接的3次握手，和TCP關閉的4次揮手過程。 這里并不是正確的連接關閉過程。
• 8: 帶有FIN標志的數據報會被立刻確認，然后zabbix server 立刻知道這個連接已經關閉。
• 9: zabbix server確認連接關閉的時候，它也會立刻發送一個帶FIN的數據包
• 10: 立刻確認第九步的FIN，到此為止，這個連接就關閉了！
• 11：passive zabbix agent的連接過程，并沒有第十一步的數據報！當第十步中，server端確認連接關閉，并轉變狀態為closed之后， agent會把TIME_WAIT掛起兩分鐘。 這意味著這個連接在兩分鐘內是不可重用的。

注意：

使用TCP協議，是為了在不可靠的網絡環境中創建可靠的連接！zabbix并不支持UDP和長連接的方式(persistent connection)

到這里問題基本解決了，不過還得后面繼續觀察，所以先記錄到這里了。后面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~

如果你覺得這篇文章對你有幫助, 請小小打賞下.