OpenVPN ประสิทธิภาพต่ำ ฉันมีปัญหา MTU หรือไม่ ทิ้งลงข้างใน

13

ฉันมีปัญหากับอุโมงค์ OpenVPN ซึ่งไม่ถึงความเร็วของสาย เกตเวย์เป็นเซิร์ฟเวอร์เสมือน Debian Jessy ที่โฮสต์ที่ OVH ไคลเอนต์เป็นของฉัน freebsd 10.2 homeserver (Intel I3 Ivy Bridge) หรือ RaspberryPI2 ของฉัน ฉันปิดการเข้ารหัสและการรับรองความถูกต้อง ฉันมีการเชื่อมต่อ FTTH แบบสมมาตร 100mbit / s แต่อุโมงค์มาถึงความเร็ว 20-40mbit / s เท่านั้น การเชื่อมต่อโดยตรง (โดยไม่มีอุโมงค์) ให้ผลตอบแทน 100mbit / s ที่ฉันคาดไว้เสมอ ฉันทดสอบประสิทธิภาพด้วย iperf3 ฉันแรกลองกับเซิร์ฟเวอร์ freebsd ของฉัน ฉันลองตั้งค่าทั้งหมดที่แนะนำเกี่ยวกับ mssfix ชิ้นส่วนและอื่น ๆ ไม่มีอะไรช่วย

จากนั้นฉันคิดว่าบางทีมันอาจเป็นเครื่อง freebsd ดังนั้นฉันจึงติดตั้งราสเบียนเจสซี่ใหม่บน RPI2 ของฉันและทำการทดสอบเชิงลึกเพิ่มเติม:

ก่อนอื่นฉันลบการตั้งค่า MTU ทั้งหมดออกจากการกำหนดค่า OpenVPN และให้เส้นทาง MTU จัดการกับสิ่งต่าง ๆ (หวังว่า) เนื่องจากฉันไม่มีไฟร์วอลล์ที่ใช้งานบนเครื่องทั้งสองเครื่องมันจึงควรใช้งานได้ นี่คือการกำหนดค่า vpn ของฉัน:

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

ก่อนอื่นการทดสอบโดยไม่ต้องใช้ช่องสัญญาณแสดงว่าการเชื่อมต่อกับเซิร์ฟเวอร์นั้นเกือบ 100mbit / s:

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

แพ็กเก็ตของการเชื่อมต่อนี้ฉันทิ้งด้วย tcpdump บนเซิร์ฟเวอร์ คุณสามารถดาวน์โหลดได้ที่นี่ (คุณต้องแตกไฟล์เพื่อเปิดด้วย wireshark): dumpraw.cap.xz

ดังนั้นนี่คือลักษณะการถ่ายโอนข้อมูล "OK" ขนาดเฟรมสูงสุดที่ฉันเห็นคือ 1,514 ดัมพ์ของ iperf3 ไม่มี tunnel

ตอนนี้ฉันทำการทดสอบผ่านอุโมงค์:

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

อ๊ะ ไม่ดีอีกต่อไป โดยเฉพาะคอลัมน์ "Retr" นี้ดูไม่ดีนัก ฉันคิดว่านี่เป็น tcp retransmit และควรมีบางอย่างในการถ่ายโอนข้อมูล เราจะเห็นว่าไม่ใช่กรณี: / CPU ไม่ใช่คอขวดที่นี่เพราะฉันปิดการใช้งาน enrcyption และการตรวจสอบสิทธิ์ CPU อยู่ที่ 20% ที่เซิร์ฟเวอร์และ 50% สำหรับ PI ในระหว่างการทดสอบ

นี่เป็นลักษณะการรับส่งข้อมูลของ OpenVPN ของการทดสอบ: OpenVPN ทราฟฟิกบนส่วนต่อประสานทางกายภาพ

สำหรับฉันมันดูโอเค แต่ฉันไม่รู้ว่าจะมองหาอะไร โปรดดูที่การถ่ายโอนข้อมูลด้วย wireshark: dump_physical.cap.xz

การรับส่งข้อมูลบนอินเทอร์เฟซทันเนลดูดีสำหรับฉันเช่นกัน ดูเหมือนว่าเขาจะลดขนาดเฟรมให้ถูกต้อง (เป็น 1444 เท่าที่ดูเหมือน): การรับส่งข้อมูล iperf3 บนอินเทอร์เฟซทันเนล

นี่คือดัมพ์: dump_tunnel.cap.xz

สำหรับฉันมันดูดี แต่ฉันไม่รู้จริง ๆ ว่าต้องค้นหาอะไรแน่ ฉันทดสอบทุกอย่างด้วยการตั้งค่า OpenVPN บางทีใครบางคนสามารถบอกฉันได้ว่าการจราจรดูโอเคไหม

สิ่งที่ฉันคาดหวังเป็นคำตอบ

