OpenVPN of IKEv2: vier controles voordat je een protocol kiest

De keuze tussen OpenVPN en IKEv2 wordt meestal als een protocolvraag besproken, en dat kader verkwist de beslissing. Wat de doorslag geeft, is of je server en je apparaten hetzelfde volledige profiel ondersteunen, en of dat profiel de manier waarop je tussen netwerken beweegt overleeft. De twee stacks vertalen zich niet in elkaar: een OVPN-bestand is geen IKEv2-profiel met een andere syntaxis. Vier controles, in volgorde uitgevoerd, beantwoorden de vraag sneller dan welke functietabel dan ook.

Een ontbrekende client beëindigt de discussie

Windows en macOS leveren een IKEv2-client mee, dus een IKEv2-profiel kost daar niets extra om uit te rollen en erft de inrichtingsopties die het besturingssysteem al biedt. OpenVPN op dezelfde machines betekent een client van derden die moet worden geïnstalleerd, bijgewerkt en ondersteund, en die client moet elke optie accepteren die het profiel gebruikt. Tel de platforms die je moet afdekken voordat je iets anders vergelijkt, want een platform zonder werkende client is helemaal geen vergelijkingspunt.

Op Windows somt één opdracht de profielen op die al bestaan en laat zien welk type elk is. De naam die hij afdrukt, is de naam die de latere controles gebruiken.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Een verzoek om een client te installeren is het echte antwoord voor de OpenVPN-kolom op die platforms, en het is een uitroltaak en geen protocolbeperking. Geen van beide regelingen haalt vertrouwenscontroles, identiteitsverificatie of onderhoud weg. Vraag hoe profielen worden verspreid, hoe inloggegevens worden vernieuwd en hoe een verloren apparaat wordt verwijderd voordat je je vastlegt. Een eenvoudige installatie kan nog steeds een herstelprocedure verbergen die niemand in het weekend wil draaien.

Mobiliteit is een gezamenlijke instelling, geen protocolbelofte

IKEv2 kan MOBIKE gebruiken wanneer beide uiteinden het ondersteunen en inschakelen, waardoor een client zijn tunnel kan behouden terwijl zijn adres verandert. RFC 4555 definieert de uitbreiding, en de voorwaardelijke formulering is belangrijk: een server die de mogelijkheid negeert, onderhandelt in plaats daarvan opnieuw. Het resultaat kan identiek lijken voor een bestandsoverdracht en heel anders voor een live gesprek.

Test de overgang die je echt belangrijk vindt, met iets dat draait en dat je kunt volgen. Laat ping -t <internal-host> draaien op Windows, of gewoon ping elders, schakel dan over van Wi-Fi naar mobiel en let op gaten. Een MOBIKE-storing verschijnt als volledige herauthenticatie in het clientlog, niet als een stille adresupdate. Wat je meet is of de tunnel de verandering overleeft, niet of het protocol ondersteuning adverteert.

OpenVPN-clients verbinden opnieuw volgens het gedrag van hun platform en de timers van het profiel, dus dezelfde test kan een andere vorm van onderbreking opleveren. Vergelijk de gebeurtenis die voor je gebruikers belangrijk is, niet het label op het protocol.

Inloggegevens horen bij de dienst, niet bij de stack

Certificaten en andere inlogregelingen horen bij de dienst die de verbinding beëindigt. Een wachtwoordvraag in de ene client zegt niets over compatibiliteit met een andere, en een profiel dat tegen een andere gateway werkt, zegt niets over deze. Houd de regels voor serveridentiteit intact terwijl je de twee stacks vergelijkt. Van protocol wisselen voordat je de storing hebt vastgesteld, levert meestal een tweede incompatibel profiel op.

Inspecteer de inloggegevens die de client gaat presenteren voordat je een van beide protocollen de schuld geeft, want een verlopen of verkeerd uitgegeven certificaat faalt op beide op dezelfde manier. De uitvoer hieronder toont subject, uitgever en geldigheidsdatums zonder de privésleutel te lezen.

openssl x509 -in client.crt -noout -subject -issuer -dates

Gebruik voor een bedrijfsverbinding de methode die het bedrijf publiceert en behandel de vergelijking niet langer als een experiment. Als je de twee zelf vergelijkt, controleer dan eerst of beide opties op dezelfde gateway eindigen, want dat ene detail bepaalt hoeveel van je resultaat over het protocol gaat. Een afwijzing die de inloggegevens noemt, is een probleem met de inloggegevens, en geen enkele protocolwissel repareert dat.

Controleer wat de tunnel werkelijk routeert

Bevestig na het verbinden dat de route die je nodig hebt bestaat en dat namen worden opgelost. Een profiel dat voor interne bronnen bestaat, kan gewoon browsen met opzet op het lokale pad laten, en dat is een beleidsbeslissing en geen fout. Wat telt, is of de bestemmingen die je team gebruikt via de tunnel bereikbaar zijn.

Op Windows dekken twee opdrachten de route en het opzoeken van namen. De Linux-equivalenten zijn ip route show default en resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Een tunnel die opkomt en niets nuttigs routeert, is een veelvoorkomende uitkomst wanneer een profiel tussen diensten is gekopieerd, en een algemene connectiviteitstest laat dat niet zien omdat de interface actief is. Test de bron die je gebruikers als eerste openen, niet een openbaar adres dat elk pad kan bereiken. Als de naam naar een openbaar adres wordt opgelost terwijl de route de tunnel in wijst, horen het DNS-antwoord en de route bij verschillende beslissingen en moeten beide worden gerepareerd.

Weeg het onderhoud na de controles

Geen van beide protocollen is in abstracte zin beter te onderhouden. Onderhoud hangt af van wie de gateway beheert, hoe profielen bij apparaten komen en hoe snel een verloren apparaat de toegang verliest. Een eenvoudige endpoint-client kan voor een moeilijker te beheren server staan, en het omgekeerde gebeurt ook. Vraag welke van de twee je team kan blijven draaien nadat de persoon die het heeft gebouwd vertrekt.

Kies de ondersteunde verbinding die het werk dekt, en test die vervolgens tegen de toegang die je echt nodig hebt, niet tegen een functielijst. Noteer op welke gateway elke optie eindigt, want twee verschillende gateways maken de vergelijking net zo goed een kwestie van routes als van protocollen. Herhaal de vier controles op het apparaat dat je echt zult dragen, en houd het profiel dat daar slaagt.