Netgear OpenVPN: TUN og TAP lytter på forskellige porte

En telefon opretter forbindelse til routerens VPN uden klager, og en bærbar computer, der bruger en profil fra samme downloadside, udløber. Intet ved certifikaterne ændrede sig mellem de to forsøg, fordi den bærbare aldrig nåede det punkt, hvor certifikater betyder noget. Routeren offentliggør separate lyttere til TUN og TAP, og en fungerende profil skal vælge den, der hører til dens egen enhedstype.

At afgøre, hvilken af tre mulige fejl der skal forfølges, er hele opgaven her: porten, enhedstypen eller forhandlingen af datakanalens cipher.

Tre ting, der skal stemme overens

Enhedstypen, profilens interface-linje og lytterporten udgør ét valg, ikke tre. En profil, der erklærer dev tun og sigter på TAP-lytteren, kan ikke fuldføre sessionen, og det omvendte fejler identisk. For din model og firmware skal du læse porten fra routerens egen VPN-side i stedet for fra en guide, fordi tallene flytter sig mellem builds. Skriv model og firmwareversion ved siden af det tal, så den næste person kan verificere det.

Rapporter fra felten nævner et par som 12973 til TUN og 12974 til TAP på én firmware og et andet tal på en anden. Læs dem som bevis på, at builds er forskellige, ikke som konstanter, der skal kopieres. Profilen har derefter brug for det afstandspassende værtsnavn: routerens dynamiske DNS-navn i stedet for en WAN-adresse, der vil ændre sig.

Efter at have rettet porten og interface-linjen ser profilen ud som en normal klientkonfiguration med én remote-linje og én dev-linje. Hvis de to ikke stemmer overens, giver ingen mængde gentagelse en session.

Læs loggen i den rækkefølge, den udskrives

En OpenVPN-klient rapporterer hændelser i den rækkefølge, de sker, så den sidste linje før stilhed angiver det lag, der skal undersøges. Når kørslen slutter på TLS Error: TLS key negotiation failed, eller blot venter på et første svar og giver op, skete certifikatsammenligningen aldrig. Det peger på nåbarhed, på lytteren eller på en port uden noget bag sig. Ingen af dem repareres ved at udskifte CA-filen.

En kørsel, der når VERIFY OK og derefter fejler, ligger helt andre steder med sine egne årsager. At sortere de to udfald før du rører filer forhindrer den klassiske omvej gennem certifikatbundter, der aldrig blev spurgt. Når håndtrykket er fuldført, men tunnelen ikke kommer op, skal du se på cipher-forhandlingen i stedet for nåbarhed.

Tilføj den cipher-liste, en moderne klient forventer

Nyere OpenVPN-klienter afviser ældre standarder, som forbrugerfirmware stadig tilbyder, og symptomet er en forhandlingsfejl lige efter et vellykket håndtryk. Rettelsen er én profillinje, der navngiver, hvad klienten vil acceptere: sæt data-ciphers til AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 og AES-128-CBC i den rækkefølge. Enhver algoritme, routeren ikke implementerer, bliver simpelthen aldrig valgt, så en længere liste koster intet ud over en lidt længere forhandling.

At liste ciphers lærer ikke routeren en, den ikke har. Hvis forhandlingen stadig fejler, skal du kontrollere, om routerens side har sin egen cipher-indstilling, og om den indstilling indeholder mindst én post, som klienten accepterer. To lister uden fælles medlem giver præcis samme fejl som en forkert port, og derfor fortjener begge ender et kig.

Importér én gang i stedet for at redigere kopier i hånden

Import af den rettede fil i NetworkManager undgår en mappe fuld af lidt forskellige profiler: nmcli connection import type openvpn file client.ovpn, og bring den derefter op ved navn. Behold den importerede profil som den eneste kopi, du redigerer, og slet de dubletter, der hober sig op fra gentagne downloads.

Test derefter udefra LAN. At forbinde fra samme netværk beviser meget lidt, fordi trafikken måske slet ikke går gennem tunnelen. Bekræft, at en anmodning faktisk forlader via routeren, ikke blot at klienten viser en forbundet tilstand.

Beslut, hvad du vil gøre ved advarsler

Forbrugerfirmware præger normalt sin egen certifikatmyndighed, og klienter klager over verifikation på måder, som firmwaren ikke kan undertrykke. Vurder, om den klage betyder noget for det, du beskytter, i stedet for at behandle hver advarsel som fatal, og slå ikke verifikation fra globalt for at tie én besked. En advarsel, du har vurderet, er en dokumenteret risiko; en verifikationsindstilling, du har deaktiveret, er en udokumenteret.

Når firmwaren ikke tilbyder nogen understøttet måde at rette en advarsel, der virkelig betyder noget, taler det hul for at hoste VPN'et et andet sted. At vælge mellem at reparere profilen, acceptere advarslen og flytte endepunktet er en beslutning om, hvor meget du stoler på det certifikat. Træf den bevidst, og skriv ned, hvilken mulighed du valgte, i stedet for at klikke gennem dialoger, indtil ikonet bliver grønt.