ทำไมคุณไม่ควรใช้ WireGuard

WireGuard ได้รับความสนใจอย่างมากเมื่อเร็ว ๆ นี้ อันที่จริงแล้วมันเป็นดาวดวงใหม่ในกลุ่ม VPN แต่เขาดีเท่าที่เขาดูเหมือน? ฉันต้องการหารือเกี่ยวกับข้อสังเกตและทบทวนการใช้งาน WireGuard เพื่ออธิบายว่าเหตุใดจึงไม่ใช่โซลูชันที่จะมาแทนที่ IPsec หรือ OpenVPN

ในบทความนี้ ฉันต้องการจะหักล้างตำนานบางอย่าง [เกี่ยวกับ WireGuard] ใช่จะใช้เวลาอ่านนานดังนั้นหากคุณยังไม่ได้ชงชาหรือกาแฟให้ตัวเองก็ถึงเวลาทำ ฉันอยากจะขอบคุณ Peter ที่แก้ไขความคิดวุ่นวายของฉัน

ฉันไม่ได้ตั้งเป้าหมายในการทำให้เสื่อมเสียชื่อเสียงของผู้พัฒนา WireGuard ลดค่าความพยายามหรือความคิดของพวกเขา ผลิตภัณฑ์ของพวกเขาใช้งานได้ แต่โดยส่วนตัวแล้วฉันคิดว่ามีการนำเสนอที่แตกต่างอย่างสิ้นเชิงจากที่เป็นอยู่จริง - นำเสนอเพื่อทดแทน IPsec และ OpenVPN ซึ่งในความเป็นจริงไม่มีอยู่จริงในขณะนี้

ตามหมายเหตุ ฉันต้องการเพิ่มเติมว่าความรับผิดชอบสำหรับการวางตำแหน่งของ WireGuard นั้นขึ้นอยู่กับสื่อที่พูดถึงเรื่องนี้ ไม่ใช่ตัวโครงการเองหรือผู้สร้าง

เมื่อเร็ว ๆ นี้ยังไม่มีข่าวดีเกี่ยวกับเคอร์เนลลินุกซ์ ดังนั้นเราจึงได้รับการบอกเล่าเกี่ยวกับช่องโหว่ร้ายแรงของโปรเซสเซอร์ซึ่งถูกปรับระดับโดยซอฟต์แวร์ และ Linus Torvalds พูดถึงเรื่องนี้อย่างหยาบคายและน่าเบื่อเกินไปในภาษาที่เป็นประโยชน์ของผู้พัฒนา ตัวกำหนดตารางเวลาหรือสแต็คเครือข่ายระดับศูนย์ยังไม่ใช่หัวข้อที่ชัดเจนสำหรับนิตยสารแบบเคลือบเงา และนี่คือ WireGuard

บนกระดาษ ทุกอย่างดูดี: เทคโนโลยีใหม่ที่น่าตื่นเต้น

แต่ลองดูให้ละเอียดกว่านี้อีกนิด

กระดาษสีขาวของ WireGuard

บทความนี้อ้างอิงจาก เอกสาร WireGuard อย่างเป็นทางการเขียนโดย Jason Donenfeld เขาอธิบายแนวคิด วัตถุประสงค์ และการใช้งานทางเทคนิคของ [WireGuard] ในเคอร์เนล Linux ที่นั่น

ประโยคแรกอ่าน:

WireGuard […] มีจุดมุ่งหมายเพื่อแทนที่ทั้ง IPsec ในกรณีการใช้งานส่วนใหญ่และพื้นที่ผู้ใช้ยอดนิยมอื่นๆ และ/หรือโซลูชันที่ใช้ TLS เช่น OpenVPN ในขณะที่มีความปลอดภัย มีประสิทธิภาพ และใช้งาน [เครื่องมือ] ได้ง่ายขึ้น

แน่นอนว่าข้อได้เปรียบหลักของเทคโนโลยีใหม่ทั้งหมดก็คือ ความสะดวก [เมื่อเทียบกับรุ่นก่อน]. แต่ VPN ก็ควรเป็นเช่นกัน มีประสิทธิภาพและปลอดภัย.

แล้วยังไงต่อ?

หากคุณบอกว่านี่ไม่ใช่สิ่งที่คุณต้องการ [จาก VPN] คุณสามารถจบการอ่านได้ที่นี่ อย่างไรก็ตาม ฉันจะทราบว่างานดังกล่าวถูกกำหนดไว้สำหรับเทคโนโลยีการขุดอุโมงค์อื่นๆ

