Thông lượng TCP OpenVPN rất thấp (cổng 100Mbit, mức sử dụng CPU thấp)


27

Tôi đang gặp tốc độ truyền OpenVPN cực kỳ chậm giữa hai máy chủ. Đối với câu hỏi này, tôi sẽ gọi máy chủ Server A và Server B.

Cả Máy chủ A và Máy chủ B đều đang chạy CentOS 6.6. Cả hai đều được đặt trong các trung tâm dữ liệu với đường truyền 100Mbit và truyền dữ liệu giữa hai máy chủ bên ngoài OpenVPN chạy gần ~ 88Mbps.

Tuy nhiên, khi tôi cố gắng chuyển bất kỳ tệp nào qua kết nối OpenVPN mà tôi đã thiết lập giữa Máy chủ A và Máy chủ B, tôi nhận được thông lượng ngay khoảng 6,5Mb / giây.

Kết quả kiểm tra từ iperf:

[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[  4]  0.0-10.0 sec  7.38 MBytes  6.19 Mbits/sec
[  4]  0.0-10.5 sec  7.75 MBytes  6.21 Mbits/sec
[  5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[  5]  0.0-10.0 sec  7.40 MBytes  6.21 Mbits/sec
[  5]  0.0-10.4 sec  7.75 MBytes  6.26 Mbits/sec

Ngoài các thử nghiệm iperf OpenVPN này, cả hai máy chủ hầu như không hoạt động với tải không.

Máy chủ A được gán IP 10.0.0.1 và đó là máy chủ OpenVPN. Máy chủ B được gán IP 10.0.0.2 và nó là máy khách OpenVPN.

Cấu hình OpenVPN cho Máy chủ A như sau:

port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3

Cấu hình OpenVPN cho Máy chủ B như sau:

port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3

Những gì tôi đã nhận thấy:

1. Suy nghĩ đầu tiên của tôi là tôi đang làm tắc nghẽn CPU trên máy chủ. OpenVPN là một luồng đơn và cả hai máy chủ này đều chạy bộ xử lý Intel Xeon L5520 không phải là nhanh nhất. Tuy nhiên, tôi đã chạy một toplệnh trong một trong các thử nghiệm iperf và nhấn 1để xem mức độ sử dụng CPU theo lõi và thấy rằng tải CPU rất thấp trên mỗi lõi:

top - 14:32:51 up 13:56,  2 users,  load average: 0.22, 0.08, 0.06
Tasks: 257 total,   1 running, 256 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.4%us,  1.4%sy,  0.0%ni, 94.8%id,  0.3%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Cpu3  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu9  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu14 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    946768k total,   633640k used,   313128k free,    68168k buffers
Swap:  4192188k total,        0k used,  4192188k free,   361572k cached

2. Thời gian Ping tăng đáng kể so với đường hầm OpenVPN trong khi iperf đang chạy. Khi iperf không chạy, thời gian ping trên đường hầm luôn là 60ms (bình thường). Nhưng khi iperf đang chạy và đẩy lưu lượng lớn, thời gian ping trở nên thất thường. Bạn có thể xem bên dưới cách thời gian ping ổn định cho đến lần ping thứ 4 khi tôi bắt đầu thử nghiệm iperf:

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms

3. Như đã đề cập ở trên, tôi đã chạy iperf bên ngoài đường hầm OpenVPN và thông lượng là bình thường - ~ 88Mbps một cách nhất quán.

Những gì tôi đã thử:

1. Tôi nghĩ rằng nén có thể làm hỏng mọi thứ, vì vậy tôi đã tắt nén bằng cách xóa comp-lzokhỏi cả hai cấu hình và khởi động lại OpenVPN. Không có cải thiện.

2. Mặc dù trước đây tôi thấy rằng việc sử dụng CPU thấp, tôi nghĩ rằng mật mã mặc định có thể hơi quá nặng để hệ thống theo kịp. Vì vậy, tôi đã thêm cipher RC2-40-CBCvào cả hai cấu hình (một mật mã rất nhẹ) và khởi động lại OpenVPN. Không có cải thiện.

3. Tôi đã đọc trên các diễn đàn khác nhau về cách điều chỉnh đoạn, mssfix và mtu-tun có thể giúp hiệu suất. Tôi đã chơi với một vài biến thể như được mô tả trong bài viết này , nhưng một lần nữa, không có cải thiện.

Bất kỳ ý tưởng về những gì có thể gây ra hiệu suất OpenVPN kém như vậy?


Làm bất kỳ liên kết, ý kiến ​​từ đây giúp đỡ? forum.openvpn.net/topic10593.html
Matt

Hầu hết các đề xuất trong đó có những điều tôi đã thử: 1. kiểm tra tắc nghẽn CPU, 2. xác minh tốc độ truyền mà không cần VPN, 3. chuyển đổi nén, 4. chọn một mật mã nhanh hơn, v.v. chưa: - / Thật kỳ quái. Ngoài tốc độ chậm và thời gian ping cao / dễ bay hơi, tôi không thấy dấu hiệu nào khác về nơi tắc nghẽn có thể xảy ra.
Elliot B.

Cả hai máy trong cùng một trung tâm dữ liệu? 60ms trong cùng một trung tâm dữ liệu là khá cao. Tôi có thể bị cám dỗ để thử cipher nonemặc dù tôi nghi ngờ nó sẽ giúp.
Zoredache

@Zoredache Xin lỗi - Tôi không rõ về vị trí của các máy chủ - máy chủ A ở Dallas và máy chủ B ở Seattle.
Elliot B.

Bạn đã kiểm tra MTU chưa? Esp: tham số tun-mtu, đoạn và mssfix? Tài liệu
Lenniey

Câu trả lời:


26

Sau rất nhiều lần chỉnh sửa tập tin Googling và cấu hình, tôi đã tìm ra giải pháp. Bây giờ tôi đang nhận được tốc độ duy trì 60Mbps và bùng nổ lên tới 80Mbps. Nó chậm hơn một chút so với tốc độ truyền tải tôi nhận được bên ngoài VPN, nhưng tôi nghĩ rằng điều này tốt như nó sẽ nhận được.

Bước đầu tiên là thiết lập sndbuf 0rcvbuf 0trong cấu hình OpenVPN cho cả máy chủ và máy khách.

Tôi đã thực hiện thay đổi đó sau khi thấy một đề xuất để làm như vậy trên một bài đăng trên diễn đàn công cộng (đó là bản dịch tiếng Anh của bài gốc tiếng Nga ) mà tôi sẽ trích dẫn ở đây:

Đó là tháng 7 năm 2004. Tốc độ internet tại nhà thông thường ở các nước phát triển là 256-1024 Kbit / s, ở các nước kém phát triển là 56 Kbit / s. Linux 2.6.7 đã được phát hành cách đây không lâu và 2.6.8 trong đó TCP Windows Size Scale sẽ được bật theo mặc định chỉ được phát hành trong một tháng. OpenVPN đã phát triển tích cực được 3 năm rồi, phiên bản 2.0 gần như đã được phát hành. Một trong những nhà phát triển quyết định thêm một số mã cho bộ đệm ổ cắm, tôi nghĩ để thống nhất kích thước bộ đệm giữa các hệ điều hành. Trong Windows, có điều gì đó không ổn với MTU của bộ điều hợp nếu kích thước bộ đệm tùy chỉnh được đặt, vì vậy cuối cùng nó đã chuyển đổi thành mã sau:

#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endif

Nếu bạn đã sử dụng OpenVPN, bạn nên biết rằng nó có thể hoạt động trên TCP và UDP. Nếu bạn đặt giá trị bộ đệm ổ cắm TCP tùy chỉnh thấp tới 64 KB, thuật toán mở rộng kích thước cửa sổ TCP không thể điều chỉnh Kích thước cửa sổ thành hơn 64 KB. Điều đó nghĩa là gì? Điều đó có nghĩa là nếu bạn đang kết nối với trang VPN khác qua liên kết dài, ví dụ: Hoa Kỳ đến Nga với ping khoảng 100 ms, bạn không thể có tốc độ hơn 5,12 Mbit / s với cài đặt bộ đệm OpenVPN mặc định. Bạn cần ít nhất 640 KB bộ đệm để có được 50 Mbit / s qua liên kết đó. UDP sẽ hoạt động nhanh hơn vì nó không có kích thước cửa sổ nhưng cũng sẽ không hoạt động rất nhanh.

Như bạn đã đoán, bản phát hành OpenVPN mới nhất vẫn sử dụng kích thước bộ đệm ổ cắm 64 KB. Làm thế nào chúng ta nên khắc phục vấn đề này? Cách tốt nhất là không cho phép OpenVPN để đặt kích thước bộ đệm tùy chỉnh. Bạn nên thêm đoạn mã sau vào cả tệp cấu hình máy chủ và máy khách:

sndbuf 0
rcvbuf 0

Tác giả tiếp tục mô tả cách đẩy các điều chỉnh kích thước bộ đệm cho máy khách nếu bạn không tự kiểm soát cấu hình máy khách.

Sau khi tôi thực hiện những thay đổi đó, tốc độ thông lượng của tôi tăng lên tới 20Mb / giây. Sau đó tôi thấy rằng việc sử dụng CPU hơi cao trên một lõi đơn nên tôi đã loại bỏ comp-lzo(nén) khỏi cấu hình trên cả máy khách và máy chủ. Eureka! Tốc độ truyền tăng vọt lên tới 60Mbps duy trì và 80Mbps nổ.

Tôi hy vọng điều này sẽ giúp người khác giải quyết vấn đề của họ với sự chậm chạp của OpenVPN!


4

Sau một vài lần thử, tôi đã đạt được một giải pháp tốt. Trong trường hợp của tôi, câu trả lời của @ Elliot đã không giúp được gì. Googling nhiều hơn, tôi phát hiện ra đoạn trích này để thêm vào cấu hình của máy chủ đã thực hiện công việc

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Tôi có một máy chủ OpenVPN nhỏ đang chạy trên Raspberry PI3 và bây giờ tôi nhận được đường xuống 71 Mbps và đường lên 16Mbps . Tải xuống bị giới hạn vì sức mạnh của CPU. Ngay bây giờ, cấu hình của tôi là như sau:

client-to-client
duplicate-cn
keepalive 10 120
cipher AES-128-CBC
#cipher AES-256-CBC <<<---- lowers the speed to around 50Mbps, still not bad
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
tun-mtu 9000

OpenVPN 2.4.0 arm-unknown-linux-gnuispihf với OpenSSL 1.0.2l

Cảm giác thật kỳ lạ khi một vấn đề như vậy về cấu hình mặc định của bộ đệm vẫn tồn tại.

[EDIT] Tệp client.ovpn của tôi có cấu trúc như thế này:

client
dev tun
proto tcp
remote SERVER.IP.ADDRESS.HERE
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
tun-mtu 9000
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
[...]
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
[...]
-----END OpenVPN Static key V1-----
</tls-auth>

Thiết lập kích thước bộ đệm đã giúp tôi.
Rolf

bạn đã đặt gì trong tệp .ovpn của máy khách?
Patoshi パ ト

@Patoshi ト Tôi đã nhận xét sndbuf và recbuf, đặt mật mã và nén và để lại các tham số mặc định.
Hạt nhân

@Kernel bạn có thể chỉ cho tôi những gì bạn có trong khách hàng của bạn? Tôi đang thực hiện kết nối OpenVPN từ Hồng Kông đến NYC và kết nối chậm và đôi khi bị ngắt kết nối. Tôi cung không chăc tại sao.
Patoshi パ ト

@Patoshi ト Tôi đã chỉnh sửa câu trả lời của mình, kiểm tra lại. Tuy nhiên, tôi sẽ đề nghị bạn thử sử dụng UDP thay vì nó có thể giúp bạn giải quyết vấn đề liên kết không ổn định với máy chủ của bạn. Thật vậy, đó chỉ là một giả định, tôi chưa bao giờ thử đánh giá giải pháp này trong tình huống này.
Hạt nhân

1

Theo Cấu hình, bạn đang sử dụng TCP làm phương tiện vận chuyển cho Đường hầm. Cân nhắc sử dụng UDP thay vì TCP vì lều kết nối TCP xếp chồng để tạo ra sự cố trong các tình huống mất gói.

Để tham khảo xem Tại sao TCP trên TCP là một ý tưởng tồi


Thật không may, UDP không phải là một lựa chọn cho chúng tôi. Chúng tôi cần đảm bảo rằng các gói dữ liệu chúng tôi truyền tải đến như mong đợi. Tuy nhiên, chúng tôi đã thử nghiệm với UDP trước đó và tỷ lệ chuyển nhượng kém vẫn là một vấn đề.
Elliot B.

6
We need to ensure that the data packets we transmit arrive as expected.và không được xử lý bởi giao thức đang được tạo đường hầm? Tại sao bạn nghĩ rằng đường hầm của bạn cần phải là thứ thực thi điều đó?
Zoredache

Đó có thể là trường hợp, nhưng chúng tôi đang sử dụng OpenVPN để triển khai DRBD không đồng bộ khoảng cách xa (nghĩa là sao chép hệ thống tệp). Tính toàn vẹn dữ liệu thực sự quan trọng, do đó, mặc dù DRBD có thể có các cơ chế bên trong để xác minh tính toàn vẹn truyền, tôi muốn giữ nó trên TCP. Dù bằng cách nào, khi chúng tôi có nó trên UDP, chúng tôi vẫn có thông lượng thấp.
Elliot B.

3
@ElliotB. Vì chính DRBD sử dụng TCP để sao chép, nó sẽ truyền lại trong trường hợp gói UDP OpenVPN bị mất. Trên thực tế, sử dụng TCP trong trường hợp này, bạn sẽ thực hiện hai lần truyền lại thay vì một ... một trong số đó sẽ bị loại bỏ. Và bạn có thể đang tạo một cửa sổ khá dài không có lưu lượng DRBD (thậm chí bị hỏng bản sao vì điều này). Một khi bạn nhận được một số packloss trên tuyến đường, bạn sẽ thấy suy nghĩ này tồi tệ như thế nào.
Cáo

@Fox Cảm ơn bạn đã cung cấp làm rõ! Thật vậy, DRBD sử dụng TCP (drbd.linbit.com/users-guide/s-prepare-network.html). Lairsdragon đề xuất trước đó để chuyển sang UDP không phù hợp vào thời điểm đó vì UDP cũng có tốc độ truyền rất thấp, nhưng kể từ khi thực hiện giải pháp tôi đã đăng ở trên, chúng tôi đã chuyển sang UDP và đạt được hiệu suất tăng thêm vài Mbps.
Elliot B.

1

Chúng tôi có hai máy chủ liên lục địa liên kết với nhau, tốc độ giữa chúng lơ lửng khoảng 220 Mbit / s.

Tuy nhiên, bên trong đường hầm OpenVPN (UDP), tốc độ sẽ trung bình ở mức 21 Mbit / s - chậm hơn khoảng 10 lần.

(Có độ trễ đáng kể giữa các máy chủ: khoảng 130 ms và các lần chuyển được đo bằng Iperf3 ở chế độ TCP.)

Đã thử tất cả các đề xuất về câu trả lời ở đây khi viết bài này, và không có gì giúp được.

Điều cuối cùng đã giúp là chút ít này:

--txqueuelen 4000

Theo tài liệu tham khảo OpenVPN:

–txqueuelen n 
(Linux only) Set the TX queue length on the TUN/TAP interface. Currently defaults to 100.

Sau khi đặt tham số này trên máy chủ và máy khách, tôi có thể đạt được tốc độ 'liên kết trực tiếp' tương tự (~ 250Mbit / giây) trong đường hầm OpenVPN.

Tôi đã sử dụng rcvbuf 0sndbuf 0, nhưng ít nhất là một mình , họ không giúp được gì cả.

Tôi đã tìm thấy các đề xuất này ở cả hai: trang này trong các diễn đàn OpenVPN và cũng trong trang này trong wiki UDPspeeder .

Một lưu ý khác: Tôi đã có thể đạt tốc độ cao hơn bằng cách sử dụng chuyển UDP trong iperf, nhưng làm như vậy cũng sẽ gây ra mất gói khá cao.

Nếu tình cờ bạn cần sử dụng VPN để tạo đường hầm hai nơi có liên kết bị mất, tôi khuyên bạn nên xem xét sử dụng một số loại đường hầm Chuyển tiếp Lỗi-Sửa lỗi (FEC) trong chính VPN. Hai cái mà tôi đã tìm được và hợp tác là:

  • UDPspeeder đã nói ở trên , đường hầm kết nối UDP;
  • kcptun , đường hầm kết nối TCP;

Cả hai đều có thể giúp ích rất nhiều cho packloss (bằng cách chi tiêu nhiều băng thông hơn ở nơi đầu tiên), và cuối cùng thậm chí dẫn đến thông lượng dữ liệu cao hơn, ngay cả với chi phí bổ sung, thực sự gọn gàng nếu bạn hỏi tôi.

(Đó là vì mất gói có thể thực sự gây rối mạng , đặc biệt là TCP . Xem trang 6.)

Tôi thích sử dụng OpenVPN trên UDP, vì tất cả các lý do thông thường, nhưng tôi cảm thấy khó đối phó với UDPspeeder khi bạn có cả độ trễ hơn 100ms và tốc độ> 10 Mbit / s.

Tuy nhiên, kcptun đã hoạt động rất tốt với rất ít điều chỉnh và thực sự đã tăng thông lượng máy chủ của chúng tôi với nhau. =)

Trên một ghi chú mở rộng, ở đây bạn có thể tìm thấy một số giải thích chi tiết hơn về việc điều chỉnh một số phần của hiệu suất OpenVPN.


0

Đối với tôi, tôi đã có một máy chủ VPS với thiết lập máy chủ openvpn tại Nhật Bản và kết nối máy khách của tôi đang sử dụng DDWRT ở chế độ máy khách OpenVPN ở NYC. Tôi chỉ nhận được 1-2mbps trên kết nối 100mbit. Điều tốt nhất tôi có thể tối ưu hóa nó là 5mbps, đủ cho những gì tôi cần, nó được tối ưu hóa như tôi có thể làm cho nó tin tưởng.

Cài đặt máy chủ OpenVPN của tôi:

tun-mtu 9000
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
comp-lzo
txqueuelen 4000
######
port 10111
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server x.x.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
#tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_IzA1QdFzHLRFfEoQ.crt
key server_IzA1QdFzHLRFfEoQ.key
auth SHA256
#cipher AES-128-GCM
#cipher AES-128-CBC
#ncp-ciphers AES-128-GCM
#ncp-ciphers AES-128-CBC
#tls-server
#tls-version-min 1.2
#tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
#tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
status /var/log/openvpn/status.log
verb 3

Các cài đặt máy khách DDWRT OpenVPN của tôi cũng được nhìn thấy trong ảnh chụp màn hình của tôi:

tun-mtu 9000
comp-lzo
##########
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_IzA1QdFzHLRFfEoQ name
auth SHA256
auth-nocache
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3

nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.