Netgear OpenVPN: TUN og TAP lytter på forskjellige porter

En telefon kobler til ruterens VPN uten klager, og en bærbar PC som bruker en profil fra samme nedlastingsside, utløper. Ingenting ved sertifikatene endret seg mellom de to forsøkene, fordi den bærbare aldri nådde punktet der sertifikater betyr noe. Ruteren publiserer separate lyttere for TUN og TAP, og en fungerende profil må velge den som hører til dens egen enhetstype.

Å avgjøre hvilken av tre mulige feil som skal forfølges, er hele jobben her: porten, enhetstypen eller forhandlingen av datakanalens chiffer.

Tre ting som må stemme

Enhetstypen, profilens grensesnittlinje og lytterporten utgjør ett valg, ikke tre. En profil som erklærer dev tun og er rettet mot TAP-lytteren, kan ikke fullføre økten, og det motsatte feiler på samme måte. For din modell og fastvare, les porten fra ruterens egen VPN-side i stedet for fra en veiledning, fordi tallene flytter seg mellom bygg. Skriv modell og fastvareversjon ved siden av tallet slik at neste person kan verifisere det.

Rapporter fra feltet nevner et par som 12973 for TUN og 12974 for TAP på én fastvare, og et annet tall på en annen. Les dem som bevis på at byggene er forskjellige, ikke som konstanter som skal kopieres. Profilen trenger da vertsnavnet som passer avstanden: ruterens dynamiske DNS-navn i stedet for en WAN-adresse som vil endre seg.

Etter å ha rettet porten og grensesnittlinjen ser profilen ut som en vanlig klientkonfigurasjon med én remote-linje og én dev-linje. Hvis de to ikke stemmer, gir ingen mengde gjentakelse en økt.

Les loggen i den rekkefølgen den skrives ut

En OpenVPN-klient rapporterer hendelser i den rekkefølgen de skjer, så den siste linjen før stillheten angir laget som skal undersøkes. Når kjøringen slutter på TLS Error: TLS key negotiation failed, eller bare venter på et første svar og gir opp, skjedde sertifikatsammenligningen aldri. Det peker på nåbarhet, på lytteren eller på en port uten noe bak. Ingenting av dette repareres ved å bytte ut CA-filen.

En kjøring som når VERIFY OK og deretter feiler, ligger helt andre steder med sine egne årsaker. Å sortere de to utfallene før du rører filer forhindrer den klassiske omveien gjennom sertifikatbunter som aldri ble spurt. Når håndtrykket er fullført men tunnelen ikke kommer opp, se på chifferforhandlingen i stedet for nåbarhet.

Legg til chifferlisten en moderne klient forventer

Nyere OpenVPN-klienter avviser eldre standardverdier som forbrukerfastvare fortsatt tilbyr, og symptomet er en forhandlingsfeil rett etter et vellykket håndtrykk. Rettelsen er én profillinje som navngir hva klienten vil godta: sett data-ciphers til AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 og AES-128-CBC i den rekkefølgen. Enhver algoritme ruteren ikke implementerer, blir rett og slett aldri valgt, så en lengre liste koster ingenting annet enn en litt lengre forhandling.

Å liste opp chiffere lærer ikke ruteren en den ikke har. Hvis forhandlingen fortsatt feiler, sjekk om ruternes side har sin egen chifferinnstilling og om den innstillingen inneholder minst én oppføring klienten godtar. To lister uten felles medlem gir nøyaktig samme feil som en feil port, derfor fortjener begge ender et blikk.

Importer én gang i stedet for å redigere kopier for hånd

Import av den rettede filen i NetworkManager unngår en mappe full av litt forskjellige profiler: nmcli connection import type openvpn file client.ovpn, og ta den deretter opp ved navn. Behold den importerte profilen som den eneste kopien du redigerer, og slett duplikatene som samler seg fra gjentatte nedlastinger.

Test deretter utenfra LAN. Å koble til fra samme nettverk beviser svært lite, fordi trafikken kanskje ikke går gjennom tunnelen i det hele tatt. Bekreft at en forespørsel faktisk forlater gjennom ruteren, ikke bare at klienten viser en tilkoblet tilstand.

Bestem hva du vil gjøre med advarsler

Forbrukerfastvare preger vanligvis sin egen sertifikatmyndighet, og klienter klager på verifiseringen på måter fastvaren ikke kan undertrykke. Vurder om den klagen betyr noe for det du beskytter, i stedet for å behandle hver advarsel som fatal, og ikke slå av verifiseringen globalt for å tie én melding. En advarsel du har vurdert, er en dokumentert risiko; en verifiseringsinnstilling du har deaktivert, er en udokumentert.

Når fastvaren ikke tilbyr noen støttet måte å rette en advarsel som virkelig betyr noe, taler det gapet for å hoste VPN-et et annet sted. Valget mellom å reparere profilen, godta advarselen og flytte endepunktet er en beslutning om hvor mye du stoler på det sertifikatet. Ta den bevisst, og skriv ned hvilket alternativ du valgte, i stedet for å klikke gjennom dialoger til ikonet blir grønt.