Netgear OpenVPN: TUN kaj TAP aŭskultas sur malsamaj pordoj

Telefono konektiĝas al la VPN de la enkursigilo sen plendo, dum tekkomputilo uzanta profilon de la sama elŝuta paĝo tempolimas. Nenio pri atestiloj ŝanĝiĝis inter tiuj du provoj, ĉar la tekkomputilo neniam atingis la punkton, kie atestiloj gravas. La enkursigilo publikigas apartajn aŭskultantojn por TUN kaj TAP, kaj funkcianta profilo devas elekti tiun, kiu apartenas al sia propra aparattipo.

Decidi, kiun el tri eblaj difektoj postkuri, estas la tuta tasko ĉi tie: la pordo, la aparattipo aŭ la ĉifra intertraktado de la datenkanalo.

Tri aferoj, kiuj devas kongrui

La aparattipo, la interfaca linio de la profilo kaj la aŭskulta pordo formas unu elekton, ne tri. Profilo deklaranta dev tun kaj celanta la TAP-aŭskultanton ne povas fini la seancon, kaj la malo malsukcesas same. Por via modelo kaj firmvaro, legu la pordon de la propra VPN-paĝo de la enkursigilo anstataŭ el gvidilo, ĉar la nombroj moviĝas inter versioj. Skribu la modelon kaj firmvaran version apud tiu nombro, por ke la sekva persono povu kontroli ĝin.

Raportoj el la kampo mencias paron kiel 12973 por TUN kaj 12974 por TAP en unu firmvaro, kaj alian nombron en alia. Legu ilin kiel pruvon, ke versioj malsamas, ne kiel konstantojn por kopii. La profilo tiam bezonas la distanc-taŭgan gastigantan nomon: la dinamikan DNS-nomon de la enkursigilo anstataŭ WAN-adreson, kiu ŝanĝiĝos.

Post korekti la pordon kaj la interfacan linion, la profilo aspektas kiel normala klienta agordo kun unu linio remote kaj unu linio dev. Se la du ne kongruas, neniu kvanto da reprovado produktas seancon.

Legu la protokolon en la ordo, en kiu ĝi presiĝas

Kliento de OpenVPN raportas eventojn en la ordo, en kiu ili okazas, do la lasta linio antaŭ silento identigas la tavolon por ekzameni. Kiam la rulo finiĝas ĉe TLS Error: TLS key negotiation failed, aŭ simple atendas unuan respondon kaj rezignas, atestila komparo neniam okazis. Tio montras al atingeblo, al la aŭskultanto aŭ al pordo, malantaŭ kiu estas nenio. Neniu el tiuj ripariĝas per anstataŭigo de la CA-dosiero.

Rulo, kiu atingas VERIFY OK kaj poste malsukcesas, sidas tute aliloke, kun propraj kaŭzoj. Apartigi tiujn du rezultojn antaŭ ol tuŝi dosierojn malhelpas la klasikan ĉirkaŭvojon tra atestilaj pakaĵoj, kiuj neniam estis konsultitaj. Post kiam la manpremo finiĝas sed la tunelo ne leviĝas, rigardu la ĉifran intertraktadon anstataŭ atingeblon.

Aldonu la ĉifran liston, kiun atendas moderna kliento

Lastatempaj OpenVPN-klientoj rifuzas pli malnovajn defaŭltojn, kiujn firmvaro de konsumantaj aparatoj ankoraŭ proponas, kaj la simptomo estas intertraktada malsukceso tuj post sukcesa manpremo. La korekto estas unu profila linio nomanta, kion la kliento akceptos: agordu data-ciphers al AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 kaj AES-128-CBC en tiu ordo. Iu ajn algoritmo, kiun la enkursigilo ne realigas, simple neniam elektiĝas, do pli longa listo kostas nenion krom iom pli longa intertraktado.

Listigi ĉifrojn ne lernigas al la enkursigilo unu, kiun ĝi ne havas. Se la intertraktado ankoraŭ malsukcesas, kontrolu, ĉu la paĝo de la enkursigilo havas propran ĉifran agordon kaj ĉu tiu agordo inkluzivas almenaŭ unu eron, kiun la kliento akceptas. Du listoj sen komuna membro produktas ĝuste la saman malsukceson kiel malĝusta pordo, kaj tial ambaŭ finoj meritas rigardon.

Importu unufoje anstataŭ permane redakti kopiojn

Importi la korektitan dosieron en NetworkManager evitas dosierujon plenan de iomete malsamaj profiloj: nmcli connection import type openvpn file client.ovpn, poste levu ĝin laŭ nomo. Konservu la importitan profilon kiel la solan kopion, kiun vi redaktas, kaj forigu la duplikatojn, kiuj amasiĝas pro ripetaj elŝutoj.

Poste testu de ekster la LAN. Konektiĝi el la sama reto pruvas tre malmulte, ĉar la trafiko eble tute ne trapasas la tunelon. Konfirmu, ke peto vere eliras tra la enkursigilo, ne nur ke la kliento montras konektitan staton.

Decidu, kion fari pri avertoj

Firmvaro de konsumantaj aparatoj kutime stampas sian propran atestilan aŭtoritaton, kaj klientoj plendas pri kontrolado tiel, ke la firmvaro ne povas subpremi. Juĝu, ĉu tiu plendo gravas por tio, kion vi protektas, anstataŭ trakti ĉiun averton kiel fatalan, kaj ne malŝaltu kontroladon tutmonde por silentigi unu mesaĝon. Averto, kiun vi taksis, estas dokumentita risko; kontrola agordo, kiun vi malŝaltis, estas nedokumentita.

Kiam la firmvaro ne provizas subtenatan manieron korekti averton, kiu ja gravas, tiu manko argumentas por gastigi la VPN aliloke. Elekti inter ripari la profilon, akcepti la averton kaj transloki la finpunkton estas decido pri tio, kiom vi fidas tiun atestilon. Faru ĝin konscie, kaj skribu, kiun opcion vi elektis, anstataŭ klaki tra dialogoj ĝis la ikono verdiĝos.