999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

一種高效的DNS 重定向?qū)崿F(xiàn)方法*

2021-10-03 04:12:58戴云偉沈春苗
通信技術(shù) 2021年9期
關(guān)鍵詞:用戶(hù)

戴云偉,沈春苗

(1.江蘇省未來(lái)網(wǎng)絡(luò)創(chuàng)新研究院,江蘇 南京 211111;2.南京師范大學(xué),江蘇 南京 210093)

0 引言

域名系統(tǒng)(Domain Name System,DNS)[1-2]提供了方便記憶的域名與復(fù)雜的IP 地址之間的相互映射,促進(jìn)了互聯(lián)網(wǎng)的普及與發(fā)展。互聯(lián)網(wǎng)服務(wù)提供商(Internet Service Provider,ISP)除了提供基礎(chǔ)的用戶(hù)接入互聯(lián)網(wǎng)的服務(wù)外,通常還會(huì)自建DNS系統(tǒng),為用戶(hù)提供域名解析服務(wù)[3]。應(yīng)用程序在訪問(wèn)互聯(lián)網(wǎng)資源之前,一般必須先進(jìn)行域名解析,以獲取數(shù)據(jù)中心(Internet Data Center,IDC)服務(wù)器、內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Delivery Network,CDN)服務(wù)器或緩存服務(wù)器的地址;之后,再與服務(wù)器進(jìn)行數(shù)據(jù)交互。

隨著互聯(lián)網(wǎng)業(yè)務(wù)日新月異,出于利益的考慮,越來(lái)越多的用戶(hù)主動(dòng)或者被動(dòng)修改了終端設(shè)備DNS解析服務(wù)器地址,這可能會(huì)導(dǎo)致DNS 請(qǐng)求出網(wǎng),即由其他ISP 完成DNS 解析服務(wù),因此本地運(yùn)營(yíng)商對(duì)于這部分請(qǐng)求將無(wú)法管控。很顯然,運(yùn)營(yíng)商希望擁有對(duì)DNS 的控制調(diào)度權(quán)限,從而盡量減少跨網(wǎng)請(qǐng)求,并盡可能將用戶(hù)調(diào)度至本網(wǎng)內(nèi)請(qǐng)求資源。這樣不僅可以降低用戶(hù)的解析時(shí)延,還可以減少用戶(hù)跨網(wǎng)訪問(wèn)網(wǎng)絡(luò)資源,尤其是可以減少會(huì)消耗大量帶寬的圖片、語(yǔ)音和視頻類(lèi)資源,因?yàn)檫@會(huì)導(dǎo)致高昂的跨網(wǎng)結(jié)算費(fèi)用。

本文在分析傳統(tǒng)DNS 引流技術(shù)實(shí)現(xiàn)及其缺陷基 礎(chǔ)上,提出了一種基于IP透明技術(shù)(IP_TRANSPARENT)的DNS 引流方法,不僅可以提高性能,而且部署運(yùn)維也相對(duì)簡(jiǎn)單。

1 DNS 重定向應(yīng)用場(chǎng)景

通過(guò)重定向完成對(duì)DNS 系統(tǒng)的管控后,對(duì)于運(yùn)營(yíng)商來(lái)說(shuō),以下列出幾種有實(shí)際應(yīng)用意義的場(chǎng)景。

1.1 惡意域名攔截

如果終端設(shè)備的DNS 解析服務(wù)器被設(shè)置為不法分子搭建的服務(wù)器,此時(shí)用戶(hù)若訪問(wèn)了惡意域名,則可能會(huì)被引導(dǎo)至色情站點(diǎn)、賭博網(wǎng)站、釣魚(yú)網(wǎng)址等[4-6]。

2018 年,黑客利用D-Link 路由器的漏洞,入侵了至少500 個(gè)家用路由器。黑客入侵后更改受害者路由器上的DNS 配置,將受害者的DNS 請(qǐng)求重定向到黑客自己搭建的惡意DNS 服務(wù)器上,最終誘導(dǎo)原本想訪問(wèn)正常銀行網(wǎng)站的受害者訪問(wèn)釣魚(yú)網(wǎng)站,并惡意竊取受害者的銀行賬號(hào)密碼信息[7]。

對(duì)于此類(lèi)攻擊,ISP 通過(guò)DNS 調(diào)度技術(shù)管控域名服務(wù)后,可以攔截DNS 請(qǐng)求,防止用戶(hù)被定向到惡意服務(wù)器,從而保護(hù)用戶(hù)數(shù)據(jù)。

1.2 提高網(wǎng)絡(luò)質(zhì)量

ISP 網(wǎng)內(nèi)(通常包括省內(nèi)和省外)有大量IDC資源,部分ISP 還會(huì)引入大量CDN 服務(wù)器和緩存服務(wù)器,用以緩存大量熱門(mén)圖片、音頻和視頻資源。當(dāng)某個(gè)用戶(hù)因出網(wǎng)DNS 請(qǐng)求,導(dǎo)致被調(diào)度到網(wǎng)外的情況時(shí),ISP 可以通過(guò)DNS 引流技術(shù)將用戶(hù)引入本網(wǎng)內(nèi)IDC 資源或者緩存服務(wù)器,避免了跨網(wǎng)傳輸。這不僅可以提高用戶(hù)訪問(wèn)速度,還可以降低ISP 網(wǎng)間結(jié)算費(fèi)用[8]。雖然工信部于2020 年7 月起,取消了中國(guó)移動(dòng)、中國(guó)電信、中國(guó)聯(lián)通間的單向結(jié)算政策,實(shí)行對(duì)等互聯(lián),互不結(jié)算;但是對(duì)于其他運(yùn)營(yíng)商,如廣電還是需要進(jìn)行跨網(wǎng)結(jié)算[9]。

1.3 日志獲取與分析

完全掌控DNS 解析服務(wù)情況下,運(yùn)營(yíng)商可以獲取到完整的DNS 請(qǐng)求響應(yīng)數(shù)據(jù)。通過(guò)對(duì)數(shù)據(jù)進(jìn)行挖掘,不僅可以幫助運(yùn)營(yíng)商提高IDC 資源引入的準(zhǔn)確度,還可以將數(shù)據(jù)用于安全分析,如郭烜臻等人提出的重綁定攻擊檢測(cè)方法[10],吉星等人提出的基于DNS 日志的識(shí)別異常查詢(xún)[11],以及王琪等人提出的通過(guò)處理DNS服務(wù)器日志來(lái)檢測(cè)DNS隧道[12]的方法等。

基于以上場(chǎng)景,通過(guò)實(shí)現(xiàn)高效DNS 引流技術(shù)來(lái)完成DNS 調(diào)度對(duì)于ISP 來(lái)說(shuō)有一定的現(xiàn)實(shí)意義。

2 DNS 重定向技術(shù)原理

如圖1 所示,用戶(hù)將終端A 的DNS 解析服務(wù)器地址設(shè)置為C。當(dāng)需要解析域名時(shí),正常的報(bào)文路徑為:

圖1 重定向工作原理

(1)終端A發(fā)出報(bào)文(MacA,IpA->MacBA,IpC),其中,MacA 表示A 的網(wǎng)卡物理地址(Media Access Control Address,MAC)地址,IpA 表示網(wǎng)卡的IP,MacBA 表示策略路由器B 與A 連接的網(wǎng)卡MAC 地址,IpC 為非運(yùn)營(yíng)商DNS 服務(wù)器C 的IP 地址;

(2)策略路由器B 根據(jù)正常的路由策略會(huì)向服務(wù)器C 轉(zhuǎn)發(fā)出報(bào)文(MacBC,IpA->MacC,IpC);

(3)服務(wù)器C 收到請(qǐng)求報(bào)文后,發(fā)出DNS 響應(yīng)報(bào)文(MacC,IpC->MacBC,IpA);

(4)策略路由器B 根據(jù)正常路由策略,轉(zhuǎn)發(fā)報(bào)文(MacBA,IpC->MacA,IpA),這里剛好與第(1)步對(duì)應(yīng),解析過(guò)程結(jié)束。

DNS 重定向需要向策略路由器下發(fā)重定向策略,但不同運(yùn)營(yíng)商或者廠家的硬件設(shè)備,下發(fā)方式和命令都不一樣。在Linux 中下發(fā)重定向路由策略類(lèi)似下面的命令:

該命令表示對(duì)于目的地址為IpC 且子網(wǎng)掩碼為255.255.255.255 的報(bào)文,通過(guò)與其直連的服務(wù)器D的IpD 地址轉(zhuǎn)發(fā)出去。但是該方法會(huì)將所有流量都引入服務(wù)器D,D 需要將非DNS 報(bào)文重新轉(zhuǎn)發(fā)給C服務(wù)器。如此,終端A 與服務(wù)器C 無(wú)法感知重定向服務(wù)器D 的存在。重定向參與情況下,報(bào)文的路徑如下:

(1)終端A發(fā)出報(bào)文(MacA,IpA->MacBA,IpC);

(2)策略路由器B 根據(jù)重定向路由策略轉(zhuǎn)發(fā)出報(bào)文(MacBD,IpA->MacD,IpC);

(3)服務(wù)器D 收到請(qǐng)求報(bào)文后,可以轉(zhuǎn)發(fā)給運(yùn)營(yíng)商內(nèi)部DNS 解析服務(wù)器,獲取結(jié)果后,發(fā)回DNS 響應(yīng)報(bào)文(MacD,IpC->MacBD,IpA);

(4)策略路由器B 根據(jù)正常路由策略,轉(zhuǎn)發(fā)報(bào)文(MacBA,IpC->MacA,IpA),這里剛好與第(1)步對(duì)應(yīng),解析過(guò)程結(jié)束。

3 DNS 重定向?qū)崿F(xiàn)

通過(guò)向策略路由器下發(fā)策略,將報(bào)文引流至重定向服務(wù)器,此種情況下,報(bào)文的目的地址為非本機(jī)。以(CentOS Linux release 7.8.2003)為例,報(bào)文進(jìn)入內(nèi)核以后,需要通過(guò)函數(shù)ip_route_input_slow來(lái)查找路由,以下為部分代碼片段:

其中,第1 918 行會(huì)進(jìn)行路由查找。因?yàn)榉潜緳C(jī)目的地址的報(bào)文最終的res.type 為RTN_UNICAST,執(zhí)行至1 936 行。該行相當(dāng)于判斷net.ipv4.ip_forward 是否為1,若為1,那么報(bào)文就會(huì)被轉(zhuǎn)發(fā);若為0,報(bào)文在此處就會(huì)被刪除。正常情況下,該值默認(rèn)設(shè)置為0,所以報(bào)文會(huì)被刪除。

根據(jù)之前的分析,重定向首先要解決的就是這個(gè)報(bào)文會(huì)被刪除的問(wèn)題。下面介紹兩種實(shí)現(xiàn)方法。

3.1 基于DNAT 的傳統(tǒng)實(shí)現(xiàn)方法

傳統(tǒng)的實(shí)現(xiàn)方式一般是基于Linux 內(nèi)核中的網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation,NAT),它由Netfilter 和Iptables 兩個(gè)獨(dú)立的部件構(gòu)成[13-14]。

(1)Netfilter 組件。它是Linux 內(nèi)核空間的一部分,在報(bào)文流經(jīng)內(nèi)核網(wǎng)絡(luò)協(xié)議棧的關(guān)鍵節(jié)點(diǎn)設(shè)置了一系列鉤子(HOOK)點(diǎn),在每個(gè)HOOK 節(jié)點(diǎn)都設(shè)置了相應(yīng)的鉤子函數(shù)。同時(shí)該框架為用戶(hù)提供了接口,用戶(hù)可以編寫(xiě)程序調(diào)用接口在鉤子節(jié)點(diǎn)處注冊(cè)鉤子函數(shù)。當(dāng)數(shù)據(jù)分組流經(jīng)每個(gè)鉤子關(guān)鍵檢測(cè)節(jié)點(diǎn)的時(shí)候,Linux 內(nèi)核會(huì)判斷是否有鉤子函數(shù)注冊(cè)在該鉤子節(jié)點(diǎn)處,如果有將會(huì)根據(jù)鉤子函數(shù)中定義的規(guī)則對(duì)數(shù)據(jù)分組的流向做出相應(yīng)的處理。

(2)Iptables 組件。它是Netfilter 框架在用戶(hù)空間的體現(xiàn)。使用者可以在用戶(hù)空間通過(guò)Iptables對(duì)Linux 內(nèi)核協(xié)議棧中定義的數(shù)據(jù)分組過(guò)濾規(guī)則進(jìn)行增加、修改和刪除等操作。基本命令格式為:Iptables [-t 表名]命令選項(xiàng)[鏈名][條件匹配]- j 目標(biāo)動(dòng)作或跳轉(zhuǎn)]

具體實(shí)現(xiàn)方式以CentOS 7 為例,執(zhí)行以下命令:

該命令會(huì)在網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation,NAT)表 的NF_INET_PRE_ROUTING上注冊(cè)目的地址轉(zhuǎn)換(Destination Network Address Translation,DNAT)目標(biāo)函數(shù)。DNAT 是NAT 的一種,可以對(duì)數(shù)據(jù)包中的目的IP 地址和目的端口進(jìn)行地址轉(zhuǎn)換,轉(zhuǎn)換之后地址為本機(jī)地址。

