WireGuard har fået meget opmærksomhed på det seneste, og er faktisk den nye "stjerne" af VPN'er. Men er det så godt, som det ser ud? Jeg vil gerne diskutere nogle observationer og se på implementeringen af WireGuard for at forklare, hvorfor det ikke er en løsning at erstatte IPsec eller OpenVPN.
I denne artikel vil jeg gerne aflive nogle myter [omkring WireGuard]. Ja, det er lang læsning, så hvis du endnu ikke har lavet en kop te eller kaffe til dig selv, er det nu du skal gøre det. Jeg vil også gerne takke Peter for korrekturlæsning af mine kaotiske tanker.
Det er ikke min hensigt at miskreditere WireGuard-udviklerne eller at devaluere deres indsats eller ideer. Deres produkt virker, men jeg synes personligt, at det præsenteres som noget helt andet, end det egentlig er – præsenteret som en erstatning for IPsec og OpenVPN, som faktisk simpelthen ikke eksisterer nu.
Som en sidebemærkning vil jeg gerne tilføje, at ansvaret for denne positionering af WireGuard ligger hos de medier, der rapporterede om det, og ikke hos projektet selv eller dets skabere.
Der har ikke været mange gode nyheder om Linux-kernen på det seneste. Så vi fik at vide om processorens monstrøse sårbarheder, som blev udjævnet af software, og Linus Torvalds talte om det for groft og kedeligt på en udviklers utilitaristiske sprog. Planlæggeren eller netværksstakken på nulniveau er heller ikke særlig klare emner for glossy magasiner. Og her kommer WireGuard.
På papiret lyder det hele fantastisk: en fængslende ny teknologi.
Men lad os se lidt nærmere på det.
WireGuard teknisk dokumentation
Denne artikel er baseret på , skrevet af Jason Donenfeld. Der forklarer han konceptet, formålet og den tekniske implementering af [WireGuard] i Linux-kernen.
Den første sætning lyder:
WireGuard […] sigter mod at erstatte både IPsec i de fleste tilfælde, såvel som andre populære brugerrum og/eller TLS-baserede løsninger såsom OpenVPN, samtidig med at de er mere sikre, mere effektive og nemmere at bruge [værktøj].
Selvfølgelig er den største fordel ved alle nye teknologier deres lethed [sammenlignet med forgængere]. Men det burde VPN også være effektivt og sikkert.
Så hvad er det næste?
Hvis du siger, at det ikke er det, du har brug for [fra en VPN], så kan du stoppe med at læse her. Jeg vil dog bemærke, at sådanne opgaver er sat til enhver anden tunnelteknologi.
Det mest interessante i ovenstående citat er ordene "i de fleste tilfælde", som selvfølgelig blev ignoreret af pressen. Og her er vi, hvor vi endte på grund af kaoset skabt af denne skødesløshed - i denne artikel.
Vil WireGuard erstatte min [IPsec] site-to-site VPN?
Nej. Der er simpelthen ingen chance for, at store leverandører som Cisco, Juniper og andre vil købe WireGuard til deres produkter. De "hopper ikke på forbipasserende tog" på farten, medmindre der er et stort behov for det. Senere vil jeg fortælle om nogle af grundene til, at de sandsynligvis ikke ville være i stand til at sætte WireGuard ombord på deres produkter, selvom de ville.
Vil WireGuard flytte min RoadWarrior fra min bærbare computer til datacentret?
Nej. Lige nu har WireGuard ikke et væld af vigtig funktionalitet implementeret for at kunne gøre sådan noget. For eksempel kan den ikke bruge dynamiske IP-adresser på tunnelserversiden, og dette alene bryder hele scenariet for sådan brug af produktet.
IPFire bruges ofte til billige internetforbindelser såsom DSL- eller kabelforbindelser. Dette giver mening for små eller mellemstore virksomheder, der ikke har brug for hurtig fiber. [Oversætterens note: Det er værd at huske på, at med hensyn til kommunikation er Rusland og nogle SNG-lande langt foran Europa og USA, fordi vi begyndte at bygge vores netværk meget senere, og med fremkomsten af Ethernet og fiberoptiske netværk som standard, var det nemmere for os at tilpasse os. I de samme EU-lande eller USA er xDSL-bredbåndsadgang med en hastighed på 3-5 Mbit/s stadig den generelle norm, og fiberoptisk forbindelse koster efter vores standard nogle urealistiske penge. Det er derfor, forfatteren af artiklen taler om DSL eller kabelforbindelse som normen og ikke som en gammel ting.] DSL, kabel, LTE (og andre trådløse adgangsmetoder) har dog dynamiske IP-adresser. Selvfølgelig ændrer de sig nogle gange ikke ofte, men de ændrer sig.
Der er et delprojekt, der hedder , som tilføjer en bruger-rum-dæmon for at overvinde denne mangel. Et stort problem med brugerscenariet beskrevet ovenfor er, at det forværres af dynamisk IPv6-adressering.
Fra distributørens synspunkt ser alt dette heller ikke særlig godt ud. Et af designmålene var at holde protokollen enkel og ren.
Desværre er alt dette faktisk blevet for simpelt og primitivt, så vi er nødt til at bruge ekstra software for at gøre hele dette design levedygtigt under virkelige forhold.
Er WireGuard så nem at bruge?
Ikke endnu. Jeg siger ikke, at WireGuard aldrig vil være et godt alternativ til tunneling mellem to punkter, men indtil videre er det bare en alfaversion af, hvad det skal være.
Men hvad gør han så egentlig? Er IPsec virkelig så meget sværere at betjene?
Åbenbart ikke. IPsec-leverandøren har tænkt over dette og sender deres produkt med en grænseflade, såsom IPFire.
For at konfigurere en VPN-tunnel over IPsec skal du bruge fem stykker information for at komme ind i konfigurationen: din egen offentlige IP-adresse, den offentlige IP-adresse på den modtagende ende, de undernet, du vil gøre offentligt tilgængelige via denne VPN-forbindelse, og en foruddelt nøgle. Således konfigureres VPN'en på få minutter og er kompatibel med enhver leverandør.
Desværre er der nogle få undtagelser fra denne historie. Enhver, der har forsøgt at tunnelere en VPN over IPsec til en OpenBSD-maskine, ved, hvad jeg taler om. Der er et par mere smertefulde eksempler, men faktisk er der mange, mange flere positive fremgangsmåder ved at bruge IPsec.
Om kompleksiteten af protokollen
Slutbrugeren skal ikke bekymre sig om kompleksiteten af protokollen.
Hvis vi levede i en verden, hvor dette var en reel bekymring for brugeren, ville vi for længst være sluppet af med SIP, H.323, FTP og andre protokoller skabt for mere end ti år siden, som ikke fungerer godt med NAT.
Der er grunde til, at IPsec er mere kompleks end WireGuard: det gør mange flere ting. For eksempel brugergodkendelse ved hjælp af login/adgangskode eller SIM-kort med EAP. Det har en udvidet mulighed for at tilføje nye .
Men dette har WireGuard ikke.
Og det betyder, at WireGuard vil gå i stykker på et tidspunkt, fordi en af de kryptografiske primitiver bliver svag eller fuldstændig kompromitteret. Forfatteren til den tekniske dokumentation siger det på denne måde:
Det er værd at bemærke, at WireGuard er kryptografisk sikker. Det mangler bevidst fleksibiliteten af ciphers og protokoller. Hvis der findes alvorlige huller i de underliggende primitiver, skal alle endepunkter opdateres. Som det kan ses af den igangværende strøm af SLL/TLS-sårbarheder, er krypteringsfleksibiliteten nu steget enormt.
Den sidste sætning er helt korrekt.
At opnå konsensus om, hvilken kryptering der skal bruges, gør protokoller som IKE og TLS mere kompleks. For kompliceret? Ja, TLS/SSL-sårbarheder er ret almindelige, og der er intet alternativ til dem.
Om at ignorere reelle problemer
Forestil dig, at du har en VPN-server med 200 live-klienter et eller andet sted rundt om i verden. Dette er en ret standard use case. Hvis du skal ændre krypteringen, skal du skubbe opdateringen til alle kopier af WireGuard på de bærbare computere, smartphones osv. Samtidigt levere. Det er bogstaveligt talt umuligt. Administratorer, der forsøger at gøre dette, vil have brug for måneder til at implementere de nødvendige konfigurationer, og gennemsnitlige virksomheder vil bogstaveligt talt have brug for år for at udføre en sådan forpligtelse.
IPsec og OpenVPN tilbyder en chifferforhandlingsfunktion. Derfor vil den gamle også virke i nogen tid, hvorefter du aktiverer ny kryptering. Dette vil give nuværende kunder mulighed for at opgradere til den nye version. Når opdateringen er rullet ud, deaktiverer du blot den sårbare kryptering. Og det er det! Parat! du er fantastisk! Og kunderne vil ikke engang bemærke det.
Dette er faktisk en meget almindelig brugssag til store implementeringer, og selv OpenVPN har nogle problemer med dette. Bagudkompatibilitet er vigtig, og selvom du måske bruger svagere kryptering, er det for mange ikke en grund til at lukke en virksomhed. Fordi det vil resultere i, at hundredvis af klienter bliver lammet på grund af deres manglende evne til at udføre deres arbejde.
WireGuard-teamet gjorde deres protokol enklere, men fuldstændig ubrugelig for folk, der ikke har konstant kontrol over begge peers i deres tunnel. Efter min erfaring er dette det mest almindelige scenarie.
Kryptografi!
Men hvad er denne interessante nye kryptering, som WireGuard bruger?
WireGuard bruger Curve25519 til nøgleudveksling, ChaCha20 til kryptering og Poly1305 til datagodkendelse. Det fungerer også med SipHash til hash-nøgler og BLAKE2 til hash.
ChaCha20-Poly1305 er standardiseret til IPsec og OpenVPN (over TLS).
Det er åbenlyst, at Daniel Bernsteins udvikling bliver brugt meget ofte. BLAKE2 er efterfølgeren til BLAKE, en SHA-3 finalist, der ikke vandt på grund af sin lighed med SHA-2. Hvis SHA-2 var brudt, var der en god chance for, at BLAKE også ville blive kompromitteret.
IPsec og OpenVPN har ikke brug for SipHash på grund af deres design. Så det eneste der ikke kan bruges med dem i øjeblikket er BLAKE2, og det er kun indtil det er standardiseret. Dette er ikke en stor ulempe, fordi VPN'er bruger HMAC til at skabe integritet, hvilket betragtes som en stærk løsning, selv når det er parret med MD5.
Så jeg kom til den konklusion, at alle VPN'er bruger næsten det samme sæt kryptografiske værktøjer. Derfor er WireGuard hverken mere eller mindre sikker end noget andet nuværende produkt, når det kommer til kryptering eller integritet af transmitterede data.
Men dette er ikke engang den vigtigste ting at være opmærksom på ifølge den officielle dokumentation for projektet. Det vigtigste er trods alt hastighed.
Er WireGuard hurtigere end andre VPN-løsninger?
Kort sagt: nej, ikke hurtigere.
ChaCha20 er en stream cipher, der er lettere at implementere i software. Den krypterer en bit ad gangen. Blokprotokoller såsom AES krypterer en blok på 128 bit ad gangen. Implementering af hardwaresupport ville kræve mange flere transistorer, så større processorer kommer med AES-NI, en instruktionssætudvidelse, der udfører nogle af krypteringsprocessens opgaver for at fremskynde den.
Det var forventet, at AES-NI aldrig ville gøre det til smartphones [men det gjorde det, - red. [oversættelse]. Derfor er ChaCha20 udviklet som et let, batterivenligt og økonomisk alternativ. Så det kan komme som en nyhed for dig, at hver smartphone, du kan købe i dag, har en form for acceleration til AES og kører den hurtigere og med mindre strøm end ChaCha20.
Tilsyneladende har næsten alle desktop/server-CPU'er købt i de sidste par år AES-NI.
Derfor forventer jeg, at AES klarer sig bedre end ChaCha20 i hvert enkelt scenarie. Den officielle WireGuard-dokumentation nævner, at AVX512 vil få ChaCha20-Poly1305 til at overgå AES-NI, men den instruktionssætudvidelse vil kun være tilgængelig på større processorer, hvilket igen ikke hjælper med mindre, mobil hardware, der altid vil være hurtigere med AES-NI.
Jeg er ikke sikker på, om dette kunne have været forudset, da WireGuard blev designet, men i dag er det faktum, at det er naglet til kryptering alene, allerede en fejl, som måske ikke har en særlig god effekt på dens ydeevne.
IPsec giver dig mulighed for frit at vælge, hvilken kryptering der er bedst egnet til din use case. Og det er selvfølgelig nødvendigt, hvis du for eksempel vil overføre 10 eller flere gigabyte data via en VPN-forbindelse.
Problemer med integration i Linux
Selvom WireGuard har valgt en moderne krypteringsprotokol, giver den allerede mange problemer. Så i stedet for at bruge det, kernen understøtter ud af boksen, blev WireGuard-integration forsinket i årevis på grund af manglen på disse primitiver i Linux.
Jeg er ikke helt sikker på, hvordan situationen er på andre styresystemer, men det er nok ikke meget anderledes end Linux.
Hvordan ser virkeligheden ud?
Desværre, hver gang en klient beder mig om at oprette en VPN-forbindelse til dem, bliver jeg konfronteret med det faktum, at de bruger forældede legitimationsoplysninger og kryptering. 3DES kombineret med MD5 er stadig almindelig praksis, ligesom AES-256 og SHA1. Og selvom sidstnævnte er lidt bedre, er det ikke noget, du skal bruge i 2020.
Til nøgleudveksling altid RSA bruges - et langsomt, men ret sikkert værktøj.
Mine kunder er forbundet med toldmyndigheder og andre statslige organisationer og institutioner, samt med store virksomheder, hvis navne er kendt over hele verden. De bruger alle en form for forespørgsel, der blev oprettet for årtier siden, og muligheden for at bruge SHA-512 blev simpelthen aldrig tilføjet. Jeg kan ikke sige, at dette har nogen indlysende indflydelse på teknologiske fremskridt, men det bremser naturligvis virksomhedens processer.
Det gør mig ondt at se dette, fordi IPsec har understøttet elliptiske kurver siden omkring 2005, nogenlunde. Curve25519 er også nyere og tilgængelig til brug. Der er også alternativer til AES som Camellia og ChaCha20, men tilsyneladende er ikke alle af dem understøttet af større leverandører som Cisco og andre.
Og folk udnytter dette. Der er mange Cisco-sæt, der er mange sæt designet til at fungere med Cisco. De er markedsledere i dette segment og er ikke særlig interesserede i innovation.
Ja, situationen [i virksomhedssegmentet] er forfærdelig, men vi vil ikke se nogen ændringer på grund af WireGuard. Leverandører vil sandsynligvis aldrig opdage nogen problemer med ydeevnen med de værktøjer og kryptering, de allerede bruger, og de vil heller ikke se nogen problemer med IKEv2 - og derfor leder de ikke efter alternativer.
Generelt, har du nogensinde tænkt på at droppe Cisco?
Benchmarks
Lad os nu gå videre til benchmarks fra WireGuard-dokumentationen. Selvom denne [dokumentation] ikke er en videnskabelig artikel, forventede jeg stadig, at udviklerne ville tage en mere videnskabelig tilgang eller bruge en videnskabelig tilgang som benchmark. Ethvert benchmark er ubrugeligt, hvis det ikke kan reproduceres, og det er endnu mere ubrugeligt, hvis det opnås i laboratoriemiljø.
I Linux-builden af WireGuard udnytter den GSO - Generic Segmentation Offloading. Takket være det opretter klienten en enorm pakke på 64 kilobyte og krypterer/dekrypterer den på én gang. Således reduceres omkostningerne ved at ringe og implementere kryptografiske operationer. Hvis du vil maksimere båndbredden af din VPN-forbindelse, er dette en god idé.
Men som sædvanligt er i virkeligheden ikke alt så enkelt. At sende så stor en pakke til en netværksadapter kræver, at den skæres i mange mindre pakker. Den typiske beskedstørrelse er 1500 bytes. Det vil sige, at vores gigant på 64 kilobyte bliver opdelt i 45 pakker (1240 bytes information og 20 bytes IP-header). Så vil de i et stykke tid fuldstændig blokere netværksadapteren fra at virke, fordi de skal sendes sammen og på én gang. Dette vil i sidste ende resultere i en prioritetsstigning, og pakker som VoIP vil blive sat i en ventekø.
Således opnås den høje gennemstrømning, som WireGuard så modigt hævder, på bekostning af at bremse netværkets ydeevne for andre applikationer. Og WireGuard-holdet allerede Dette er min konklusion.
Men lad os komme videre.
Ifølge benchmarks i den tekniske dokumentation viser forbindelsen en gennemstrømning på 1011 Mbps.
Imponerende.
Dette er især imponerende, fordi den maksimale teoretiske gennemstrømning af en enkelt gigabit Ethernet-forbindelse er 966 Mbps med en pakkestørrelse på 1500 bytes minus 20 bytes til IP-headeren, 8 bytes til UDP-headeren og 16 bytes til selve WireGuard-headeren. Der er en anden IP-header i den indkapslede pakke og en anden i TCP til 20 bytes. Så hvor kom denne ekstra båndbredde fra?
Med enorme rammer og de GSO-fordele, vi talte om ovenfor, ville det teoretiske maksimum ved en 9000 byte-rammestørrelse være 1014 Mbps. Normalt er en sådan gennemstrømning ikke opnåelig i virkeligheden, fordi den er forbundet med store vanskeligheder. Så jeg kan kun gå ud fra, at testen blev udført med endnu federe frames, der overstiger 64kB-størrelsen med et teoretisk maksimum på 1023Mbps, hvilket kun understøttes af nogle netværksadaptere. Men dette er absolut ikke anvendeligt under virkelige forhold, eller kan kun bruges mellem to direkte forbundne stationer, udelukkende inden for rammerne af en testbænk.
Men da VPN-tunnelen dirigeres mellem to værter ved hjælp af en internetforbindelse, der slet ikke understøtter store frames, kan det opnåede resultat på standeren ikke tages som standard. Dette er simpelthen en urealistisk laboratoriepræstation, der er umulig og uanvendelig under virkelige kampforhold.
Selv når jeg sidder i et datacenter, ville jeg ikke være i stand til at overføre rammer større end 9000 bytes.
Kriteriet for anvendelighed i det virkelige liv er fuldstændig overtrådt, og som jeg tror, miskrediterede forfatteren af den udførte "måling" sig selv af indlysende grunde.
Det sidste glimt af håb
WireGuard-hjemmesiden taler meget om containere, og det bliver tydeligt, hvad det egentlig er beregnet til.
En enkel og hurtig VPN, der ikke kræver nogen konfiguration og kan implementeres og konfigureres af massive orkestreringsværktøjer, som Amazon har i deres sky. Specifikt bruger Amazon de nyeste hardwarefunktioner, som jeg nævnte tidligere, såsom AVX512. Dette gøres for at fremskynde arbejdet og ikke være bundet til x86 eller nogen anden arkitektur.
De optimerer til gennemløb og pakker større end 9000 bytes - disse vil være enorme indkapslede rammer til kommunikation mellem containere eller til backup-operationer, oprettelse af snapshots eller implementering af de samme containere. Selv dynamiske IP-adresser vil ikke påvirke WireGuards drift i det scenarie, jeg beskrev.
Ikke dårligt spillet. Strålende implementering og en meget subtil, næsten referenceprotokol.
Men det er bare ikke egnet til verden uden for et datacenter, som du helt kontrollerer. Hvis du tager risikoen og begynder at bruge WireGuard, bliver du nødt til konstant at gå på kompromis med udformningen og implementeringen af krypteringsprotokollen.
Output
Det er nemt for mig at konkludere, at WireGuard ikke er klar endnu.
Det var tænkt som en let og hurtig løsning på en række problemer med eksisterende løsninger. Desværre, for disse beslutninger ofrede han mange funktioner, der ville være relevante for de fleste brugere. Det er derfor, det ikke kan erstatte IPsec eller OpenVPN.
For at WireGuard skal være konkurrencedygtig, skal den som minimum tilføje IP-adressekonfiguration og routing og DNS-konfiguration. Det er klart, hvad krypterede kanaler er til.
Sikkerhed er min topprioritet, og på nuværende tidspunkt har jeg ingen grund til at tro, at IKE eller TLS på en eller anden måde er kompromitteret eller ødelagt. Moderne kryptering er understøttet i dem begge, og de er blevet testet gennem årtiers brug. Bare fordi noget er nyere, betyder det ikke, at det er bedre.
Interoperabilitet er ekstremt vigtigt, når du kommunikerer med tredjeparter, hvis stationer du ikke kontrollerer. IPsec er en de facto standard og understøttes næsten overalt. Og det virker. Og uanset hvordan det ser ud, kan WireGuard i teorien i fremtiden være inkompatibel selv med forskellige versioner af sig selv.
Enhver kryptografisk beskyttelse bliver før eller siden hacket og skal derfor udskiftes eller opdateres.
At benægte alle disse fakta og blindt vælge at bruge WireGuard til at forbinde din iPhone til din hjemmearbejdsstation er simpelthen en mesterklasse i at stikke hovedet i sandet.
Kilde: www.habr.com
