Pi VPN-servilo: komencu per la telefono-aplikaĵo, ne per la recepto

Plej multaj Pi VPN-konstruoj komenciĝas per la servila recepto kaj finiĝas per telefono, kiu ne povas konektiĝi. La ordo estas inversa. Telefona kliento realigas specifan protokolon kun specifa aŭtentiga interŝanĝo, kaj la servilo devas kongrui kun tiu interŝanĝo, ne male. Se vi unue decidas la aplikaĵon, posttagmezo da sencimigado fariĝas mallonga kontrol-listo.

La ordo, kiu ŝparas la rekonstruon

Notu la operaciumon de la telefono kaj la precizan VPN-aplikaĵon antaŭ ol instali ion ajn sur la Pi. Tiu paro difinas, kiu protokolo entute eblas. Klienta aplikaĵo ne fariĝas alia kliento nur ĉar profilo hazarde enhavas konatan kampon.

Komuna sekreto en profilo aŭ konata ŝajna pordnumero ne igas unu protokolon alia. La interŝanĝo aŭ kongruas kun tio, kion la aplikaĵo realigas, aŭ fiaskas en etapo, kiu donas al vi tre malmulte por legi. Ne ekzistas diagnozo, kiu per simplaj vortoj diras "malĝusta protokolo". Vi ricevas tempolimon, atestilan eraron aŭ silentan ripetan buklon, kaj ĉio tio aspektas kiel servila problemo.

Post kiam la aplikaĵo estas fiksita, la elekto de servilo mallarĝiĝas kaj la resto de la konstruo havas celon.

Kion la telefona aplikaĵo efektive realigas

Publikigita klientlisto priskribas aplikaĵon, ne servon. La aplikaĵo OpenVPN Connect por Android atendas OpenVPN-servilon; ĝi ne provizas la servilan flankon. Ĝi ankaŭ ne fariĝas kliento de IPsec aŭ L2TP, kiam profilo aspektas simila.

Tiu distingo plej gravas, kiam vi sekvas pli malnovan gvidadon. Receptoj verkitaj por protokolo, kiun la nuna aplikaĵo forlasis, ankoraŭ instaliĝos pure sur la Pi kaj ankoraŭ fiaskos sur la telefono, kio legiĝas kiel agorda eraro anstataŭ protokola malkongruo.

Kontrolu la nunan dokumentaron de la aplikaĵo pri la profilaj formatoj, kiujn ĝi importas, antaŭ ol ligi vin al servila pako. Kvin minutoj da legado pli valoras ol rekonstruo.

La kvarparta interkonsento

Notu kvar aferojn kaj tenu ilin kune: la operaciumon kaj aplikaĵan version de la telefono, la servilan realigon sur la Pi, la aŭtentigan kaj fidan politikon, kaj la eksteran finpunkton. Ĉiu el la kvar povas nuligi la aliajn tri.

Aplikaĵa ĝisdatigo, ŝanĝo de servila pako aŭ nova atestila aŭtoritato rompas la interkonsenton, kaj la fiasko aspektas idente de la telefono ĉiufoje. Ĝuste la notitaj kvar ebligas al vi identigi, kiu parto moviĝis.

Akreditiloj havas apartajn taskojn

Decidu, ĉu la profilo uzas klientajn atestilojn, uzantnomon kaj pasvorton aŭ subtenatan kombinaĵon, kaj interkonsentigu ambaŭ finojn. La identeco de la servilo kaj la materialo de la fidata CA ankaŭ devas kongrui kun tio, kion la kliento akceptos.

La publika atestilo de la CA kaj ĝia privata subskriba ŝlosilo estas malsamaj objektoj. Nur la publika parto apartenas al telefona profilo. Se vi metas la subskriban ŝlosilon sur telefonon, vi donacas la kapablon krei identecojn, kio estas la malo de tio, por kio CA ekzistas. Traktu tiun dosieron kiel la plej senteman objekton en la tuta konstruo.

Uzu la subtenatan elportan kaj enportan fluon de la servo anstataŭ kunmeti profilon permane. Permane konstruitaj profiloj kutime portas direktivojn nur por surtabla komputilo, kiujn la poŝtelefona aplikaĵo ignoras aŭ malakceptas.

Super ĉio, ne anstataŭigu atestilan validigon per "akcepti ajnan servilon" por ke malnova ekzemplo konektiĝu. Tio ŝanĝas kongruecan problemon en preterpason de aŭtentigo, kaj ĝi kutime pluvivas en produktadon ĉar ĝi funkcias.

Atingebleco estas aparta kontrakto

La telefono devas atingi la eksteran finpunkton de la servilo tra la reala suprenflua aranĝo. La traduko de la hejma enkursigilo, filtrado kaj NAT de la operatoro ĉiuj kuŝas inter ili. Dinamika DNS-nomo donas al la finpunkto nur stabilan nomon; ĝi ne kreas envenan vojon.

Poste difinu, kion la kliento rajtas atingi post konekto: privatajn prefiksojn aŭ plenan interretan eliron, iliajn plusendajn kaj respondajn vojojn, DNS-konduton, kaj ĉu IPv6 estas en la amplekso. Sukcesa ensaluto pruvas neniun el tiuj.

Akceptu la celatan telefonon kaj profilon rekte, inkluzive kontrolon, ke neaŭtorizita rimedo restas neatingebla kaj ke revoko vere forigas aliron. Sukceso kun surtabla kliento validigas tiun surtablan klienton, ne la telefonon en via mano. La listo de OpenVPN Connect estas konkreta ekzemplo de klienta aplikaĵo, kiu atendas konforman servon.