OpenVPN bez klientského certifikátu: politika serveru, ne profil

Smažete řádky s certifikátem a klíčem, předáte profil a připojení stále selhává s chybou certifikátu. Profil nikdy nebyl tím, co tento požadavek vynucovalo. O tom, zda je klientský certifikát povinný, rozhoduje server a žádná úprava na straně klienta to nevyjedná. Oprava je tedy změna serverové politiky, provedená záměrně, se vším, co na ní závisí, aktualizovaným v témže kroku.

Profil není politika

Community OpenVPN 2.6 přichází s povinnými klientskými certifikáty, protože verify-client-cert má ve výchozím nastavení hodnotu require. Nastavení na none zastaví požadavek na certifikát a předá autentizaci klienta tomu uspořádání uživatelského jména a hesla, které server už používá. Starší návody sahají po client-cert-not-required, zastaralém pravopisu téže myšlenky, proto použijte direktivu, kterou dokumentuje vaše nainstalovaná verze. V každém případě se změna odehrává na serveru a žádný klientský profil ji nemůže provést.

Následující fragment je celá změna na straně serveru a sám o sobě není funkční konfigurací autentizace. verify-client-cert none odstraňuje požadavek na certifikát, zatímco username-as-common-name činí název účtu identitou, kterou vidí pozdější zpětná volání a soubory jednotlivých klientů. Ani jeden řádek nekontroluje heslo, takže verifikátor stále musí existovat.

verify-client-cert none
username-as-common-name

Tím verifikátorem je plugin nebo skript řízený auth-user-pass-verify a musí být na místě dřív, než kterýkoli z výše uvedených řádků něco znamená. Opačné pořadí vám dá okno, ve kterém server nechce certifikát a nekontroluje účet.

Co server stále ověřuje

Zrušení klientského certifikátu neznamená zrušení TLS. Server si ponechává svůj certifikát a klíč a klient si ponechává důvěru v CA a kontroly názvu hostitele, které mu brání mluvit s podvodníkem. Odstranění remote-cert-tls server nebo balíku CA proto, že klient už nemá certifikát, je časté a vážné nepochopení a reference k 2.6 výslovně uvádí, že oba směry jsou nezávislé. Jeden prokazuje server klientovi; druhý prokazuje klienta serveru.

Profil může nést také blok tls-auth nebo tls-crypt. Je to sdílený klíč řídicího kanálu s vlastním cyklem distribuce a rotace, takže soubor bez řádků s certifikátem nebo klíčem není automaticky bezpečný k publikování. Považujte ho za tajemství, dokud ho nepřečtete.

Soubor certifikátu zkopírovaný z funkčního profilu sám o sobě nic nedokazuje; držení znamená mít soukromý klíč, který k němu pasuje, což nasazení ověřující certifikátem kontroluje. Soubor, který obsahuje certifikát, není soubor, kterým se lze autentizovat.

Co musí verifikátor dělat

Po odstranění požadavku na certifikát stojí vše na verifikátoru: pluginu nebo skriptu řízeném auth-user-pass-verify. Musí odmítat neplatné přihlašovací údaje, odmítat zakázané nebo nezpůsobilé účty a při nedostupnosti backendu selhat zavřeně. username-as-common-name se často zapíná vedle toho a mění identitu, kterou vidí pozdější zpětná volání a konfigurační soubory jednotlivých klientů. Neověřuje heslo a nečiní nezpůsobilý účet způsobilým. To jsou oddělené úlohy a jejich záměna je způsob, jak migrace projde testem šťastné cesty a selže při svém prvním skutečném incidentu.

Testujte negativní případy stejně pečlivě jako pozitivní. Profil, který zobrazí výzvu k zadání hesla, dokazuje jen to, že klient umí vykreslit výzvu, zatímco server, který přijme špatné heslo, dokazuje něco podstatně horšího. Přidejte do testovací sady zakázaný účet a propadlý přihlašovací údaj, ne jen špatné heslo.

Měňte politiku, profil a mapování společně

Slaďte tři věci: direktivu serveru, klientský profil a mapování identity jednotlivých klientů. Změňte je odděleně a klienti selžou před ověřením, nebo se připojí pod jménem, které správce nečekal, což je horší, protože to vypadá jako úspěch. Spojení, které uspěje pod špatnou identitou, se odhalí obtížněji než to, které selže.

Pro tuto cestu udržujte dva testovací účty, jeden platný a jeden známý špatný, a po každé změně verifikátoru použijte oba. Platný účet dokazuje šťastnou cestu a mapování identity; špatný dokazuje, že odmítnutí stále funguje. Ani jeden test nic neříká o pravidlech způsobilosti, proto přidejte účet, který má být odmítnut z politických důvodů, pokud je nasazení má. Po každé změně spusťte všechny tři, protože verifikátor, který začne přijímat všechno, vypadá přesně jako fungující přihlášení.

Zaznamenejte, které metody autentizace server skutečně přijímá, ne které navrhuje profil. Tento záznam odpovídá na otázku, kterou lidé stále kladou, totiž kdo se k této službě může připojit. Přežije i dalšího správce, který by ho jinak znovu objevil ze zachycení paketů.