ข้อความที่น่าสนใจที่สุดของข้อความข้างต้นอยู่ในคำว่า "ในกรณีส่วนใหญ่" ซึ่งแน่นอนว่าสื่อมวลชนไม่สนใจ ดังนั้นเราจึงลงเอยด้วยความวุ่นวายที่เกิดจากความประมาทเลินเล่อนี้ - ในบทความนี้

ทำไมคุณไม่ควรใช้ WireGuard

WireGuard จะแทนที่ [IPsec] site-to-site VPN ของฉันหรือไม่

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

WireGuard จะนำ RoadWarrior ของฉันจากแล็ปท็อปไปยังศูนย์ข้อมูลหรือไม่

เลขที่ ตอนนี้ WireGuard ไม่มีฟีเจอร์สำคัญๆ จำนวนมากที่ใช้เพื่อให้สามารถทำสิ่งนี้ได้ ตัวอย่างเช่น ไม่สามารถใช้ที่อยู่ IP แบบไดนามิกบนฝั่งเซิร์ฟเวอร์ช่องสัญญาณได้ และสิ่งนี้เพียงอย่างเดียวจะทำลายสถานการณ์ทั้งหมดของการใช้ผลิตภัณฑ์ดังกล่าว

IPFire มักใช้สำหรับลิงก์อินเทอร์เน็ตราคาถูก เช่น การเชื่อมต่อ DSL หรือสายเคเบิล สิ่งนี้เหมาะสมสำหรับธุรกิจขนาดเล็กหรือขนาดกลางที่ไม่ต้องการไฟเบอร์ที่รวดเร็ว [หมายเหตุจากผู้แปล: อย่าลืมว่าในแง่ของการสื่อสาร รัสเซียและบางประเทศ CIS ล้ำหน้ากว่ายุโรปและสหรัฐอเมริกามาก เพราะเราเริ่มสร้างเครือข่ายของเราในภายหลัง และด้วยการถือกำเนิดของเครือข่ายอีเธอร์เน็ตและไฟเบอร์ออปติกในฐานะ มาตรฐาน มันง่ายกว่าสำหรับเราที่จะสร้างใหม่ ในประเทศเดียวกันของสหภาพยุโรปหรือสหรัฐอเมริกา การเข้าถึงบรอดแบนด์ xDSL ที่ความเร็ว 3-5 Mbps ยังคงเป็นบรรทัดฐานทั่วไป และการเชื่อมต่อไฟเบอร์ออปติกมีค่าใช้จ่ายที่ไม่สมจริงตามมาตรฐานของเรา ดังนั้นผู้เขียนบทความจึงกล่าวถึงการเชื่อมต่อ DSL หรือสายเคเบิลเป็นบรรทัดฐาน ไม่ใช่สมัยโบราณ] อย่างไรก็ตาม DSL, เคเบิล, LTE (และวิธีการเข้าถึงแบบไร้สายอื่นๆ) มีที่อยู่ IP แบบไดนามิก แน่นอนว่าบางครั้งพวกเขาไม่ได้เปลี่ยนบ่อยนัก แต่ก็เปลี่ยน

มีโครงการย่อยที่เรียกว่า "wg-ไดนามิก"ซึ่งเพิ่ม userspace daemon เพื่อเอาชนะข้อบกพร่องนี้ ปัญหาใหญ่ที่เกิดขึ้นกับสถานการณ์ของผู้ใช้ที่อธิบายไว้ข้างต้นคือการซ้ำเติมของการกำหนดที่อยู่ IPv6 แบบไดนามิก

จากมุมมองของผู้จัดจำหน่าย ทั้งหมดนี้ก็ดูไม่ค่อยดีนัก หนึ่งในเป้าหมายของการออกแบบคือการทำให้โปรโตคอลเรียบง่ายและสะอาดตา

น่าเสียดายที่ทั้งหมดนี้กลายเป็นเรื่องง่ายและดั้งเดิมเกินไป เราจึงต้องใช้ซอฟต์แวร์เพิ่มเติมเพื่อให้การออกแบบทั้งหมดนี้ใช้งานได้จริง

WireGuard ใช้งานง่ายมากไหม

ยัง. ฉันไม่ได้บอกว่า WireGuard จะไม่เป็นทางเลือกที่ดีสำหรับการขุดอุโมงค์ระหว่างสองจุด แต่สำหรับตอนนี้มันเป็นเพียงผลิตภัณฑ์รุ่นอัลฟ่าที่ควรจะเป็น

แต่จริงๆแล้วเขาทำอะไร? IPsec ดูแลรักษายากกว่าจริงหรือ?

เห็นได้ชัดว่าไม่ ผู้จำหน่าย IPsec คิดเรื่องนี้และจัดส่งผลิตภัณฑ์ของตนพร้อมกับอินเทอร์เฟซ เช่น IPFire

ในการตั้งค่าอุโมงค์ VPN ผ่าน IPsec คุณจะต้องมีชุดข้อมูลห้าชุดที่คุณจะต้องป้อนในการกำหนดค่า: ที่อยู่ IP สาธารณะของคุณเอง, ที่อยู่ IP สาธารณะของฝ่ายรับ, ซับเน็ตที่คุณต้องการทำให้เป็นสาธารณะผ่าน การเชื่อมต่อ VPN นี้และรหัสที่แชร์ล่วงหน้า ดังนั้น VPN จึงตั้งค่าได้ภายในไม่กี่นาทีและเข้ากันได้กับผู้ให้บริการรายใดก็ได้

น่าเสียดายที่มีข้อยกเว้นบางประการในเรื่องนี้ ใครก็ตามที่พยายามขุดอุโมงค์ผ่าน IPsec ไปยังเครื่อง OpenBSD รู้ว่าฉันกำลังพูดถึงอะไร มีตัวอย่างที่น่าปวดหัวอยู่สองสามตัวอย่าง แต่จริงๆ แล้วมีแนวทางปฏิบัติที่ดีสำหรับการใช้ IPsec อีกมากมาย

เกี่ยวกับความซับซ้อนของโปรโตคอล

ผู้ใช้ไม่ต้องกังวลเกี่ยวกับความซับซ้อนของโปรโตคอล

หากเราอาศัยอยู่ในโลกที่สิ่งนี้เป็นข้อกังวลของผู้ใช้อย่างแท้จริง เราคงจะกำจัด SIP, H.323, FTP และโปรโตคอลอื่นๆ ที่สร้างขึ้นเมื่อสิบกว่าปีก่อนซึ่งใช้งานไม่ได้กับ NAT

มีหลายสาเหตุที่ IPsec ซับซ้อนกว่า WireGuard: มันทำหลายสิ่งหลายอย่าง ตัวอย่างเช่น การตรวจสอบผู้ใช้โดยใช้ชื่อผู้ใช้ / รหัสผ่าน หรือซิมการ์ดด้วย EAP มันมีความสามารถเพิ่มเติมในการเพิ่มใหม่ วิทยาการเข้ารหัสลับ.

และ WireGuard ไม่มีสิ่งนั้น

และนั่นหมายความว่า WireGuard จะหยุดทำงานเมื่อถึงจุดหนึ่ง เนื่องจากหนึ่งในการเข้ารหัสแบบดั้งเดิมจะอ่อนแอลงหรือถูกบุกรุกอย่างสมบูรณ์ ผู้เขียนเอกสารทางเทคนิคกล่าวว่า:

เป็นที่น่าสังเกตว่า WireGuard มีความคิดเห็นเกี่ยวกับการเข้ารหัส มันจงใจขาดความยืดหยุ่นของการเข้ารหัสและโปรโตคอล หากพบช่องโหว่ร้ายแรงในสิ่งดั้งเดิมพื้นฐาน จุดสิ้นสุดทั้งหมดจะต้องได้รับการอัปเดต ดังที่คุณเห็นจากช่องโหว่ SLL/TLS ที่มีอยู่อย่างต่อเนื่อง ความยืดหยุ่นในการเข้ารหัสได้เพิ่มขึ้นอย่างมากในขณะนี้

ประโยคสุดท้ายถูกต้องอย่างยิ่ง

การเข้าถึงฉันทามติว่าจะใช้การเข้ารหัสแบบใดทำให้เกิดโปรโตคอลเช่น IKE และ TLS ขึ้น ซับซ้อน. ซับซ้อนเกินไป? ใช่ ช่องโหว่นั้นพบได้ทั่วไปใน TLS/SSL และไม่มีทางเลือกอื่น

ในการเพิกเฉยต่อปัญหาที่แท้จริง