該命令會(huì)將所有目的地址20.1.0.2 的報(bào)文修改為30.1.0.2。Linux 內(nèi)核中有關(guān)報(bào)文的處理流程為ip_rcv->NF_INET_PRE_ROUTING 鏈的HOOK 函數(shù)->ip_ rcv_finish->ip_route_input_slow,因此修改報(bào)文的過(guò)程是在路由之前。這樣fib_lookup 函數(shù)執(zhí)行后,res.type 的值為RTN_LOCAL,代碼最終會(huì)執(zhí)行到1 933行,成功提交至本地。這一過(guò)程依賴(lài)于連接跟蹤表,對(duì)于用戶(hù)數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocol,UDP)協(xié)議,一次DNS 請(qǐng)求,連接跟蹤表會(huì)新增一條條目,該條目包含16 列,如表1 所示。

表1 連接跟蹤表?xiàng)l目信息表

報(bào)文被修改后,應(yīng)用層軟件就可以接受到該報(bào)文,進(jìn)行解析并提供響應(yīng),但應(yīng)用層發(fā)出去的報(bào)文源地址為30.1.0.2。此時(shí),NAT 模塊在內(nèi)核中再次起作用,根據(jù)連接跟蹤表的記錄,即將源地址還原為30.1.0.2。這樣終端就無(wú)法感知這一重定向的過(guò)程。

該方法的缺陷即是DNAT 本身,因?yàn)樗且粋€(gè)查表的過(guò)程。為了完成映射過(guò)程,內(nèi)核需要維護(hù)連接跟蹤表,即每個(gè)連接一個(gè)條目,通過(guò)增、刪、查等操作,來(lái)實(shí)現(xiàn)IP 地址的轉(zhuǎn)換與還原。此外,為了實(shí)現(xiàn)這一過(guò)程,內(nèi)核還必須使用鎖機(jī)制及多CPU的之間的同步,而這一操作過(guò)程會(huì)降低整體服務(wù)性能。同時(shí),內(nèi)存占用會(huì)隨著鏈接跟蹤表?xiàng)l目數(shù)的增多而增加。

3.2 基于IP_TRANSPARENT 的實(shí)現(xiàn)方法

基于IP_TRANSPARENT 的實(shí)現(xiàn)方法的技術(shù)優(yōu)勢(shì)就在于,使用策略路由表避免了NAT 過(guò)程,從而完成重定向的過(guò)程。為了實(shí)現(xiàn)這一目標(biāo)需要解決以下3 個(gè)問(wèn)題。

3.2.1 內(nèi)核如何將非本機(jī)IP 的報(bào)文轉(zhuǎn)送至本機(jī)

根據(jù)第3 節(jié)的描述,目的地址非本機(jī)的報(bào)文會(huì)被刪除,為了將報(bào)文送至本機(jī),使用策略路由表來(lái)實(shí)現(xiàn)。

如圖2 所示,報(bào)文進(jìn)入路由匹配過(guò)程后,先根據(jù)rule 匹配找到路由表,然后使用該路由表中的條目進(jìn)行路由匹配。這里面的local 表、main 表和default 表是內(nèi)核內(nèi)置的。在Linux 中,函數(shù)fib_lookup 中的傳遞參數(shù)res.type 將決定報(bào)文的類(lèi)型。根據(jù)第2 節(jié)中的第1 927 行可知,當(dāng)返回的類(lèi)型為RTN_LOCAL 時(shí),報(bào)文就會(huì)被發(fā)送至本機(jī)。通過(guò)如下配置可以實(shí)現(xiàn)此目的:

圖2 策略路由表匹配過(guò)程

第1 行表示創(chuàng)建新的自定義策略路由表;第2行表示對(duì)從eth0 口進(jìn)入DNS UDP 報(bào)文設(shè)置標(biāo)識(shí)為0x66;第3 行表示對(duì)于標(biāo)識(shí)為0x66 的報(bào)文,會(huì)進(jìn)行rt_test 自定義路由表的路由查詢(xún);第4 行表示對(duì)于該路由表的所有報(bào)文都屬于local 類(lèi)型,也就是res.type 的返回值RTN_LOCAL。

3.2.2 如何使應(yīng)用層能以非源地址發(fā)送報(bào)文