อย่างน้อยก็มีคำอธิบายว่าเกิดอะไรขึ้นที่นี่และทำไมมันถึงเป็นอิสระจากซอฟต์แวร์ VPN ที่ฉันใช้ ทุกสิ่งที่ฉันพบบนอินเทอร์เน็ตคือปัญหาเกี่ยวกับ MTU แต่ควรแก้ไขได้ง่ายด้วยการลดอุโมงค์ MTU หรือพารามิเตอร์อื่น ๆ ของ OpenVPN สำหรับฉันแล้วการเปลี่ยนแปลงเล็กน้อย เมื่อคุณดูดัมพ์คุณจะเห็นว่ามันลดขนาดเซ็กเมนต์ tcp และแพ็กเก็ตจะไม่กระจัดกระจาย จะต้องมีอย่างอื่น ผมชอบที่จะรู้ว่าสิ่งที่

ปรับปรุง

ฉันทดสอบสิ่งนี้ด้วยคำว่า strongswan และแม้กระทั่ง softether เป็นปัญหาเดียวกันจริง ๆ (ความเร็วเทียบเคียงไม่มีคอขวด cpu) ฉันงงจริง ๆ ว่ามีปัญหาอะไรที่นี่ ฉันลองเกตเวย์อื่น (RaspberryPi2 กับการเชื่อมต่อที่บ้าน 100/100 เพื่อน)

อัปเดต 2

ฉันสังเกตเห็นว่า iperf3 รายงาน tcp retransmits (retr) แต่ไม่มี retransmits ในการถ่ายโอนข้อมูล (Wireshark ควรเน้นพวกเขา) เกิดอะไรขึ้น?

ฉันได้ลอง OpenVPN บนเครือข่ายท้องถิ่นของฉัน (RaspberryPi2 ถึง FreebsdServer) ถึงแม้ว่าฉันจะมีการส่งสัญญาณใหม่จำนวนมาก (บน LAN?!):

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

ในโหมดย้อนกลับฉันมีหน้าต่างแออัดแปลก ๆ (wtf?):

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

อัปเดต 3

การใช้ iperf กับ udp ส่งผลให้เกิดการบล็อกชั่วคราวของพอร์ตนั้น (พวกเขาส่งอีเมลแจ้งให้ฉันทราบเกี่ยวกับการโจมตี) และการสูญเสียแพ็กเก็ตจำนวนมาก:

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order
vpn  performance  openvpn  mtu 
— Alexander Theißen
แหล่งที่มา
1
หากคุณยังไม่ได้ทำฉันจะลองดู: tun-mtu 9000 fragment 0 mssfix 0(ตัวเลือกจะต้องเพิ่มในสามบรรทัดที่แตกต่างกัน)
— Diamant
ฉันทดสอบแล้วว่า แต่ฉันทดสอบอีกครั้ง สิ่งที่เกิดขึ้นคือมันเริ่มต้นด้วยความเร็วเท่ากัน แต่จากนั้นจุดเชื่อมต่อจะหยุด ซึ่งจะเกิดขึ้นตลอดเวลาเมื่อฉันปิดการใช้งานการกระจายตัวของแพ็กเก็ต OpenVPN คู่มือนี้community.openvpn.net/openvpn/wiki/Gigabit_Networksทำให้คุณคิดว่าระบบปฏิบัติการควรรองรับ แต่เห็นได้ชัดว่าไม่ได้
— Alexander Theißen
โอ้ว้าว. ฉันเห็นลักษณะการทำงานที่แน่นอนบน VPNs ของฉันและฉันมีฮาร์ดแวร์อ้วนที่ปลายทั้งสองและการเชื่อมต่ออินเทอร์เน็ตที่ช้าลง ฉันจะตรวจสอบเพิ่มเติม ถ้าฉันพบสิ่งที่เป็นรูปธรรมฉันจะโพสต์กลับมาที่นี่
— Harald
1
ถ้าฉันเปลี่ยนการทดสอบเป็น UDP (iperf3 -u -b 25m) ฉันจะได้ความเร็วเต็มทั้งภายในและภายนอกอุโมงค์ openvpn ฉันได้รับการยืนยันว่าไม่มีการแตกแฟรกเมนต์เมื่อใช้ TCP - openvpn รายงาน MSS ขนาดเล็กอย่างถูกต้องแพ็กเก็ต tcp ของฉันภายในอุโมงค์มีขนาด 1354 ไบต์และแพ็คเก็ต UDP มาถึงการแยกส่วน ฉันเห็นปรากฏการณ์เช่นเดียวกับคุณ - ค่า CWnd ภายในอุโมงค์มีประมาณครึ่งหนึ่งของสิ่งที่พวกเขาอยู่นอกอุโมงค์และผ่านเป็นครึ่งหนึ่งนอกจากนี้ยังมี แต่ฉันที่สูญเสียที่จะอธิบายว่าทำไม มโนหร
— Harald
1
โอเคฉันขอโทษที่สร้างความหวังผิด ๆ พยายามกำจัดตัวแปรทั้งหมดฉันตั้งค่า OpenVPN ด้วยพารามิเตอร์การกำหนดค่าเดียวกันทำงานบน LAN ท้องถิ่นของฉัน นอกอุโมงค์ 750Mbps ภายในอุโมงค์ 117Mbps แต่ - openvpn ใช้ซีพียู 100% ของคอร์เดียวทั้งสองจุดปลาย ดังนั้นฉันจึงย้ายจุดสิ้นสุดที่บ้านของอุโมงค์อินเทอร์เน็ตของฉันไปยังเซิร์ฟเวอร์ "ของจริง" และเห็น 25Mbps ที่คาดหวังผ่านทางอุโมงค์ของฉัน OpenVPN บนจุดปลายทั้งสองใช้งาน CPU ประมาณ 20% เรื่องสั้นสั้น ๆ - ในกรณีของฉันปัญหาคือจุดปลายอุโมงค์ในบ้านของฉันคือ CPU ที่ถูกผูกไว้ ขออภัย!
— Harald

