Koraci VPN rukovanja: šta se dešava prije nego što podaci počnu teći

Pritisak na Poveži pokreće četiri odvojena zadatka koji uspijevaju ili ne uspijevaju nezavisno. Klijent mora doći do slušača, dogovoriti ko je partner, izvesti ključeve i zatim predati radni tunel ostatku sistema. Većina neuspješnih veza se dijagnostikuje u pogrešnom zadatku. Zato je prva greška važnija od trećeg pokušaja.

Prvo dođite do slušača

Prije nego što se razmijeni ikakav identitet, klijent razrješava ime, bira rutu i otvara transport ka portu. Zarobljeni portal koji odgovara na sve, zatvoren port i pogrešno ime hosta ovdje ne uspijevaju, i nijedno od toga nije problem autentifikacije. Promjena lozinke ne može popraviti nijedno od tri. Pročitajte prvi red greške prije nego što dirnete akreditive.

Istek vremena, odbijanje certifikata i odbijen nalog su tri različita kvara s tri različite provjere. Njihovo prvo razvrstavanje je ono što sprječava da se mrežni problem otklanja kao problem s akreditivima.

Dokažite partnera, pa izvedite ključeve

Svaki protokol treba način da prepozna namjeravani server, bilo kroz konfigurisani javni ključ ili lanac certifikata. Prijava korisnika je dodatak toj provjeri, a ne njena zamjena. Server 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 zadatke. 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 šta ste promijenili i vratite to prije sljedećeg testa.

Tri protokola, tri razgovora

U OpenVPN implementaciji zasnovanoj na TLS-u kontrolni kanal pregovara sigurnosne parametre dok podatkovni kanal nosi promet tunela, pa opcija podatkovnog kanala i problem s certifikatom žive na različitim mjestima. IKEv2 autentifikuje oba učesnika i zatim uspostavlja sigurnosne asocijacije IPsec s vlastitim rokovima. WireGuard izvodi ključeve kroz svoju razmjenu zasnovanu na Noise i namjerno drži mašinu stanja malom. 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 između njih je nagađanje, a ne migracija.

Šta rukovanje ne radi

Rute, razrješavanje imena i politika odredišta sve ostaju nakon toga. Interna lokacija može ostati nedostupna jer nedostaje ruta njene podmreže, iako je partner ispravno autentifikovan i tunel je aktivan. Tretiranje toga kao slabe enkripcije šalje vas da tražite u pogrešnom sloju, 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 da li je običan promet bio blokiran tokom 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 greš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