Ferâldere fersiferingsrigels yn âlde VPN-profylen: lês se foar it kopiearjen

Dit profyl is yn 2016 skreaun en it wurdt noch ymporteare en it ferbynt noch. Dat is krekt wêrom’t gjinien der nei sjocht. De klant dy’t dizze rjochtlinen ea lies is al lang fuort, en de hjoeddeiske ferzje kin ferskate derfan oars parse.

Dat in bestân oerlibbet betsjut net dat de konfiguraasje by de tiid is. It skieden fan dy twa ideeën is it grutste part fan it wurk.

Fyn út hokker klant it profyl skreau

Begjin by de útjouwer en de ferzje. De betsjutting fan in rjochtline wurdt bepaald troch de ymplemintaasje dy’t him lêst. In rigel dy’t ea in algoritme keas kin in fallbacklist, in warskôging of in hurde flater wurde. Hokker útjefte him parset beslút de útkomst.

OpenVPN is it dúdlikste foarbyld. Ferzje 2.5 yntrodusearre data-ciphers en feroare hoe’t de âldere rjochtline cipher oan ’e ûnderhanneling mei docht. In profyl dat allinnich cipher AES-128-CBC hat, docht no in folle smeller foarstel as syn auteur bedoelde.

Lês de útjefte-opmerkingen foar de ynstelling dy’t no warskôget of mislearret. In warskôging yn it logboek is in feit oer de hjoeddeiske ferzje, en it weaget swierder as immen syn oantinken oan wêrom’t de rigel tafoege waard.

Sjoch wat der eins úthannele is

Súksesfolle ymport bewiist parsing, net belied. It úthannele resultaat ferskynt yn it klantlogboek neidat de ferbining omheech komt. It kin fan beide kanten fan it konfiguraasjebestân ferskille.

# OpenVPN: what did this session agree on?
sudo journalctl -u openvpn-client@office --since '5 min ago' | grep -i 'cipher\|Data Channel'

# which directives does the profile actually carry?
grep -n -E 'cipher|auth|tls-|dh ' office.ovpn

In akseptearre ymport dy’t stil in rjochtline falle lit, lit in profyl efter dat op ien manier lêst en op in oare manier docht. Dat gat is hoe’t in dokumint dat as hurde is markearre eat swakker úthannelet as’t syn eigen tekst beweart. It logboek is it ienige plak dêr’t it ferskil te sjen is. Lês it foardat jo it bestân fertrouwe.

Werkje de regeling by, net de rigel

Nim it profyl dat de operator ûnderhâldt yn stee fan algoritmenammen byinoar te setten oant de ymport ophâldt mei klagen. Rigels tafoegje by besykjen keart de rjochting fan ’e reparaasje om. It past de klant oan in ûnbekende tsjinner oan yn stee fan fêst te stellen wat de tsjinner stipet.

De tsjinner hat miskien ek de koördinearre bywurking nedich. In hjoeddeiske klant kin gjin stipe meitsje foar in foarstel dat de oare kant nea biedt. Gjin opsje oan ’e klantkant ferfangt in gateway dy’t net bywurke is.

Wat net opjûn wurde mei is ferifikaasje. Sertifikaatkontrôles fuortsmite, de hostnamkontrôle útsette of bywurkings útsette om in âld profyl libben te hâlden makket fan in kompatibiliteitsprobleem in fertrouwensprobleem. Dat bart meastentiids ien lytse bewurking tagelyk.

Befêstigje it resultaat en registrearje de útsûndering

Nei de wiziging, besjoch de úthannele set opnij en test it middel wêr’t de tunnel foar bestiet. In profyl dat úthannelet wat jo bedoelden en dochs de tsjinst net berikt hat in routing- of identiteitsprobleem. It hat gjin kryptografysk probleem.

Hâld de foarige bekende-goede konfiguraasje op in beskerme plak. In fergeliking is allinnich mooglik salang’t it âlde bestân noch bestiet.

Dokumintearje elke kompatibiliteitsútsûndering mei in eigner en in kontrôledatum. In tydlike regeling sûnder eigner wurdt belied foar altyd. De folgjende persoan dy’t it bestân lêst sil oannimme dat it bewust keazen is.