SSTP en Linukso malsukcesas antaŭ ensaluto? Kontrolu la rulkomponantojn

Vi instalas la kromprogramon SSTP, la radiobutono aperas en la retredaktilo, vi enigas enirejon kaj uzantnomon, kaj la profilo malsukcesas per ĝenerala eraro antaŭ ol ĝi eĉ petas pasvorton. Nenio en tiu sinsekvo estas nekutima, kaj nenio en ĝi pruvas, ke la tunela programaro estas instalita. SSTP-konekto estas kunmetata el partoj, kiuj estas liverataj aparte: VPN-kromprogramo, kiun NetworkManager povas lanĉi, la SSTP-klienta programo, kiu posedas la TLS- kaj PPP-sesion, la PPP-demono sub ĝi, kaj sekretujo, kiun la konekto rajtas legi.

Kion la menuero aldonas, kaj kion ne

La kromprogramo kontribuas servopriskribon, kiu diras al NetworkManager kiel lanĉi ĝin, kaj sur la plej multaj distribuaĵoj malgrandan redaktilon, kiu desegnas la formularon. Tio estas la tuta amplekso de la menuero. La klienta programo venas el alia fontpakaĵo, kaj la propra README de la kromprogramo diras la dividon rekte: ĝi estas kromprogramo, ne kliento.

La kliento poste bezonas PPP, ĉar SSTP portas PPP-sesion ene de TLS-konekto. Sen pppd la tunelo povas fini sian TLS-manpremon kaj tamen morti ĉe la unua kontrola kadro, kio aspektas kiel problemo pri akreditiloj kaj ne estas. Sur Debian kaj Ubuntu la partoj venas kiel network-manager-sstp, sstp-client kaj ppp, kaj instali nur la unuan estas la plej ofta kialo, ke formularo akceptas ĉiun kampon dum la konekto neniam finiĝas.

La labortabla elekto aldonas unu plian dividon. Plasma redaktas profilojn per plasma-nm, kiu bezonas sian propran SSTP-komponenton kaj legas la saman servopriskribon, do redaktilo sen SSTP-ero kaj CLI, kiu bone kreas profilojn, estas mankanta duono de redaktilo, ne rompita rulmedio.

Legu la unuan malsukcesan stadion antaŭ ol reinstali ion ajn

Malsukcesa SSTP-provo trapasas stadiojn en fiksa ordo, kaj la stadio, kiu malsukcesis, diras al vi, kiun komponenton rigardi.

Lanĉi la kromprogramon estas la unua, kaj malsukceso tie produktas mesaĝon pri la VPN-servo anstataŭ pri la servilo. Poste venas TCP-konekto al pordo 443; rifuzo aŭ tempolimo ĉi tie estas problemo pri atingeblo, ne pri TLS. Poste la TLS-manpremo kaj la kontrolo de servila identeco, poste PPP-intertraktado kaj konta aŭtentikigo, kaj fine adresatribuo kaj itineroj. Observu journalctl -f -u NetworkManager dum vi unufoje aktivigas la profilon, kaj legu la unuan specifan linion anstataŭ la lastan ĝeneralan.

Tiu ordo klarigas oftan mislegadon. Plendo pri atestilo raportiĝas antaŭ ol ajna akreditilo estas sendita, do ŝanĝi la pasvorton ne povas helpi; rifuzo de PPP-aŭtentikigo alvenas post sukcesa manpremo, do anstataŭigi la atestilon ankaŭ ne povas helpi. Konservu la unuan eraron kaj ĝian stadion, kaj vi havas diagnozon anstataŭ simptomon.

Fido al la atestilo kaj saluto al la konto estas apartaj pordegoj

La manpremo validigas, ke la servilo estas tiu, kiun vi intencis atingi, uzante la eldonanton kaj nomon, kiujn vi agordis. Nur post tio la PPP-tavolo proponas vian uzantnomon kaj pasvorton al la aŭtentikiga metodo de la enirejo. Do du sendependaj kontroloj, taksataj en fiksa ordo, kun apartaj agordoj por ĉiu. Nenio tajpita en la pasvortan kampon povas influi la unuan.

Profilo, kiu fidas la malĝustan eldonanton, malsukcesas ĉe la unua pordego per identeca eraro. Profilo, kiu fidas ĝin ĝuste sed konservas eksvalidiĝintan pasvorton, malsukcesas ĉe la dua per rifuzo de aŭtentikigo. Ambaŭ aspektas kiel VPN, kiu ne konektiĝos, kaj neniu el ili ripariĝas per la rimedo de la alia.

Akiru la atendatan eldonanton kaj servilan nomon de tiu, kiu administras la enirejon, anstataŭ diveni la agordajn defaŭltojn de la redaktilo, kaj notu la aŭtentikigan metodon, kiun ili postulas. Se la organizo bezonas metodon, kiun la kromprogramo ne povas esprimi, la honesta respondo estas aprobita kliento, kiu povas, ne profilo kun malŝaltita validigo por malaperigi la eraron.

Lasu unu posedanton teni la profilon kaj la sekretojn

Post kiam la profilo ekzistas, aktivigu ĝin per NetworkManager kaj lasu tiun administrilon posedi la rezultajn itinerojn kaj ŝanĝojn de solvilo. Lanĉi duan sendependan SSTP-klienton dum NetworkManager jam gvidas la konekton donas al vi du itinarojn, du DNS-agordojn kaj sencimigan sesion sen unu sola fonto de vero.

Sekretoj ankaŭ havas posedanton. Konekto markita por tutsistema uzo konservas akreditilojn malsame ol unu limigita al via uzanta sesio, kaj profilo kreita permane en ŝlosilodosiero eble ne estas legebla de la sekreta agento, kiu atendas liveri la pasvorton interage. Kontrolu, kiun kuntekston la profilo atendas, antaŭ ol vi retajpi pasvorton, kiu neniam estis la problemo. Aktivigi la saman profilon el terminalo per nmcli estas la plej rapida testo, ĉar instigilo, kiu neniam aperas, diras al vi, ke la agento jam havis nenion proponi.

Kontrolu la tunelon, la itinerojn kaj la solvilon aparte

Indikilo «konektita» nur asertas, ke la ligo leviĝis. Kontrolu la cellokon, kiun vi efektive bezonas, la itineron, kiu portas ĝin, kaj la uzatan solvilon, unu post la alia; ĉiu povas esti malĝusta dum la aliaj du estas bonaj.

Por malsukcesa provo, registru la version de ĉiu komponento kaj la purigitan erartekston. Kunhavigu tiujn, ne la plenan profilon, ĉar la profilo povas enhavi la antaŭe kunhavigitan sekreton kaj viajn konservitajn akreditilojn.

Fine, malkonektu kaj rekonektu, poste restartigu unufoje. Se la profilo funkcias nur ĉe la unua provo, la problemo kuŝas en la traktado de sekretoj aŭ en la posedo de itineroj, kaj ambaŭ estas pli malmultekostaj ripari nun ol meze de labora tago.