Jy het 'n wg0.conf en 'n kliënt wat net .ovpn aanvaar, so iemand stel voor om die lêer om te skakel. As jy dit hernoem, kry jy 'n profiel wat OpenVPN nie kan ontleed nie, en 'n noukeurige veld-vir-veld-vertaling lewer een wat ontleed en dan by die handskud misluk. Die rede is nie die lêerformaat nie. WireGuard en OpenVPN is verskillende protokolle met verskillende handskudde, verskillende stawingsmodelle en verskillende idees oor wat 'n peer is. Omskakeling werk net in die sin dat jy 'n OpenVPN-profiel by wie die ander kant bedryf kan gaan kry.

Die lêer wat jy het, beskryf 'n peer, nie 'n verbindingsprofiel nie

'n WireGuard-konfigurasie is kort omdat die protokol so is: 'n koppelvlak met 'n privaat sleutel en adresse, dan een of meer peers met 'n publieke sleutel, 'n eindpunt en 'n AllowedIPs-lys. Daar is geen onderhandelingslaag om te konfigureer en geen syfersuite om te kies nie.

'n OpenVPN-profiel is 'n kliënt vir 'n TLS-gebaseerde beheerkanaal, daarom dra dit verwysings na sertifikate of geloofsbriewe en direktiewe wat beskryf hoe om te verifieer.

Waarom 'n vertaalde lêer steeds die handskud misluk

WireGuard begin met 'n Noise-gebaseerde handskud wat met statiese peer-sleutels gesleutel word, en dit bly stil tensy die peer se publieke sleutel reeds bekend is. OpenVPN open 'n TLS-sessie, verifieer 'n bediener-sertifikaat of 'n statiese sleutel, en staaf dan die gebruiker met sertifikate, 'n gebruikersnaam en wagwoord, of albei. Niks in 'n WireGuard-lêer beskryf enigiets daarvan nie. 'n Vertaalde lêer sou die regte eindpunt dra en alles anders verkeerd.

Om dieselfde adres en poort te hergebruik help ook nie, want die ander kant luister vir 'n ander pakket.

Wat om by die verskaffer te vra

As 'n verskaffer die WireGuard-lêer verskaf het, vra of dieselfde rekening OpenVPN-toegang het en versoek daardie profiel. Baie het, en dit kom met sy eie geloofsbriewe eerder as as 'n gewysigde kopie van die eerste een.

As die antwoord nee is, is die beperking die intekening eerder as die lêer, en geen omskakelaar verander dit nie.

As die router of kliënt net OpenVPN praat

Wanneer die toestel wat moet koppel net OpenVPN ondersteun, kyk na die ander kant se gedokumenteerde protokolondersteuning voordat jy na 'n ander uitbreiding soek. 'n Router wat OpenVPN termineer kan nie oorreed word om WireGuard te aanvaar deur 'n lêer in te voer nie. Die werkbare opsies is 'n OpenVPN-eindpunt aan die bedienerkant, of 'n ander toestel wat WireGuard praat.

Kies op grond van wie die ander kant administreer, nie op grond van watter lêer jy toevallig het nie.

As jy die bediener bedryf, voeg die protokol by

Om 'n tweede protokol te ondersteun beteken om 'n tweede diens te bedryf. Op 'n Linux-bediener is dit 'n OpenVPN-instansie met sy eie CA, bediener-sertifikaat, kliëntsertifikate en server plus push-direktiewe, saam met 'n vuurmuur-reël vir sy poort. Die bestaande WireGuard-peer-inskrywing beskryf geen van daardie objekte nie. Beplan die adrespoel en die gestuurde roetes apart van die WireGuard AllowedIPs, want dit is nie dieselfde meganisme met twee name nie.

Verifieer dan vanaf die kliënt: die profiel laai, die TLS-sessie voltooi, die gestuurde roete verskyn, en verkeer bereik 'n gasheer wat net deur die tonnel bereikbaar is.

Waar die omskakelaar-idee veilig is

Om waardes met die hand in notas te vertaal is goed en dikwels nuttig, want die eindpunt, die adresse en die peer se publieke sleutel is net feite oor die ontplooiing. Om 'n privaat sleutel na 'n webwerf op te laai wat omskakeling belowe, is nie goed nie, want daardie sleutel is die geloofsbrief en die diens het geen protokol om dit na om te skakel nie. As jy dieselfde toegang vanaf 'n OpenVPN-kliënt nodig het, vra eerder 'n OpenVPN-geloofsbrief.

Hou die twee konfigurasies langs mekaar en behandel hulle as aparte toegangspaaie, want dit is wat hulle is.

Verwante artikels