Pi VPN-bediener: begin by die selfoonprogram, nie die resep nie
Die selfoon se program bepaal die protokol, die uitruiling en die profielformaat. Teken die vierledige ooreenkoms aan voordat jy iets op die Pi installeer.
Die meeste Pi VPN-bouprojekte begin met die resep vir die bediener en eindig met 'n selfoon wat nie kan koppel nie. Die volgorde is verkeerd om. 'n Selfoonprogram implementeer 'n spesifieke protokol met 'n spesifieke verifikasie-uitruiling, en die bediener moet by daardie uitruiling pas, nie omgekeerd nie. Om eers die program te kies verander 'n middag se foutsoek in 'n kort kontrolelys.
Die volgorde wat 'n herbou voorkom
Skryf die selfoon se bedryfstelsel en die presiese VPN-program neer voordat jy enigiets op die Pi installeer. Daardie paar bepaal watter protokol hoegenaamd moontlik is. 'n Program word nie 'n ander program omdat 'n profiel toevallig 'n bekende veld bevat nie.
'n Gedeelde geheim in 'n profiel, of 'n poortnommer wat bekend lyk, verander nie een protokol in 'n ander nie. Die uitruiling pas by wat die program implementeer, of dit misluk in 'n stadium wat jou baie min leesstof gee. Daar is geen diagnostiek wat in gewone woorde "verkeerde protokol" sê nie. Jy kry 'n tydverstreke, 'n sertifikaatfout of 'n stil herprobeerslus, wat almal soos 'n bedienerprobleem lyk.
Sodra die program vas is, word die keuse van die bediener smaller en het die res van die bou 'n teiken.
Wat die selfoonprogram werklik implementeer
'n Gepubliseerde programlys beskryf 'n toepassing, nie 'n diens nie. Die OpenVPN Connect-program vir Android verwag 'n OpenVPN-bediener; dit verskaf nie die bedienerkant nie. Dit word ook nie 'n IPsec- of L2TP-program wanneer 'n profiel soortgelyk lyk nie.
Daardie onderskeid maak die meeste saak wanneer jy 'n ouer gids volg. Resepte wat geskryf is vir 'n protokol wat die huidige program laat vaar het, sal steeds netjies op die Pi installeer en steeds op die selfoon misluk, wat soos 'n konfigurasiefout eerder as 'n protokolwanpassing lyk.
Kyk na die program se huidige dokumentasie vir die profielformate wat dit invoer voordat jy jou tot 'n bedienerpakket verbind. Vyf minute se lees klop 'n herbou.
Die vierledige ooreenkoms
Teken vier dinge aan en hou hulle bymekaar: die selfoon se bedryfstelsel en programweergawe, die bedienerimplementering op die Pi, die verifikasie- en vertrouensbeleid, en die eksterne eindpunt. Elkeen van die vier kan die ander drie ongeldig maak.
'n Programopgradering, 'n verandering van bedienerpakket of 'n nuwe sertifikaatowerheid verbreek almal die ooreenkoms, en die mislukking lyk elke keer dieselfde van die selfoon af. Om die vier neergeskryf te hê, is wat jou in staat stel om te sien watter deel verskuif het.
Geloofsbriewe het aparte take
Besluit of die profiel kliëntsertifikate, 'n gebruikersnaam en wagwoord, of 'n ondersteunde kombinasie gebruik, en laat beide kante saamstem. Die bediener se identiteit en die vertroude CA-materiaal moet ook pas by wat die kliënt sal aanvaar.
Die CA se openbare sertifikaat en sy ondertekenende private sleutel is verskillende voorwerpe. Net die openbare deel hoort in 'n selfoonprofiel. Om die ondertekeningsleutel op 'n selfoon te plaas, gee die vermoë weg om identiteite te skep, wat die teenoorgestelde is van waarvoor 'n CA dien. Behandel daardie lêer as die mees sensitiewe voorwerp in die hele bou.
Gebruik die diens se ondersteunde uitvoer- en invoerwerkvloei eerder as om 'n profiel met die hand saam te stel. Handgeboude profiele dra gewoonlik riglyne wat net vir rekenaars bedoel is, wat die selfoonprogram ignoreer of verwerp.
Boonop, moenie sertifikaatvalidering vervang met "aanvaar enige bediener" om 'n ou voorbeeld te laat koppel nie. Dit verander 'n versoenbaarheidsprobleem in 'n verifikasie-omseiling, en dit oorleef gewoonlik tot in produksie omdat dit werk.
Bereikbaarheid is 'n aparte kontrak
Die selfoon moet die bediener se eksterne eindpunt bereik deur die werklike opstroom-reëling. Huisrouter-omsetting, filterering en draer-NAT sit almal tussen die twee. 'n Dinamiese DNS-naam gee net vir die eindpunt 'n stabiele naam; dit skep nie 'n inkomende pad nie.
Definieer dan wat die kliënt kan bereik sodra dit gekoppel is: private prefikse of 'n volledige internetuitgang, hulle aanstuur- en antwoordpaaie, DNS-gedrag, en of IPv6 in die prentjie is. 'n Suksesvolle aanmelding bewys nie een daarvan nie.
Aanvaar die beoogde selfoon en profiel direk, insluitend 'n kontrole dat 'n ongemagtigde bron onbereikbaar bly en dat herroeping werklik toegang verwyder. Sukses met 'n rekenaarkliënt bevestig daardie rekenaarkliënt, nie die selfoon in jou hand nie. Die OpenVPN Connect-lys is 'n konkrete voorbeeld van 'n kliënttoepassing wat 'n passende diens verwag.