SSTP sa Linux nabigo bago mag-login? Suriin ang mga bahagi ng runtime

Ikinakabit mo ang plugin na SSTP, lumalabas ang radio button sa editor ng network, pinupunan mo ang gateway at username, at nabigo ang profile na may pangkalahatang error bago pa man ito humingi ng password. Wala sa pagkakasunod-sunod na iyon ang kakaiba, at wala ring nagpapatunay dito na naka-install ang software ng tunnel. Ang koneksyon ng SSTP ay binuo mula sa mga bahaging hiwalay na ipinapadala: isang plugin ng VPN na kayang ilunsad ng NetworkManager, ang programang kliyente ng SSTP na nagmamay-ari ng TLS at PPP session, ang PPP daemon sa ilalim nito, at isang imbakan ng mga sikreto na pinapayagang basahin ng koneksyon.

Ano ang idinadagdag ng menu entry, at ano ang hindi

Nag-aambag ang plugin ng paglalarawan ng serbisyo na nagsasabi sa NetworkManager kung paano ito sisimulan, at sa karamihan ng distribusyon ng isang maliit na editor na gumuguhit ng form. Iyon ang buong saklaw ng menu entry. Ang programang kliyente ay nagmumula sa ibang source package, at ang README mismo ng plugin ay direktang nagsasabi ng paghahati: ito ay plugin, hindi kliyente.

Pagkatapos ay kailangan ng kliyente ang PPP, dahil dinadala ng SSTP ang PPP session sa loob ng koneksyon ng TLS. Kung walang pppd maaaring matapos ng tunnel ang TLS handshake at mamatay pa rin sa unang control frame, na mukhang problema sa kredensyal at hindi naman. Sa Debian at Ubuntu dumarating ang mga bahagi bilang network-manager-sstp, sstp-client at ppp, at ang pag-install lamang ng una ang pinakakaraniwang dahilan kung bakit tinatanggap ng form ang bawat field habang hindi kailanman natatapos ang koneksyon.

Nagdaragdag ng isa pang paghahati ang pagpili ng desktop. Ine-edit ng Plasma ang mga profile sa pamamagitan ng plasma-nm, na nangangailangan ng sarili nitong SSTP component at nagbabasa ng parehong paglalarawan ng serbisyo, kaya ang editor na walang SSTP entry at CLI na mahusay gumawa ng profile ay kulang na kalahati ng editor, hindi sirang runtime.

Basahin ang unang yugtong nabigo bago mag-install muli ng kahit ano

Ang nabigong pagtatangka ng SSTP ay dumadaan sa mga yugto sa takdang pagkakasunod-sunod, at ang yugtong nabigo ay nagsasabi kung aling bahagi ang titingnan.

Ang paglunsad ng plugin ang una, at ang kabiguan doon ay gumagawa ng mensahe tungkol sa serbisyo ng VPN, hindi tungkol sa server. Susunod ang koneksyon ng TCP sa port 443; ang pagtanggi o timeout dito ay problema sa abot, hindi sa TLS. Pagkatapos ang TLS handshake at ang pagsusuri ng pagkakakilanlan ng server, pagkatapos ang PPP negotiation at pagpapatunay ng account, at sa huli ang pagtatalaga ng address at mga ruta. Panoorin ang journalctl -f -u NetworkManager habang isang beses mong i-activate ang profile, at basahin ang unang partikular na linya sa halip na ang huling pangkalahatan.

Ipinapaliwanag ng pagkakasunod-sunod na iyon ang karaniwang maling pagbasa. Ang reklamo sa sertipiko ay iniuulat bago pa magpadala ng anumang kredensyal, kaya hindi makakatulong ang pagpapalit ng password; ang pagtanggi sa pagpapatunay ng PPP ay dumarating pagkatapos ng matagumpay na handshake, kaya hindi rin makakatulong ang pagpapalit ng sertipiko. Itago ang unang error at ang yugto nito, at mayroon kang diagnosis, hindi sintomas.

