Kroky handshaku VPN: co se děje, než začnou téct data

Stisknutí Připojit spouští čtyři samostatné úlohy, které uspějí nebo selžou nezávisle. Klient musí dosáhnout posluchače, dohodnout, kdo je protistrana, odvodit klíče a potom předat funkční tunel zbytku systému. Většina neúspěšných připojení se diagnostikuje ve špatné úloze. Proto je první chyba důležitější než třetí pokus.

Nejprve dosáhněte posluchače

Než se vymění jakákoli identita, klient přeloží jméno, zvolí trasu a otevře transport na port. Captive portál, který odpovídá na všechno, zavřený port a špatné jméno hostitele zde selhávají a žádná z těchto věcí není problém autentizace. Změna hesla nemůže opravit ani jednu z těch tří. Přečtěte si první řádek chyby, než se dotknete přihlašovacích údajů.

Časový limit, odmítnutí certifikátu a odmítnutý účet jsou tři různé závady se třemi různými kontrolami. Právě jejich první roztřídění brání tomu, aby se síťový problém ladil jako problém s údaji.

Prokažte protistranu, pak odvoďte klíče

Každý protokol potřebuje způsob, jak rozpoznat zamýšlený server, ať už nakonfigurovaným veřejným klíčem, nebo řetězem certifikátů. Přihlášení uživatele je k této kontrole navíc, ne její náhradou. Server, který přijme vaše heslo, neprokázal nic o své vlastní identitě. Proto sdílené tajemství napsané do klienta nenahrazuje ověření toho, kdo odpověděl.

Výměna pak odvozuje klíče provozu z vlastních vstupů protokolu a přihlašovací heslo obvykle není klíč, který se razí na každý paket. Dlouhodobý identitní materiál a krátkodobé klíče relace mají různou životnost a různé úkoly. Právě o tomto oddělení je dopředná utajení.

Ponechte ověřování zapnuté při řešení problémů, protože tunel, který se připojí poté, co ověření vypnete, neprokázal nic jiného než to, že ověření něco dělalo. Poznamenejte si, co jste změnili, a před dalším testem to vraťte.

Tři protokoly, tři rozhovory

V nasazení OpenVPN založeném na TLS vyjednává řídicí kanál bezpečnostní parametry, zatímco datový kanál přenáší provoz tunelu, takže volba datového kanálu a problém s certifikátem žijí na různých místech. IKEv2 autentizuje oba účastníky a poté vytváří bezpečnostní asociace IPsec s vlastní životností. WireGuard odvozuje klíče svou výměnou založenou na Noise a stavový automat drží záměrně malý. Znalost toho, který ze tří provozujete, rozhoduje o tom, který log stojí za přečtení.

Podobně vypadající klienti neznamenají zaměnitelné zprávy pod povrchem a konfigurační pole, které existuje v jednom produktu, nemusí mít protějšek v jiném. Kopírování profilu mezi nimi je odhad, nikoli migrace.

Co handshake nedělá

Trasy, překlad jmen a politika cíle všechny zůstávají potom. Interní web může zůstat nedostupný, protože chybí trasa jeho podsítě, i když je protistrana správně autentizována a tunel běží. Považovat to za slabé šifrování vás pošle hledat do špatné vrstvy a obvykle to skončí změnou šifry, která nic neopraví.

Obnova klíčů a opětovné připojení také vypadají v většině stavových displejů stejně a ani jedno neříká, zda byl běžný provoz během výpadku blokován. Na tuto otázku odpovídá jen politika selhání klienta, takže čtěte politiku, ne ikonu.

Proveďte fáze ve výše uvedeném pořadí a zastavte se u první, která vyprodukuje chybu. Každá další fáze dědí stav předchozích, takže selhání ve třetí fázi nic neříká o čtvrté.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal