Servile ŝlosita profilo malsukcesas malantaŭ TLS-prokuraĵo: kiu generacio?

Unu uzanto povas konektiĝi kaj alia ne, tra la sama portalo, en la sama tago. Ambaŭ havas servile ŝlositajn profilojn, ambaŭ estas en la sama Access Server-konstruo, kaj la sola diferenco estas, kiam ilia profilo estis generita. Tio estas la ŝablono inda je rekono, ĉar "servile ŝlosita" nomas politikon, ne konektosekvencon. Access Server liveris du generaciojn de tiu artefakto, kaj TLS-inversa prokuraĵo staras antaŭ nur unu el iliaj vojoj. Tri kondiĉoj decidas, en kiu branĉo vi estas.

Du generacioj, du konektosekvencoj

En la pli malnova dezajno, valida ĝis 2.8, la importita dosiero estas pseŭdoprofilo. OpenVPN Connect uzas ĝin por aŭtentigi sin kontraŭ la reta API de Access Server per HTTPS, ricevas provizoran uzant-ŝlositan profilon kaj seanctokenon, kaj nur poste starigas la VPN. Du transportoj funkcias sinsekve, kaj la unua estas ordinara reta peto.

La formato enkondukita kun 2.9 ne faras tiun preparon po konekto. Ĝi estas denaska profilo uzebla de kongruaj OpenVPN klientoj, ne nur de OpenVPN Connect. Elŝuti aŭ importi ĝin per URL ankoraŭ povas impliki HTTPS — tio estas publikiga paŝo, ne akiro de provizora profilo po konekto.

Ĝisdatigo ne nepre reskribas profilojn jam eldonitajn, do aktuala servila versio ankoraŭ povas disdoni la malnovan artefakton. La servila konstruo diras al vi, kio eblas, ne kion ĉi uzanto importis.

Tri kondiĉoj, kiuj elektas vian branĉon

La unua kondiĉo estas la generacio de la artefakto. Petu la dosieron, rigardu kiel ĝi estis produktita, kaj notu la klientan version, kiu importis ĝin. Se vi ne povas determini la generacion el la dosiero, freŝa profilo eldonita por testa konto diros al vi, kion la servilo produktas hodiaŭ, kio estas malsama informo ol tiu, kiun havas la malsukcesanta uzanto.

La dua estas, kion via antaŭaĵo efektive finas. HTTP-inversa prokuraĵo de la sepa tavolo, kiu malpezigas TLS, ne estas la sama objekto kiel TCP-plusendilo de la kvara tavolo, kaj UDP-plusendilo ankaŭ ne. La kutima aranĝo de Access Server sur pordo 443 igas la demonon OpenVPN TCP rekoni retumilan trafikon kaj transdoni ĝin al la retaj servoj, do enmeti nerilatan HTTPS-finilon antaŭe ne konservas la protokolan traktadon de tiu demono. Kunhavigi la numeron 443 ne faras du dezajnojn ekvivalentaj.

La tria estas, kie la malsukceso surteriĝas. Malsukceso antaŭ VPN kaj malsukceso de la stirkanalo aspektas similaj en kliento, kiu nur diras "konektante", sed ili lasas spurojn en malsamaj lokoj. Se la malnova formato ludas, la preparo estas kandidato. Se la nova formato ludas, malplena reta alirprotokolo estas atendata kaj pruvas nenion en iu ajn direkto.

Kiam la artefakto estas malnova: la preparo malsukcesas unue

Legu la faktan eraron de la kliento anstataŭ ĝian finan staton. La interesaj kampoj estas la HTTPS-eraro, la servila identeco, kiun la kliento atendis, la celo, kien iris la peto, kaj ĉu la atestila validigo finiĝis. Poste komparu ilin kun la protokoloj de la reta servo kaj de la prokuraĵo ĉe la servila flanko.

Tio, ke retumilo atingas la ensalutan paĝon, ne estas pruvo, ke la API-aŭtentigo de ĉi kliento sukcesis. Ili estas malsamaj petoj, kun malsamaj atestilaj atendoj kaj ofte malsamaj gastigantnomoj. Se la portalo estas servata ĝuste kaj la kliento ankoraŭ malsukcesas, la malkonsento estas en la prepara vojo, ne en la pasvorto de la uzanto.

Ne sukcesigu la komparon per malŝalto de TLS-validigo aŭ malstreĉigo de la aŭtentiga politiko. Tio ŝanĝas diagnozeblan agordan malkongruon en vojon, kiu funkcias sed ne estas validigita, kaj ĝuste tiu ŝanĝo turnas provizoran teston en permanentan truon. La dokumentaro de Access Server pri konektaj profiloj priskribas ambaŭ generaciojn kaj la fluon de la provizora profilo, kaj ĝi estas la referenco kontrolenda antaŭ ol supozi, ke prokuraĵo kulpas.

Kiam la artefakto estas nova: legu la stirkanalon

Kun profilo laŭ stilo 2.9, la kliento iras rekte al la denaska VPN-finpunkto. Esploru la finpunktojn en la profilo, la uzatan transporton, kaj la eraron de la stirkanalo. Se la kliento neniam elsendas HTTP-peton, tio kongruas kun la dezajno kaj ne estas simptomo.

Ĉi tie ankaŭ la demando pri la prokuraĵo ŝanĝas formon. HTTPS-malpezigado ne povas rompi TCP-nuran fluon, kiun ĝi neniam vidas, sed ĝi ankoraŭ povas rompi la elŝuton, kiu publikigas la profilon, kaj TCP-nura plusendilo tute ne portos UDP. Kontrolu, kiun transporton la profilo postulas, antaŭ ol konkludi, ke la antaŭaĵo estas nerelevanta.

TLS-trapaso por unu fluo estas mallarĝa aranĝo. Ĝi ne disponigas UDP-plusendadon, kaj ĝi ne reproduktas la propran servoplusendan konduton de la demono sur 443. Se via antaŭaĵo faras unu el tiuj aferoj, diru kiun, ĉar la rimedo malsamas.

Rimedoj, kiuj restas mallarĝaj

La malplej ĝena kontrolo estas generi freŝan subtenatan profilon por testa konto kaj konektiĝi tra la celata denaska finpunkto kun la samaj aŭtentigaj postuloj. Se tio funkcias kaj la konservita malnova profilo ne, vi apartigis la artefakton de la servilo kaj de la prokuraĵo en unu paŝo.

La disdonado de uzant-ŝlosita profilo tute forigas la heredaĵan preparan dependecon, ĉar ne ekzistas interŝanĝo de provizora profilo, kiu povus malsukcesi. Ĝi devas esti eldonita por la celata uzanto, neniam kopiita de administranto, kaj ĝi ŝanĝas, kion la kliento rajtas fari, do traktu ĝin kiel politikan decidon, ne kiel provizoran solvon.

Poste riparu la publikigan aranĝon tiel, ke ekzistu ĉiu bezonata vojo: la reta vojo por elŝutoj kaj portalouzo, kaj la denaska VPN-vojo sur la transporto, kiun la profiloj atendas. Tenu la laboron de la prokuraĵo en unu tavolo. Funkcianta uzant-ŝlosita tunelo pruvas, ke tiu vojo funkcias; ĝi ne pruvas, ke ĉiu prokuraĵa aranĝo subtenas ĉiun generacion, kaj malnova prepara malsukceso ne kondamnas la pli novan formaton.

• Determinu la generacion de la artefakto antaŭ ol tuŝi la prokuraĵon.
• Determinu, ĉu la malsukceso okazas antaŭ la tunelo aŭ ene de ĝi.
• Konfirmu, kion la antaŭaĵo finas: HTTP, TCP-fluo, aŭ UDP.
• Testu freŝe eldonitan profilon kontraŭ la denaska finpunkto kun neŝanĝita politiko.