ลองนึกภาพว่าคุณมีเซิร์ฟเวอร์ VPN ที่มีไคลเอนต์การต่อสู้ 200 แห่งทั่วโลก นี่เป็นกรณีการใช้งานที่ค่อนข้างมาตรฐาน หากคุณต้องเปลี่ยนการเข้ารหัส คุณต้องส่งการอัปเดตไปยังสำเนาทั้งหมดของ WireGuard บนแล็ปท็อป สมาร์ทโฟน และอื่นๆ เหล่านี้ พร้อมกัน ส่งมอบ. มันเป็นไปไม่ได้อย่างแท้จริง ผู้ดูแลระบบที่พยายามทำเช่นนี้จะใช้เวลาหลายเดือนในการปรับใช้การกำหนดค่าที่จำเป็น และบริษัทขนาดกลางจะใช้เวลาหลายปีในการดึงเหตุการณ์ดังกล่าวออกมา

IPsec และ OpenVPN เสนอคุณสมบัติการเจรจารหัส ดังนั้นหลังจากที่คุณเปิดการเข้ารหัสใหม่แล้ว การเข้ารหัสแบบเก่าก็จะใช้งานได้เช่นกัน ซึ่งจะทำให้ลูกค้าปัจจุบันสามารถอัปเกรดเป็นเวอร์ชันใหม่ได้ หลังจากเปิดตัวการอัปเดต คุณเพียงแค่ปิดการเข้ารหัสที่มีช่องโหว่ และนั่นแหล่ะ! พร้อม! คุณเป็นคนสง่างาม! ลูกค้าจะไม่สังเกตเห็นด้วยซ้ำ

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

ทีม WireGuard ทำให้โปรโตคอลของพวกเขาง่ายขึ้น แต่ไม่สามารถใช้งานได้อย่างสมบูรณ์สำหรับผู้ที่ไม่สามารถควบคุมเพียร์ทั้งสองในอุโมงค์ได้อย่างต่อเนื่อง จากประสบการณ์ของฉัน นี่เป็นสถานการณ์ที่พบบ่อยที่สุด

ทำไมคุณไม่ควรใช้ WireGuard

การเข้ารหัส!

แต่การเข้ารหัสใหม่ที่น่าสนใจนี้ที่ WireGuard ใช้คืออะไร?

WireGuard ใช้ Curve25519 สำหรับการแลกเปลี่ยนคีย์, ChaCha20 สำหรับการเข้ารหัส และ Poly1305 สำหรับการตรวจสอบข้อมูล นอกจากนี้ยังทำงานร่วมกับ SipHash สำหรับคีย์แฮชและ BLAKE2 สำหรับการแฮช

ChaCha20-Poly1305 ได้รับมาตรฐานสำหรับ IPsec และ OpenVPN (ผ่าน TLS)

เห็นได้ชัดว่าการพัฒนาของ Daniel Bernstein ถูกนำมาใช้บ่อยมาก BLAKE2 เป็นผู้สืบทอดต่อจาก BLAKE ซึ่งเป็นผู้เข้ารอบสุดท้ายของ SHA-3 ที่ไม่ชนะเนื่องจากความคล้ายคลึงกับ SHA-2 หาก SHA-2 ถูกทำลาย มีโอกาสที่ดีที่ BLAKE จะถูกบุกรุกเช่นกัน

IPsec และ OpenVPN ไม่ต้องการ SipHash เนื่องจากการออกแบบ สิ่งเดียวที่ไม่สามารถใช้กับ BLAKE2 ได้ในขณะนี้ และนั่นเป็นเพียงจนกว่าจะได้มาตรฐานเท่านั้น นี่ไม่ใช่ข้อเสียเปรียบมากนัก เนื่องจาก VPN ใช้ HMAC เพื่อสร้างความสมบูรณ์ ซึ่งถือเป็นโซลูชันที่แข็งแกร่งแม้จะใช้ร่วมกับ MD5

ดังนั้นฉันจึงสรุปได้ว่าเครื่องมือการเข้ารหัสชุดเดียวกันเกือบทั้งหมดใช้ใน VPN ทั้งหมด ดังนั้น WireGuard จึงมีความปลอดภัยไม่มากก็น้อยเมื่อเทียบกับผลิตภัณฑ์อื่นๆ ในปัจจุบัน เมื่อพูดถึงการเข้ารหัสหรือความสมบูรณ์ของข้อมูลที่ส่ง

