Koraci VPN rukovanja: što se događa prije nego što podaci počnu teći

Pritiskom na Poveži pokreću se četiri odvojena zadatka koji uspijevaju ili ne uspijevaju neovisno. Klijent mora stići do slušača, dogovoriti tko je partner, izvesti ključeve i zatim predati radni tunel ostatku sustava. Većina neuspjelih veza dijagnosticira se u pogrešnom zadatku. Zato je prva pogreška važnija od trećeg pokušaja.

Prvo stignite do slušača

Prije nego što se razmijeni ikakav identitet, klijent razrješava ime, odabire rutu i otvara prijenos prema portu. Zarobljeni portal koji odgovara na sve, zatvoren port i pogrešno ime hosta ovdje ne uspijevaju, i nijedno od toga nije problem autentikacije. Promjena lozinke ne može popraviti nijedno od tri. Pročitajte prvi redak pogreške prije nego što dirnete vjerodajnice.

Istek vremena, odbijanje certifikata i odbijen račun tri su različita kvara s tri različite provjere. Njihovo prvo razvrstavanje sprječava da se mrežni problem otklanja kao problem s vjerodajnicama.

Dokažite partnera, zatim izvedite ključeve

Svaki protokol treba način da prepozna predviđeni poslužitelj, bilo kroz konfigurirani javni ključ ili lanac certifikata. Prijava korisnika je dodatak toj provjeri, a ne njezina zamjena. Poslužitelj koji prihvati vašu lozinku nije dokazao ništa o vlastitom identitetu. Zato zajednička tajna otkucana u klijentu nije zamjena za provjeru onoga što je odgovorilo.

Razmjena zatim izvodi ključeve prometa iz vlastitih ulaza protokola, a lozinka za prijavu obično nije ključ koji se utiskuje na svaki paket. Dugoročni identitetski materijal i kratkotrajni sesijski ključevi imaju različit životni vijek i različite zadaće. Upravo o tom razdvajanju govori unaprijedna tajnost.

Držite provjeru uključenom dok rješavate probleme, jer tunel koji se poveže nakon što isključite provjeru nije dokazao ništa osim da je ta provjera nešto radila. Zabilježite što ste promijenili i vratite to prije sljedećeg testa.

Tri protokola, tri razgovora

U OpenVPN postavi temeljenoj na TLS-u kontrolni kanal pregovara sigurnosne parametre dok podatkovni kanal prenosi promet tunela, pa opcija podatkovnog kanala i problem s certifikatom žive na različitim mjestima. IKEv2 autentificira oba sudionika i zatim uspostavlja sigurnosne asocijacije IPsec s vlastitim rokovima. WireGuard izvodi ključeve kroz svoju razmjenu zasnovanu na Noiseu i namjerno drži stroj stanja malim. Znanje koji od ta tri pokrećete odlučuje koji je dnevnik vrijedan čitanja.

Slično izgledajući klijenti ne znače da su poruke ispod zamjenjive, a polje konfiguracije koje postoji u jednom proizvodu možda nema pandan u drugom. Kopiranje profila među njima je nagađanje, a ne migracija.

Što rukovanje ne čini

Rute, razrješavanje imena i politika odredišta sve ostaju nakon toga. Interno sjedište može ostati nedostupno jer nedostaje ruta njegove podmreže, iako je partner ispravno autentificiran i tunel je aktivan. Tretirati to kao slabu enkripciju šalje vas u pogrešan sloj, i obično završava promjenom šifre koja ništa ne popravlja.

Osvježavanje ključeva i ponovno povezivanje također izgledaju isto na većini prikaza stanja, i nijedno ne kaže je li običan promet bio blokiran tijekom prekida. Samo politika neuspjeha klijenta odgovara na to pitanje, pa čitajte politiku, a ne ikonu.

Radite faze gore navedenim redom i zaustavite se na prvoj koja proizvede pogrešku. Svaka kasnija faza nasljeđuje stanje prethodnih, pa neuspjeh u trećoj fazi ne govori ništa o četvrtoj.

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