คำตอบ:

2

สำหรับการเริ่มการทำงานปกติของอุโมงค์ IPerf ภายนอกของคุณควรเป็น UDP / 1194 เป็นโฟลว์ที่คุณมีปัญหาไม่ใช่ TCP / 5201 ลองด้วย -b 100M ก่อน แต่โปรดจำไว้ว่านี่จะสร้างดาต้าแกรมขนาดสูงสุดซึ่งไม่ได้เป็นตัวแทนของทราฟฟิก VPN ของคุณ (ขนาดดาตาแกรมควรเป็นแบบสุ่ม) ปรับด้วยตัวเลือก -l สำหรับขนาดดาตาแกรมและตรวจสอบผลลัพธ์ หากผลลัพธ์ไม่ดี (ฉันจะบอกว่า> 15 หรือ 20% สูญเสีย) คุณอาจสงสัยว่ามีเราเตอร์อินเทอร์เน็ตที่ใช้งานมากเกินไปซึ่งกำลังจะวางแพ็กเก็ตของคุณ

นอกจากนี้อาจเป็นเรื่องที่น่าสนใจที่จะเห็นประสิทธิภาพที่คุณได้รับหากคุณเปลี่ยนอุโมงค์ VPN ของคุณไปเป็นพอร์ต EF Class UDP (ฉันบอกว่า 5061 เพราะ RTP แต่ไม่แน่ใจว่าเราเตอร์อินเทอร์เน็ตทุกตัวมีการกำหนดค่า QoS อย่างถูกต้อง) พอร์ต TCP

สำหรับฉันไม่มีอะไรผิดปกติกับการตั้งค่าของคุณและการวินิจฉัยของคุณจะไม่แสดงอะไรแปลก ๆ ลองใช้ OpenVPN เวอร์ชันอื่นหรือซอฟต์แวร์ VPN อื่น

— 30gd4n
แหล่งที่มา
ทำอย่างนั้น ดูที่ update3 รอให้ ovh ปลดบล็อกพอร์ตเพื่อทำการทดสอบเพิ่มเติม
— Alexander Theißen
อ้าวขอโทษที่ไม่เห็นการอัพเดทครั้งล่าสุด ในขณะที่รอ OVH ลองติดตั้ง VPN ของคุณผ่าน TCP ผลลัพธ์คืออะไร ยังเกี่ยวกับการแก้ไขครั้งที่สองของคุณและการส่งใหม่จาก * BSD ถึง PI; คุณเคยเล่นกับบัฟเฟอร์เซิร์ฟเวอร์ของ iperf หรือไม่ เป็นค่าเริ่มต้น 8kb ไม่รู้ว่าสแต็คทำบน ARM และ Linux ได้อย่างไร แต่ฉันคิดว่ามันจะช่วยได้มากขึ้น
— 30gd4n
ฉันหมายถึงฉันเพิ่มมันหลังจากที่คุณบอกให้ฉัน :) ผลลัพธ์ใน tcp แย่ลง Tcp 443 ไม่ได้สร้างความแตกต่าง สิ่งที่ตลกคือเมื่อฉันใช้github.com/sivel/speedtest-cliนี้เพื่อทดสอบมันจะรายงานว่า 95m และ 75m ขึ้นไป ฉันเชื่อถือ iperf มากกว่านี้ แต่ขึ้นอยู่กับประเภทของการจราจรดังนั้นดูเหมือน Playstation4 ยังใช้เวลานานในการดาวน์โหลดเกมหรือแพทช์ข้ามอุโมงค์ เมื่อถึงบ้านฉันจะทำอุโมงค์โดยตรงระหว่างสอง Rbps ซึ่งอยู่ในสถานที่ต่างกัน แต่ใช้ isp เดียวกัน ฉันทำอย่างนั้นมาก่อนและผลลัพธ์ที่เกือบเหมือนกัน แต่ฉันพยายามทำการทดสอบเพิ่มเติม
— Alexander Theißen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.