OpenVPN-skript auth-user-pass-verify: de útgongskoad goed krije
De útgongstatus fan ’e hook is de beslissing, net syn logrigel. Map de útkomsten fan ’e ferifiearder nei 0, 1 of útsteld, lês it bewysbestân as gegevens en mislearje sletten.
OpenVPN wurket op krekt ien útgong fan in oanmeldskript: de útgongstatus. Al it oare dat it skript docht is fersiering. In hook kin de juste ferifiearder berikke, it antwurd parse en in freonlike rigel printsje wylst er in status weromjaan dy’t it tsjinstelde betsjut fan wat de auteur bedoelde. Lês earst it kontrakt en skriuw de adapter deromhinne, en dan ferdwynt dy hiele klasse fan flaters.
It kontrakt is lyts: identifisearje it akkount dat ynstjoerd is, freegje de goedkarde ferifiearder de bedoelde fraach en akseptearje allinnich it dokumintearre positive resultaat fan dy ferifiearder foar dat fersyk. Al it oare is ynfrastruktuer.
De trije statussen dy’t de hook weromjaan kin
Foar auth-user-pass-verify, de OpenVPN 2.6-hantlieding definiearret útgongskoad 0 as akseptaasje, 1 as ôfwizing en 2 as útstelde autentikaasje. Dat binne de iennichste trije antwurden dy’t de server begrypt, en elk hat in oare gefolch foar de ferbining. In skript dat einiget mei de status fan syn lêste opdracht hat eins in logoproep of in opromjestap stimme litten. Skriuw de status eksplisyt yn elke tûke, ek yn ’e tûken dy’t de ferifiearder nea berikten.
HTTP-súkses en autentikaasjesúkses binne aparte lagen, en se trochinoar helje is de meast foarkommende manier wêrop dizze hook ferkeard giet. In antwurd fan 202 betsjut dat it fersyk akseptearre is foar ferwurking, net dat in wachtwurd ferifiearre is. Definiearje de ferwachte status, de foarm fan it antwurd en it definitive oardiel út it API-kontrakt dat jo krigen hawwe, en betink gjin fjildnamme om’t er leauwich liket.
As it antwurd echt letter komt, is dat it útstelde paad en it moat as sadanich boud wurde. In útsteld besykjen dat nea foltôge wurdt, hâldt boarnen fêst oant de tiidlimyt ferrint.
Lês it bewysbestân krekt sa’t it skreaun is
By de dokumintearre fia-bestânmetoade skriuwt de server de brûkersnamme en it wachtwurd as de earste twa rigels fan in tydlik bestân, jout dat paad oan it skript en ferwideret it bestân as it skript weromkomt. Lês dy twa rigels as gegevens: doch it bestân nea troch source, evaluearje it nea en plak de ynhâld nea yn in opdrachtregel dêr’t de prosestabel it sjen kin. Bewarje it wachtwurd byte foar byte, want normalisearjen sa’t jo in brûkersnamme normalisearje soene, feroaret it bewys stil. De map foar dat tydlike bestân is in ynsetbeslissing, dus befêstigje dat er bestiet en net foar elkenien op ’e host lêsber is.
Hâld it eigen bewys fan ’e ferifiearder apart fan dat fan ’e brûker: it heart by de gateway-ynset, wennet yn ’e geheimenopslach fan it platfoarm en hat allinnich de tastimming om te ferifiearjen, dus it is gjin bewiis dat in bepaald persoan autentisearre is. Lit de hook ek gjin twadde wachtwurdferifiearder wurde. It mei de hân werbouwen fan in hash-fergeliking wurdt net feilich troch de lus te optimalisearjen, en in ûnderholden ferifiearder begrypt al it sâlte en kostbere skema fan ’e akkountopslach.
Beslis wat in net-klassifisearber antwurd betsjut
Tiidlimititen, transportflaters, misfoarme antwurden en in net-beskikbere backend diele ien eigenskip: gjin fan allegear is in positive ferifikaasje. De hook soe foar elk fan harren sletten mislearje en in reden fêstlizze dêr’t in operator op hannelje kin. Dy reden heart yn in beskerme log, net yn in berjocht dat weromjûn wurdt oan ’e persoan dy’t besiket te ferbinen.
Wês like foarsichtich mei de paden dy’t de ferifiearder hielendal net berikke. In ûntbrekkende konfiguraasjewearde, in net-lêsber geheim of in ôfhinklikheid dy’t net ynstallearre is, soe in ôfwizing mei in apart operaasjemerk jaan moatte ynstee fan in tafallige akseptaasje. Test dy tûken troch de ôfhinklikheid yn in laboratoarium fuort te heljen ynstee fan deroer te redenearjen. Wêr’t in falen fan loggen de útgongstatus feroarje kin, is it loggen diel fan ’e beslissing wurden en moat it ûnskiedlik makke wurde.
Serverkonfiguraasje is hjir ek fan belang: troch de brûker definiearre skripten wurde allinnich respektearre as de rinnende konfiguraasje se op it fereaske feiligensnivo tastiet, en dy ynstelling is in bewuste kar ynstee fan in standertwearde om te ferheegjen.
Ferifiearje it oardiel, net de printe rigel
Bou in test dy’t de útgongstatus direkt ynspektearret. Skriuw in foarbyldbewysbestân, fier it skript der tsjin út mei in bekend-goed en in bekend-slecht akkount, en lês de status dy’t de skyl rapportearret ynstee fan ’e tekst dy’t it skript printet. Dy iene kontrôle fangt de measte kontraktflaters foardat in klant ea ferbynt.
Fier dêrnei deselde gefallen troch in echte klant tsjin in net-produksje-tsjinner en befêstigje wat de server fêstlein hat: akseptearre, ôfwiisd of útsteld. Dek in útskeakele akkount, in ferkeard wachtwurd, in misfoarmd antwurd fan ’e ferifiearder, in tiidlimyt en in net-berikbere ferifiearder. As in gefal yn in steat bedarret dy’t jo net beneame kinne, is de adapter net klear.
Hâld de mapping fan ferifiearderútkomst nei útgongstatus njonken it skript yn ’e repository, sadat de folgjende yngenieur it kontrakt lêze kin sûnder de koade werom te ûntwerpen.