Netgear OpenVPN: TUN en TAP luister op verskillende poorte

'n Foon maak sonder klagte aan die router se VPN verbinding, en 'n skootrekenaar wat 'n profiel van dieselfde aflaai-bladsy gebruik, hou op reageer. Niks omtrent sertifikate het tussen daardie twee pogings verander nie, want die skootrekenaar het nooit die punt bereik waar sertifikate saak maak nie. Die router publiseer afsonderlike luisteraars vir TUN en TAP, en 'n werkende profiel moet die een kies wat by sy eie toesteltipe hoort.

Om te besluit watter van drie kandidaatfoute om na te jaag, is die hele taak hier: die poort, die toesteltipe, of die data-kanaal-syfer-onderhandeling.

Drie dinge wat moet ooreenstem

Die toesteltipe, die profiel se koppelvlaklyn en die luisterpoort vorm een keuse, nie drie nie. 'n Profiel wat dev tun verklaar en op die TAP-luisteraar gemik is, kan nie die sessie voltooi nie, en die omgekeerde misluk identies. Vir jou model en firmware, lees die poort van die router se eie VPN-bladsy eerder as uit 'n gids, want die nommers skuif tussen bouwe. Skryf die model en firmware-weergawe langs daardie nommer sodat die volgende persoon dit kan verifieer.

Verslae uit die veld noem 'n paar soos 12973 vir TUN en 12974 vir TAP op een firmware, en 'n ander nommer op 'n ander. Lees dit as bewys dat bouwe verskil, nie as konstantes om te kopieer nie. Die profiel benodig dan die afstand-toepaslike gasheernaam: die router se dinamiese DNS-naam eerder as 'n WAN-adres wat sal verander.

Nadat die poort en die koppelvlaklyn reggestel is, lyk die profiel soos 'n normale kliëntkonfigurasie met een remote-lyn en een dev-lyn. As die twee nie ooreenstem nie, lewer geen hoeveelheid herprobeer 'n sessie nie.

Lees die log in die orde waarin dit druk

'n OpenVPN-kliënt rapporteer gebeure in die orde waarin hulle gebeur, so die laaste lyn voor stilte identifiseer die laag om te ondersoek. Wanneer die lopie eindig by TLS Error: TLS key negotiation failed, of bloot op 'n eerste antwoord wag en opgee, het sertifikaatvergelijking nooit plaasgevind nie. Dit wys op bereikbaarheid, op die luisteraar, of op 'n poort met niks agter dit nie. Nie een van daardie word herstel deur die CA-lêer te vervang nie.

'n Lopie wat VERIFY OK bereik en dan misluk, sit heeltemal elders, met sy eie oorsake. Om daardie twee uitkomste te sorteer voordat lêers aangeraak word, voorkom die klassieke ompad deur sertifikaatbondels waarmee nooit geraadpleeg is nie. Sodra die handdruk voltooi is maar die tonnel nie opkom nie, kyk na syfer-onderhandeling eerder as bereikbaarheid.

Voeg die syferlys by wat 'n moderne kliënt verwag

Onlangse OpenVPN-kliënte weier ouer verstekwaardes wat verbruikersfirmware nog bied, en die simptoom is 'n onderhandelingsfout onmiddellik ná 'n suksesvolle handdruk. Die regstelling is een profiellyn wat noem wat die kliënt sal aanvaar: stel data-ciphers op AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 en AES-128-CBC in daardie orde. Enige algoritme wat die router nie implementeer nie, word bloot nooit gekies nie, so 'n langer lys kos niks behalwe 'n effens langer onderhandeling.

Om syfers te lys leer die router nie een wat hy nie het nie. As onderhandeling steeds misluk, kyk of die router-bladsy 'n eie syferinstelling het en of daardie instelling ten minste een inskrywing bevat wat die kliënt aanvaar. Twee lyste met geen gemeenskaplike lid lewer presies dieselfde fout as 'n verkeerde poort, wat is waarom beide kante 'n kyk verdien.

Voer een keer in eerder as om kopieë met die hand te redigeer

Om die reggestelde lêer in NetworkManager in te voer, vermy 'n gids vol effens verskillende profiele: nmcli connection import type openvpn file client.ovpn, en bring dit dan by die naam op. Hou die ingevoerde profiel as die enkele kopie wat jy redigeer, en verwyder die duplikate wat uit herhaalde aflaaie opdam.

Toets dan van buite die LAN. Om van dieselfde netwerk te koppel, bewys baie min, want die verkeer mag glad nie deur die tonnel gaan nie. Bevestig dat 'n versoek werklik deur die router vertrek, nie bloot dat die kliënt 'n gekoppelde toestand wys nie.

Besluit wat om omtrent waarskuwings te doen

Verbruikersfirmware munt gewoonlik sy eie sertifikaatowerheid, en kliënte kla oor verifikasie op maniere wat die firmware nie kan onderdruk nie. Beoordeel of daardie klag saak maak vir wat jy beskerm, eerder as om elke waarskuwing as noodlottig te behandel, en moenie verifikasie globaal afskakel om een boodskap stil te maak nie. 'n Waarskuwing wat jy beoordeel het, is 'n gedokumenteerde risiko; 'n verifikasiestelling wat jy gedeaktiveer het, is 'n ongedokumenteerde een.

Wanneer die firmware geen ondersteunde manier bied om 'n waarskuwing reg te stel wat wel saak maak nie, pleit daardie gaping daarvoor om die VPN elders te huisves. Om te kies tussen die profiel herstel, die waarskuwing aanvaar en die eindpunt skuif, is 'n besluit oor hoeveel jy daardie sertifikaat vertrou. Neem dit doelbewus, en skryf neer watter opsie jy gekies het, eerder as om deur dialoogvensters te klik totdat die ikoon groen word.