默認(rèn)情況下IP 路由在發(fā)送報(bào)文之前需要查找路由,中間有一個(gè)步驟就是調(diào)用__ip_dev_find 來(lái)查找源地址所屬于的網(wǎng)卡。顯然這里要發(fā)送的源地址是非本機(jī)的,如果不做特殊處理,報(bào)文會(huì)因?yàn)闊o(wú)法查找到所屬網(wǎng)卡而刪除。route.c 有如下代碼片段:

第2 266行表示若是設(shè)置了IP_TRANSPARENT,那么就會(huì)跳過(guò)源網(wǎng)卡查找階段,這就避免了報(bào)文被刪除。通過(guò)如下片段即可設(shè)置IP_TRANSPARENT選項(xiàng):

第3 行setsockopt 設(shè)置了IP_TRANSPARENT 選項(xiàng);第7 行將非本機(jī)源地址綁定至socket。

3.2.3 如何實(shí)現(xiàn)源地址的保存與還原

傳統(tǒng)的方法由NAT 幫助完成還原,而基于IP_TRANSPARENT 的方法則必須由應(yīng)用層來(lái)自己完成這一還原過(guò)程。其實(shí)現(xiàn)方法就是先保存源地址,發(fā)送之前再還原回源地址。為了獲取接受報(bào)文的源地址,需要使用recvmsg 來(lái)接受報(bào)文而不是常用的recvfrom,因?yàn)閞ecvmsg 可以獲取源地址,并保存下來(lái)。發(fā)送的時(shí)候,將接受時(shí)保存的源地址填充至struct msghdr 結(jié)構(gòu)體,再使用sendmsg 函數(shù)來(lái)發(fā)送響應(yīng)報(bào)文。

以Unbound 1.13.1 為例,用于接受UDP 請(qǐng)求報(bào)文的函數(shù)為comm_point_udp_ancil_callback,其內(nèi)部就是調(diào)用的recvmsg 函數(shù)。發(fā)送DNS 響應(yīng)報(bào)文使用的函數(shù)為comm_point_send_udp_msg_if,其內(nèi)部調(diào)用的也就是為sendmsg 函數(shù)。

4 性能對(duì)比實(shí)驗(yàn)驗(yàn)證

4.1 測(cè)試方案

為了降低中間設(shè)備對(duì)時(shí)延的影響,測(cè)試采用兩臺(tái)設(shè)備網(wǎng)卡直連方式,網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖3 所示。

圖3 實(shí)驗(yàn)拓?fù)浣Y(jié)構(gòu)

兩臺(tái)設(shè)備均為4 核E3-1225 CPU,千兆網(wǎng)卡。Client 網(wǎng)卡的MAC 地址為00:90:11:7e:03:6a,IP 配置為10.1.0.2,測(cè)試軟件為Dnsperf 2.5.2[15]。Server網(wǎng)卡的Mac 地址為00:70:27:f0:00:c,IP 配置為30.1.0.2,DNS 服務(wù)軟件為Unbound 1.31.1[16]。為了測(cè)試,需要配置地址解析協(xié)議(Address Resolution Protocol,ARP)和路由如下所述。

(1)Client 的配置:

(2)Server 的配置:

完成以上配置后,再選擇3.1 或者3.2 的配置,就可以使用dig www.nat.test @20.1.0.2 進(jìn)行測(cè)試,若可以正常解析,則證明配置成功。

4.2 基于DNAT 的性能

為了實(shí)現(xiàn)DNAT,服務(wù)器需要配置iptables 如下:

iptables -t nat -I PREROUTING -p udp -d 20.1.0.0/24 -j DNAT --to 30.1.0.2

基于DNAT 技術(shù)性能測(cè)試結(jié)果如下:

可以看出每秒可以處理的請(qǐng)求數(shù)為160 000 左右。單個(gè)請(qǐng)求的平均時(shí)延為612 μs。

共測(cè)試了3 次,每秒處理請(qǐng)求數(shù)分別為:158 605、154 992,、160 480。平均每秒處理158 025 個(gè)請(qǐng)求。

4.3 基于IP_TRANSPARENT 的性能

測(cè)試服務(wù)器的配置參考3.2 中的說(shuō)明。基于IP_TRANSPARENT 技術(shù)的性能測(cè)試結(jié)果如下:

可以看出每秒處理的請(qǐng)求數(shù)為200 000 左右,單個(gè)請(qǐng)求的平均時(shí)延為469 μs。