แต่สิ่งนี้ไม่ใช่สิ่งที่สำคัญที่สุดซึ่งควรค่าแก่การให้ความสนใจตามเอกสารอย่างเป็นทางการของโครงการ ท้ายที่สุดสิ่งสำคัญคือความเร็ว

WireGuard เร็วกว่าโซลูชั่น VPN อื่น ๆ หรือไม่?

กล่าวโดยย่อ: ไม่ ไม่เร็วกว่า

ChaCha20 เป็นรหัสสตรีมที่ง่ายต่อการใช้งานในซอฟต์แวร์ มันเข้ารหัสทีละบิต โปรโตคอลบล็อก เช่น AES เข้ารหัสบล็อกครั้งละ 128 บิต จำเป็นต้องใช้ทรานซิสเตอร์จำนวนมากขึ้นเพื่อใช้การสนับสนุนฮาร์ดแวร์ ดังนั้นโปรเซสเซอร์ขนาดใหญ่จึงมาพร้อมกับ AES-NI ซึ่งเป็นส่วนขยายชุดคำสั่งที่ทำหน้าที่บางอย่างของกระบวนการเข้ารหัสเพื่อเพิ่มความเร็ว

คาดว่า AES-NI จะไม่เข้าสู่สมาร์ทโฟน ต่อ.]. สำหรับสิ่งนี้ ChaCha20 ได้รับการพัฒนาให้เป็นทางเลือกที่ประหยัดแบตเตอรี่และมีน้ำหนักเบา ดังนั้นจึงอาจเป็นข่าวสำหรับคุณว่าสมาร์ทโฟนทุกเครื่องที่คุณสามารถซื้อได้ในปัจจุบันมีการเร่ง AES บางประเภทและทำงานเร็วขึ้นและใช้พลังงานน้อยลงด้วยการเข้ารหัสนี้มากกว่า ChaCha20

เห็นได้ชัดว่าโปรเซสเซอร์เดสก์ท็อป/เซิร์ฟเวอร์ทุกตัวที่ซื้อในช่วงสองสามปีที่ผ่านมามี AES-NI

ดังนั้น ฉันคาดว่า AES จะมีประสิทธิภาพดีกว่า ChaCha20 ในทุกสถานการณ์ เอกสารอย่างเป็นทางการของ WireGuard ระบุว่าด้วย AVX512, ChaCha20-Poly1305 จะมีประสิทธิภาพดีกว่า AES-NI แต่ส่วนขยายชุดคำสั่งนี้จะใช้ได้เฉพาะกับ CPU ที่มีขนาดใหญ่กว่า ซึ่งจะไม่ช่วยอีกต่อไปกับฮาร์ดแวร์พกพาที่เล็กลงและมากขึ้น ซึ่ง AES จะเร็วกว่าเสมอ - เอ็น.ไอ.

ฉันไม่แน่ใจว่าสิ่งนี้สามารถคาดการณ์ล่วงหน้าได้หรือไม่ในระหว่างการพัฒนา WireGuard แต่ในปัจจุบันความจริงที่ว่ามันถูกตอกย้ำด้วยการเข้ารหัสเพียงอย่างเดียวนั้นเป็นข้อเสียเปรียบที่อาจไม่ส่งผลกระทบต่อการทำงานของมันมากนัก

IPsec ช่วยให้คุณสามารถเลือกการเข้ารหัสที่ดีที่สุดสำหรับกรณีของคุณได้อย่างอิสระ และแน่นอนว่านี่เป็นสิ่งจำเป็น ตัวอย่างเช่น คุณต้องการถ่ายโอนข้อมูล 10 กิกะไบต์ขึ้นไปผ่านการเชื่อมต่อ VPN

ปัญหาการผสานรวมใน Linux

แม้ว่า WireGuard จะเลือกโปรโตคอลการเข้ารหัสที่ทันสมัย ​​แต่ก็ทำให้เกิดปัญหามากมาย ดังนั้น แทนที่จะใช้สิ่งที่สนับสนุนโดยเคอร์เนลตั้งแต่แกะกล่อง การรวม WireGuard จึงล่าช้าไปหลายปี เนื่องจากไม่มีเคอร์เนลพื้นฐานเหล่านี้ใน Linux

ฉันไม่แน่ใจว่าสถานการณ์ในระบบปฏิบัติการอื่นเป็นอย่างไร แต่ก็คงไม่ต่างไปจากบน Linux มากนัก

