Een OpenVPN-kliënt pouseer: waarom herroeping die verkeerde hefboom is
Om die sessie te dood is omkeerbaar; om die sertifikaat te herroep is nie. Besluit watter hefboom die geval nodig het, en bou die CRL eers weer op wanneer dit pas.
Om een kliënt se toegang te pouseer en om dit permanent te verwyder lyk soos dieselfde taak totdat jy een van die twee probeer ongedaan maak. Om 'n sertifikaat te herroep skryf 'n rekord wat die bediener as finaal beskou, en om dit terug te draai beteken om die uitreiker se databasis met die hand te wysig. Om die lewende tonnel te laat val is 'n bestuursopdrag wat niks aan vertroue verander nie. Kies die hefboom deur te vra of die sleutel nog betroubaar is, nie deur te vra hoe dringend die versoek voel nie.
Die oortuiging: herroep en opgeskort is dieselfde ding
'n Kontrakteur word vir 'n week gepouseer en die refleks is om te herroep, want herroeping klink soos om iets af te skakel. Dit lyk netjies, dit neem tien sekondes, en dit laat 'n databasiswysiging as die enigste weg terug. Die refleks is verstaanbaar en dit is nader aan om 'n paspoort te verbrand as om 'n deur toe te maak. 'n Gepouseerde toestel en 'n gekompromitteerde sleutel het verskillende behandeling nodig, en net een van hulle is goedkoop om terug te draai.
Die onderskeid gaan oor die geloofsbrief eerder as oor die persoon. 'n Sleutel wat nog in die regte hande is, kan gepouseer en hervat word sonder enige verlies aan vertroue. 'n Sleutel wat moontlik gekopieer is, moet nooit herstel word nie, want herstel beweer dat die kopie nie bestaan nie.
Skryf die antwoord neer voordat jy aan enige van die twee stelsels raak. As jy nie kan sê of die sleutel blootgestel is nie, is die versigtige antwoord vervanging.
Laat vaar die lewende sessie met die bestuurskoppelvlak
OpenVPN bied 'n bestuurskoppelvlak wat sessies kan lys en een daarvan op algemene naam kan doodmaak. Aktiveer dit op localhost, hou dit weg van die openbare koppelvlak, en stuur die doodmaakopdrag wanneer 'n sessie nou moet verdwyn. Die opdrag sluit net daardie tonnel, en elke ander kliënt hou aan werk.
Dit is 'n reaksie op 'n aktiewe probleem, nie 'n skorsingsbeleid nie. Dieselfde profiel kan binne 'n minuut weer koppel, want niks aan sy geloofsbrief het verander nie. Gebruik dit wanneer die sessie moet weg en die blywende besluit nog geneem word.
Bevestig dat die sessie aangeheg was voordat jy dit doodmaak, sodat jy nie 'n kliënt jag wat nooit gekoppel het nie. Die statusopdrag hier onder wys wat tans aangeheg is.
printf 'status 2\nquit\n' | nc 127.0.0.1 7506
printf 'kill kiosk-14\nquit\n' | nc 127.0.0.1 7506As die doodmaak geen sodanige kliënt rapporteer nie, is die algemene naam in die sertifikaat nie die string wat jy getik het nie. Lees die statusuitvoer eerder as die profiellêernaam.
Wat die CRL werklik beheer
Die bediener raadpleeg nie 'n herroepingsvlag wat op die sertifikaat gestoor is nie. Dit lees die sertifikaatherroepingslys wat deur crl-verify genoem word, by elke nuwe verbinding, en verwerp 'n sertifikaat wie se reeksnommer in daardie lys voorkom. Twee gevolge volg, en albei maak operasioneel saak. Die lêer moet leesbaar wees vir die rekening waarna die bediener privileges laat val, en 'n kliënt wat reeds gekoppel is, hou aan werk totdat hy weer koppel.
Daardie tweede gevolg verras mense tydens voorvalle. Om 'n sertifikaat te herroep sluit nie die tonnel wat dit tans gebruik nie. Paar die herroeping met 'n bestuursdoodmaak as die sessie onmiddellik moet eindig, en hanteer die twee aksies as aparte stappe in die runbook.
Inspekteer die lys om te sien wat die bediener werklik sal afdwing, eerder as om die tydstempel van die laaste lêer wat jy gekopieer het, te vertrou. Die reeksnommertelling is die deel wat saak maak.
openssl crl -in /etc/openvpn/server/crl.pem -noout -text | sed -n '1,14p'
ls -l /etc/openvpn/server/crl.pem'n Lys sonder inskrywings en 'n lys met die regte inskrywings lyk identies in 'n gidslys, daarom is dit die moeite werd om die reeksnommertelling te druk. Die toestemmingslyn maak net soveel saak, want 'n lêer wat die daemon nie kan lees nie, produseer 'n fout wat soos 'n verwerpte kliënt lyk.
Herstel van 'n rekord, versigtig
Om 'n sertifikaat te herstel beteken om 'n rekord in die uitreikdatabasis om te keer en 'n nuwe lys te publiseer. easy-rsa 3 hou daardie databasis as index.txt onder die PKI-gids, terwyl ouer uitlegte 'n ander reëling gebruik het. 'n Ry begin met 'n statusletter en 'n vervaldatum. 'n Herroepte ry voeg 'n tydstempel vir die herroeping in voordat dit met die reeksnommer, die sertifikaatlêernaam en die onderskeidende naam voortgaan. Om 'n ry terug te sit beteken om daardie tydstempel te skrap en die letter om te draai, terwyl alles anders alleen gelaat word.
Maak eers 'n rugsteun van die lêer, en skryf die wysiging as 'n skrip eerder as om in 'n teksredigeerder te tik. 'n Tjop wat verander hoeveel velde 'n ry dra, breek uitreiking vir elke sertifikaat wat daarna bygevoeg word. Dit is die rede om die verandering te outomatiseer en die lêer te kopieer voordat jy daaraan raak.
'n Tweede herroeping van dieselfde naam misluk dikwels ook, want die eerste lopie het daardie sertifikaat en sy sleutel uit die gidse geskuif waar die instrument dit verwag om te vind. Die instrument kan dan nie kry wat gevra is om te herroep nie, en die foutboodskap is nie altyd duidelik oor waarom nie.
cp /etc/easy-rsa/pki/index.txt /root/index.txt.$(date +%F-%H%M)
grep -c '^R' /etc/easy-rsa/pki/index.txt
easyrsa gen-crlPubliseer die nuwe lys, regstel die eienaarskap daarvan, en laat die bediener dit lees. 'n Herlaai is op die meeste installasies genoeg, maar die bevestiging moet van 'n vars verbinding kom, want die bestaande sessie het nooit iets weer nagegaan nie.
Kyk watter hefboom die geval verdien
Vra die een vraag wat die hele runbook besluit: is die privaatsleutel nog net waar dit moet wees. As dit so is, dek die sessiedoodmaak plus 'n gedokumenteerde pouse die geval en laat dit geen permanente rekord agter nie. As dit nie so is nie, is die enigste veilige antwoord 'n nuwe sleutel met die ou sertifikaat herroep gelaat.
Verifieer dan die uitkoms met 'n verbindingspoging eerder as met 'n konfigurasieverskil. Die verskil vertel jou wat jy bedoel het, en die verbinding vertel jou wat die bediener afdwing.
openssl crl -in /etc/openvpn/server/crl.pem -noout -text | grep -c 'Serial Number'
printf 'status 2\nquit\n' | nc 127.0.0.1 7506Wanneer 'n herstelde kliënt koppel en in die statusuitvoer verskyn, het die rekordwysiging gewerk. Wanneer 'n herroepte kliënt geweier word en die log die CRL noem, het die herroeping gewerk. Enigiets tussenin is 'n toestemmings- of herlaaiprobleem, en dit is die moeite werd om dit reg te maak voordat die volgende versoek opdaag.