共測(cè)試3 次,每秒處理請(qǐng)求數(shù)分別為:209 017、206 483、208 769。平均每秒處理208 089 個(gè)請(qǐng)求。

5 結(jié)語(yǔ)

本文介紹了幾種DNS 重定向應(yīng)用場(chǎng)景,分析了常用傳統(tǒng)實(shí)現(xiàn)方法,闡述了內(nèi)核對(duì)于UDP 報(bào)文處理的部分流程,再結(jié)合Netfilter/Iptables、策略路由及IP_TRANSPARENT 技術(shù)提出DNS 的重定向方法。經(jīng)實(shí)驗(yàn)驗(yàn)證,特定硬件設(shè)備條件下報(bào)文處理性能提升約為25%,每秒處理約50 000 個(gè)請(qǐng)求。

本文方法不僅性能有所提升,而且與現(xiàn)網(wǎng)廣泛使用的DNAT 技術(shù)相比,由于避免了使用連接跟蹤表,不但節(jié)省了額外的解析時(shí)延和內(nèi)存的開(kāi)銷(xiāo),而且不受限于連接跟蹤表的容量,因此具有較高的實(shí)際應(yīng)用意義和技術(shù)參考價(jià)值。

猜你喜歡
用戶(hù)
雅閣國(guó)內(nèi)用戶(hù)交付突破300萬(wàn)輛
您撥打的用戶(hù)已戀愛(ài),請(qǐng)稍后再哭
關(guān)注用戶(hù)
關(guān)注用戶(hù)
兩新黨建新媒體用戶(hù)與全網(wǎng)新媒體用戶(hù)之間有何差別
關(guān)注用戶(hù)
關(guān)注用戶(hù)
挖掘用戶(hù)需求尖端科技應(yīng)用
Camera360:拍出5億用戶(hù)
100萬(wàn)用戶(hù)
主站蜘蛛池模板: 97在线免费| 东京热一区二区三区无码视频| 亚洲成av人无码综合在线观看| 久久天天躁狠狠躁夜夜2020一| 日本人又色又爽的视频| 试看120秒男女啪啪免费| 四虎AV麻豆| 亚洲av无码人妻| 免费午夜无码18禁无码影院| 亚洲av无码专区久久蜜芽| 日本不卡免费高清视频| 中文字幕在线观看日本| 国产亚洲精品自在久久不卡 | 日韩精品中文字幕一区三区| 一级在线毛片| 国产精品99r8在线观看 | 天天综合网色| 91热爆在线| 视频国产精品丝袜第一页| 一级爆乳无码av| 亚洲AⅤ无码日韩AV无码网站| 国产午夜福利片在线观看| 深夜福利视频一区二区| 无码中文字幕精品推荐| 国产黑丝视频在线观看| 伊人色综合久久天天| 午夜精品久久久久久久无码软件 | 性做久久久久久久免费看| 国产一级毛片网站| 嫩草国产在线| 日韩视频免费| 波多野结衣中文字幕一区| 国产精品理论片| 成人午夜免费观看| 538精品在线观看| 亚洲天堂免费在线视频| 亚洲无码37.| 亚洲精品人成网线在线| 国产精品白浆无码流出在线看| 中文字幕波多野不卡一区| 一区二区三区在线不卡免费| 日韩欧美国产中文| 亚洲精品你懂的| 无码内射在线| 国产免费网址| 天天综合亚洲| 久久综合伊人77777| 亚洲色欲色欲www网| 国产剧情一区二区| 无遮挡国产高潮视频免费观看| 91美女视频在线| 欧美精品黑人粗大| 人妻21p大胆| 久久综合丝袜日本网| 日本在线欧美在线| 国产高清精品在线91| 国产在线观看人成激情视频| 污污网站在线观看| 天天躁夜夜躁狠狠躁躁88| 欧美成人午夜视频| 日韩色图在线观看| 欧美高清视频一区二区三区| 国产成人精品午夜视频'| 国产夜色视频| 国产精品爆乳99久久| 久久精品国产精品青草app| 国产精品成人免费视频99| 狠狠操夜夜爽| jizz在线免费播放| 老司国产精品视频91| 亚洲av片在线免费观看| 2020久久国产综合精品swag| 成人欧美日韩| 狠狠亚洲五月天| 久久福利片| 亚洲欧美综合另类图片小说区| 国产一区免费在线观看| 91福利在线看| 在线不卡免费视频| 99久久无色码中文字幕| 国产99久久亚洲综合精品西瓜tv| 天天色天天操综合网|