ความเป็นจริงมีลักษณะอย่างไร?

น่าเสียดายที่ทุกครั้งที่ลูกค้าขอให้ฉันตั้งค่าการเชื่อมต่อ VPN ฉันพบปัญหาที่พวกเขาใช้ข้อมูลรับรองและการเข้ารหัสที่ล้าสมัย 3DES ที่ใช้ร่วมกับ MD5 ยังคงเป็นวิธีปฏิบัติทั่วไป เช่นเดียวกับ AES-256 และ SHA1 และแม้ว่าอย่างหลังจะดีกว่าเล็กน้อย แต่นี่ไม่ใช่สิ่งที่ควรใช้ในปี 2020

สำหรับการแลกเปลี่ยนคีย์ เสมอ ใช้ RSA ซึ่งเป็นเครื่องมือที่ช้าแต่ค่อนข้างปลอดภัย

ลูกค้าของฉันมีความเกี่ยวข้องกับหน่วยงานศุลกากรและองค์กรและสถาบันของรัฐอื่นๆ ตลอดจนองค์กรขนาดใหญ่ที่มีชื่อเป็นที่รู้จักไปทั่วโลก พวกเขาทั้งหมดใช้แบบฟอร์มคำขอที่สร้างขึ้นเมื่อหลายสิบปีก่อน และไม่เคยเพิ่มความสามารถในการใช้ SHA-512 เลย ฉันไม่สามารถพูดได้ว่ามันส่งผลกระทบต่อความก้าวหน้าทางเทคโนโลยีอย่างชัดเจน แต่เห็นได้ชัดว่ามันทำให้กระบวนการขององค์กรช้าลง

ฉันเจ็บปวดที่เห็นสิ่งนี้เพราะ IPsec รองรับเส้นโค้งวงรีทันทีตั้งแต่ปี 2005 นอกจากนี้ Curve25519 ยังใหม่กว่าและพร้อมใช้งาน นอกจากนี้ยังมีทางเลือกอื่นสำหรับ AES เช่น Camellia และ ChaCha20 แต่เห็นได้ชัดว่าไม่ใช่ทุกทางเลือกที่ได้รับการสนับสนุนจากผู้จำหน่ายรายใหญ่เช่น Cisco และรายอื่น ๆ

และผู้คนใช้ประโยชน์จากมัน มีชุดคิทของ Cisco หลายชุด มีชุดคิทมากมายที่ออกแบบมาเพื่อทำงานร่วมกับ Cisco พวกเขาเป็นผู้นำตลาดในส่วนนี้และไม่สนใจนวัตกรรมใดๆ มากนัก

ใช่ สถานการณ์ [ในส่วนขององค์กร] แย่มาก แต่เราจะไม่เห็นการเปลี่ยนแปลงใดๆ เนื่องจาก WireGuard ผู้จำหน่ายอาจไม่พบปัญหาด้านประสิทธิภาพใด ๆ กับเครื่องมือและการเข้ารหัสที่พวกเขาใช้อยู่แล้ว และจะไม่พบปัญหาใด ๆ กับ IKEv2 ดังนั้นพวกเขาจึงไม่มองหาทางเลือกอื่น

โดยทั่วไปแล้ว คุณเคยคิดที่จะละทิ้ง Cisco หรือไม่

เกณฑ์มาตรฐาน

ตอนนี้เรามาดูเกณฑ์มาตรฐานจากเอกสาร WireGuard แม้ว่า [เอกสารประกอบ] นี้ไม่ใช่บทความทางวิทยาศาสตร์ แต่ฉันก็ยังคาดหวังให้นักพัฒนาใช้แนวทางทางวิทยาศาสตร์มากขึ้น หรือใช้แนวทางทางวิทยาศาสตร์เป็นข้อมูลอ้างอิง เกณฑ์มาตรฐานใดๆ จะไม่มีประโยชน์หากไม่สามารถทำซ้ำได้ และจะยิ่งไร้ประโยชน์มากขึ้นเมื่อได้รับในห้องปฏิบัติการ

ใน Linux build ของ WireGuard จะใช้ประโยชน์จากการใช้ GSO - Generic Segmentation Offloading ต้องขอบคุณเขา ลูกค้าสร้างแพ็คเก็ตขนาดใหญ่ 64 กิโลไบต์และเข้ารหัส / ถอดรหัสในครั้งเดียว ดังนั้น ค่าใช้จ่ายในการเรียกใช้และการดำเนินการเข้ารหัสจึงลดลง หากคุณต้องการเพิ่มปริมาณงานของการเชื่อมต่อ VPN ให้สูงสุด นี่เป็นความคิดที่ดี

แต่ตามปกติแล้วความเป็นจริงไม่ง่ายนัก การส่งแพ็กเก็ตขนาดใหญ่ไปยังอะแดปเตอร์เครือข่ายจำเป็นต้องตัดเป็นแพ็กเก็ตขนาดเล็กจำนวนมาก ขนาดการส่งปกติคือ 1500 ไบต์ นั่นคือขนาดยักษ์ 64 กิโลไบต์ของเราจะถูกแบ่งออกเป็น 45 แพ็คเก็ต (ข้อมูล 1240 ไบต์และส่วนหัว IP 20 ไบต์) จากนั้นสักครู่พวกเขาจะบล็อกการทำงานของอะแดปเตอร์เครือข่ายโดยสมบูรณ์เนื่องจากต้องส่งพร้อมกันและพร้อมกัน เป็นผลให้สิ่งนี้นำไปสู่การข้ามลำดับความสำคัญและแพ็กเก็ตเช่น VoIP จะถูกเข้าคิว

ดังนั้น ทรูพุตสูงที่ WireGuard กล่าวอ้างอย่างกล้าหาญจึงทำได้โดยเสียค่าใช้จ่ายในการทำให้เครือข่ายของแอปพลิเคชันอื่นๆ ช้าลง และทีมงานไวร์การ์ดอยู่แล้ว ได้รับการยืนยัน นี่คือข้อสรุปของฉัน

แต่ขอเดินหน้าต่อไป

ตามเกณฑ์มาตรฐานในเอกสารทางเทคนิค การเชื่อมต่อแสดงทรูพุตที่ 1011 Mbps

ประทับใจ.

สิ่งนี้น่าประทับใจเป็นพิเศษเนื่องจากข้อเท็จจริงที่ว่าปริมาณงานทางทฤษฎีสูงสุดของการเชื่อมต่อ Gigabit Ethernet เดียวคือ 966 Mbps โดยมีขนาดแพ็กเก็ต 1500 ไบต์ลบ 20 ไบต์สำหรับส่วนหัว IP, 8 ไบต์สำหรับส่วนหัว UDP และ 16 ไบต์สำหรับส่วนหัวของ WireGuard นั่นเอง มีส่วนหัว IP อีกหนึ่งรายการในแพ็กเก็ตที่ห่อหุ้ม และอีกรายการหนึ่งใน TCP ขนาด 20 ไบต์ แล้วแบนด์วิธพิเศษนี้มาจากไหน?

ด้วยเฟรมขนาดใหญ่และประโยชน์ของ GSO ที่เราพูดถึงข้างต้น ค่าสูงสุดตามทฤษฎีสำหรับขนาดเฟรม 9000 ไบต์คือ 1014 Mbps โดยปกติแล้วปริมาณงานดังกล่าวไม่สามารถทำได้ในความเป็นจริงเนื่องจากมีความเกี่ยวข้องกับความยากลำบากอย่างมาก ดังนั้น ฉันสามารถสรุปได้เพียงว่าการทดสอบดำเนินการโดยใช้เฟรมขนาดใหญ่ที่อ้วนขึ้นถึง 64 กิโลไบต์ โดยมีความเร็วสูงสุดตามทฤษฎีที่ 1023 Mbps ซึ่งรองรับโดยอะแดปเตอร์เครือข่ายบางตัวเท่านั้น แต่สิ่งนี้ใช้ไม่ได้อย่างยิ่งในสภาพจริง หรือสามารถใช้ได้ระหว่างสองสถานีที่เชื่อมต่อโดยตรงเท่านั้น เฉพาะภายในแท่นทดสอบเท่านั้น

แต่เนื่องจากอุโมงค์ VPN ถูกส่งต่อระหว่างสองโฮสต์โดยใช้การเชื่อมต่ออินเทอร์เน็ตที่ไม่รองรับจัมโบ้เฟรมเลย ผลลัพธ์ที่ได้บนม้านั่งจึงไม่สามารถนำมาเป็นเกณฑ์มาตรฐานได้ นี่เป็นเพียงความสำเร็จในห้องปฏิบัติการที่ไม่สมจริงซึ่งเป็นไปไม่ได้และไม่สามารถใช้ได้ในสภาพการต่อสู้จริง

แม้จะนั่งอยู่ในศูนย์ข้อมูล ฉันก็ไม่สามารถถ่ายโอนเฟรมที่มีขนาดใหญ่กว่า 9000 ไบต์ได้

เกณฑ์การบังคับใช้ในชีวิตจริงนั้นถูกละเมิดโดยสิ้นเชิงและอย่างที่ฉันคิด ผู้เขียน "การวัดผล" ได้ทำให้ตัวเองเสียชื่อเสียงอย่างจริงจังด้วยเหตุผลที่ชัดเจน

ทำไมคุณไม่ควรใช้ WireGuard

ความหวังริบหรี่สุดท้าย

เว็บไซต์ WireGuard พูดถึงคอนเทนเนอร์มากมายและชัดเจนว่ามีไว้เพื่ออะไร

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

พวกเขาเพิ่มประสิทธิภาพปริมาณงานและแพ็กเก็ตที่มีขนาดใหญ่กว่า 9000 ไบต์ - สิ่งเหล่านี้จะเป็นเฟรมห่อหุ้มขนาดใหญ่สำหรับคอนเทนเนอร์เพื่อสื่อสารระหว่างกัน หรือสำหรับการดำเนินการสำรอง สร้างสแน็ปช็อต หรือปรับใช้คอนเทนเนอร์เดียวกันนี้ แม้แต่ที่อยู่ IP แบบไดนามิกก็จะไม่ส่งผลกระทบต่อการทำงานของ WireGuard แต่อย่างใด ในกรณีของสถานการณ์ที่ฉันอธิบายไว้

เล่นดี. การใช้งานที่ยอดเยี่ยมและโปรโตคอลอ้างอิงที่บางมาก

แต่มันไม่เหมาะกับโลกภายนอกศูนย์ข้อมูลที่คุณควบคุมโดยสิ้นเชิง หากคุณรับความเสี่ยงและเริ่มใช้ WireGuard คุณจะต้องประนีประนอมอย่างต่อเนื่องในการออกแบบและใช้งานโปรโตคอลการเข้ารหัส

เอาท์พุต

เป็นเรื่องง่ายสำหรับฉันที่จะสรุปได้ว่า WireGuard ยังไม่พร้อม

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

เพื่อให้ WireGuard สามารถแข่งขันได้ จำเป็นต้องเพิ่มการตั้งค่าที่อยู่ IP และการกำหนดเส้นทางและ DNS เป็นอย่างน้อย เห็นได้ชัดว่านี่คือสิ่งที่ช่องเข้ารหัสมีไว้สำหรับ

ความปลอดภัยคือสิ่งสำคัญที่สุดของฉัน และตอนนี้ฉันไม่มีเหตุผลที่จะเชื่อได้ว่า IKE หรือ TLS นั้นถูกบุกรุกหรือใช้งานไม่ได้ ทั้งคู่รองรับการเข้ารหัสที่ทันสมัย ​​และได้รับการพิสูจน์จากการดำเนินการหลายทศวรรษ เพียงเพราะมีบางสิ่งที่ใหม่กว่าไม่ได้หมายความว่าจะดีกว่า

ความสามารถในการทำงานร่วมกันมีความสำคัญอย่างยิ่งเมื่อคุณสื่อสารกับบุคคลที่สามซึ่งสถานีที่คุณไม่ได้ควบคุม IPsec เป็นมาตรฐานจริงและได้รับการสนับสนุนเกือบทุกที่ และเขาทำงาน และไม่ว่าจะมีรูปลักษณ์อย่างไร ตามทฤษฎีแล้ว WireGuard ในอนาคตอาจใช้งานร่วมกันไม่ได้แม้ว่าจะเป็นรุ่นต่างๆ กันก็ตาม

การป้องกันการเข้ารหัสใด ๆ จะใช้งานไม่ได้ไม่ช้าก็เร็ว ดังนั้น จะต้องเปลี่ยนหรืออัปเดต

การปฏิเสธข้อเท็จจริงเหล่านี้ทั้งหมดและต้องการใช้ WireGuard เพื่อเชื่อมต่อ iPhone ของคุณกับโฮมเวิร์กสเตชันอย่างสุ่มสี่สุ่มห้านั้นเป็นเพียงระดับปรมาจารย์ในการเอาหัวซุกทราย

ที่มา: will.com

เพิ่มความคิดเห็น