Netgear OpenVPN: TUN en TAP luisteren op verschillende poorten
Consumentenfirmware kan TUN- en TAP-luisteraars op verschillende poorten publiceren. Een profiel dat op de verkeerde is gericht, loopt ruim voor het onderzoeken van enig certificaat al in een time-out.
Een telefoon maakt zonder klachten verbinding met de VPN van de router, en een laptop met een profiel van dezelfde downloadpagina loopt in een time-out. Aan de certificaten is tussen die twee pogingen niets veranderd, want de laptop bereikte nooit het punt waarop certificaten ertoe doen. De router publiceert aparte luisteraars voor TUN en TAP, en een werkend profiel moet degene kiezen die bij zijn eigen apparaattype hoort.
Bepalen welke van drie mogelijke fouten je moet achtervolgen, is hier het hele werk: de poort, het apparaattype of de cipher-onderhandeling van het datakanaal.
Drie dingen die moeten kloppen
Het apparaattype, de interfaceregel van het profiel en de luisterpoort vormen één keuze, niet drie. Een profiel dat dev tun opgeeft en op de TAP-luisteraar is gericht, kan de sessie niet voltooien, en omgekeerd mislukt het net zo goed. Lees voor jouw model en firmware de poort van de eigen VPN-pagina van de router en niet uit een handleiding, want de nummers verschuiven tussen builds. Schrijf het model en de firmwareversie naast dat nummer, zodat de volgende persoon het kan verifiëren.
Rapporten uit de praktijk noemen een paar zoals 12973 voor TUN en 12974 voor TAP op één firmware, en een ander nummer op een andere. Lees die als bewijs dat builds verschillen, niet als constanten om over te nemen. Het profiel heeft dan de bij de afstand passende hostnaam nodig: de dynamische DNS-naam van de router in plaats van een WAN-adres dat zal veranderen.
Na het corrigeren van de poort en de interfaceregel ziet het profiel eruit als een normale clientconfiguratie met één remote-regel en één dev-regel. Als die twee niet overeenkomen, levert geen enkele hoeveelheid opnieuw proberen een sessie op.
Lees de log in de volgorde waarin hij wordt afgedrukt
Een OpenVPN-client meldt gebeurtenissen in de volgorde waarin ze gebeuren, dus de laatste regel voor de stilte wijst de laag aan die je moet onderzoeken. Wanneer de run eindigt op TLS Error: TLS key negotiation failed, of gewoon op een eerste antwoord wacht en opgeeft, heeft er nooit een certificaatvergelijking plaatsgevonden. Dat wijst op bereikbaarheid, op de luisteraar of op een poort waar niets achter zit. Niets daarvan wordt gerepareerd door het CA-bestand te vervangen.
Een run die VERIFY OK bereikt en daarna faalt, zit ergens anders, met eigen oorzaken. Die twee uitkomsten scheiden voordat je bestanden aanraakt, voorkomt de klassieke omweg via certificaatbundels waaraan nooit iets is gevraagd. Als de handshake klaar is maar de tunnel niet opkomt, kijk dan naar de cipher-onderhandeling in plaats van naar bereikbaarheid.
Voeg de cipherlijst toe die een moderne client verwacht
Recente OpenVPN-clients weigeren oudere standaardwaarden die consumentenfirmware nog biedt, en het symptoom is een onderhandelingsfout direct na een geslaagde handshake. De oplossing is één profielregel die noemt wat de client accepteert: stel data-ciphers in op AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 en AES-128-CBC in die volgorde. Elk algoritme dat de router niet implementeert, wordt simpelweg nooit gekozen, dus een langere lijst kost niets anders dan een iets langere onderhandeling.
Ciphers opnoemen leert de router er geen aan die hij niet heeft. Als de onderhandeling nog steeds mislukt, controleer dan of de routerpagina een eigen cipherinstelling heeft en of die instelling ten minste één invoer bevat die de client accepteert. Twee lijsten zonder gemeenschappelijk lid geven precies dezelfde fout als een verkeerde poort, daarom verdienen beide kanten een blik.
Importeer één keer in plaats van kopieën met de hand te bewerken
Het importeren van het gecorrigeerde bestand in NetworkManager voorkomt een map vol licht verschillende profielen: nmcli connection import type openvpn file client.ovpn, en breng het daarna op naam omhoog. Houd het geïmporteerde profiel als de enige kopie die je bewerkt, en verwijder de duplicaten die zich door herhaalde downloads opstapelen.
Test daarna van buiten het LAN. Verbinden vanaf hetzelfde netwerk bewijst heel weinig, omdat het verkeer de tunnel misschien helemaal niet doorkruist. Bevestig dat een verzoek echt via de router naar buiten gaat, niet alleen dat de client een verbonden status toont.
Beslis wat je met waarschuwingen doet
Consumentenfirmware maakt meestal zijn eigen certificaatautoriteit aan, en clients klagen over verificatie op manieren die de firmware niet kan onderdrukken. Beoordeel of die klacht ertoe doet voor wat je beschermt in plaats van elke waarschuwing als fataal te behandelen, en schakel verificatie niet wereldwijd uit om één bericht stil te maken. Een waarschuwing die je hebt beoordeeld is een gedocumenteerd risico; een verificatie-instelling die je hebt uitgeschakeld is een ongedocumenteerd risico.
Wanneer de firmware geen ondersteunde manier biedt om een waarschuwing te corrigeren die er echt toe doet, pleit dat gat ervoor de VPN elders te hosten. Kiezen tussen het profiel repareren, de waarschuwing accepteren en het eindpunt verplaatsen is een beslissing over hoeveel je dat certificaat vertrouwt. Neem die bewust, en schrijf op welke optie je hebt gekozen, in plaats van door dialoogvensters te klikken tot het pictogram groen wordt.