Ang tiwala sa sertipiko at ang pag-login sa account ay dalawang magkaibang gate

Binabalidate ng handshake na ang server ay ang nilalayon mong maabot, gamit ang issuer at pangalang na-configure mo. Pagkatapos lamang niyon iniaalok ng PPP layer ang iyong username at password sa paraan ng pagpapatunay ng gateway. Dalawang independiyenteng pagsusuri, kung gayon, na sinusuri sa takdang pagkakasunod-sunod, na may hiwalay na mga setting para sa bawat isa. Wala sa anumang itina-type sa field ng password ang makakaapekto sa una.

Ang profile na nagtitiwala sa maling issuer ay nabigo sa unang gate na may error sa pagkakakilanlan. Ang profile na nagtitiwala rito nang tama ngunit nag-iimbak ng lumang password ay nabigo sa pangalawa na may pagtanggi sa pagpapatunay. Pareho silang mukhang VPN na hindi kokonekta, at wala sa kanila ang naaayos ng gamot ng isa.

Kunin ang inaasahang issuer at pangalan ng server mula sa sinumang nagpapatakbo ng gateway sa halip na hulaan ang mga default ng editor, at itala ang paraan ng pagpapatunay na kailangan nila. Kung kailangan ng organisasyon ang isang paraan na hindi maipahayag ng plugin, ang tapat na sagot ay isang aprubadong kliyente na kaya, hindi isang profile na naka-off ang validation para mawala ang error.

Hayaang isang may-ari lang ang humawak ng profile at mga sikreto

Kapag umiiral na ang profile, i-activate ito sa pamamagitan ng NetworkManager at hayaang ang manager na iyon ang magmay-ari ng mga resultang ruta at pagbabago ng resolver. Ang paglunsad ng pangalawang standalone na kliyente ng SSTP habang pinapatakbo na ng NetworkManager ang koneksyon ay nagbibigay sa iyo ng dalawang set ng ruta, dalawang configuration ng DNS at isang sesyon ng debugging na walang iisang pinagmulan ng katotohanan.

May may-ari rin ang mga sikreto. Ang koneksyong minarkahan para sa paggamit sa buong sistema ay nag-iimbak ng kredensyal nang iba kaysa sa isang limitado sa iyong sesyon ng user, at ang profile na ginawa sa pamamagitan ng kamay sa isang key file ay maaaring hindi mabasa ng secret agent na umaasang magbibigay ng password nang interactive. Suriin kung anong konteksto ang inaasahan ng profile bago mo muling i-type ang password na hindi naman kailanman naging problema. Ang pag-activate ng parehong profile mula sa terminal gamit ang nmcli ang pinakamabilis na pagsubok, dahil ang prompt na hindi kailanman lumalabas ay nagsasabi sa iyo na wala nang maiaalok ang agent.

Suriin ang tunnel, mga ruta at resolver nang hiwalay

Ang indicator ng konektado ay nagsasabi lamang na bumangon ang link. Suriin ang destinasyong talagang kailangan mo, ang rutang nagdadala nito at ang resolver na ginagamit, isa-isa; bawat isa ay maaaring mali habang ang dalawa ay maayos.

Para sa nabigong pagtatangka, itala ang bersyon ng bawat bahagi at ang nilinis na teksto ng error. Ibahagi ang mga iyon, hindi ang buong profile, dahil maaaring naglalaman ang profile ng paunang ibinahaging sikreto at ng iyong naka-imbak na kredensyal.

Sa huli, idiskonekta at muling kumonekta, pagkatapos ay mag-reboot nang isang beses. Kung gumagana lamang ang profile sa unang pagtatangka, ang problema ay nasa paghawak ng mga sikreto o sa pagmamay-ari ng mga ruta, at pareho ang mas mura ayusin ngayon kaysa sa kalagitnaan ng araw ng trabaho.