Koraki rokovanja VPN: kaj se zgodi, preden se promet začne prenašati

Pritisk na Poveži zažene štiri ločene naloge, ki uspejo ali ne uspejo neodvisno. Odjemalec mora doseči poslušalca, se dogovoriti, kdo je partner, izpeljati ključe in nato predati delujoč tunel preostanku sistema. Večina neuspešnih povezav se diagnosticira v napačni nalogi. Zato je prva napaka pomembnejša od tretjega poskusa.

Najprej dosezite poslušalca

Preden se izmenja kakršna koli identiteta, odjemalec razreši ime, izbere pot in odpre transport do vrat. Ujeti portal, ki odgovori na vse, zaprta vrata in napačno ime gostitelja tu ne uspejo, in nobeno od tega ni težava preverjanja pristnosti. Sprememba gesla ne more popraviti nobene od treh. Preberite prvo vrstico napake, preden se dotaknete poverilnic.

Časovna omejitev, zavrnitev potrdila in zavrnjen račun so tri različne okvare s tremi različnimi preverjanji. Prav njihova prva razvrstitev prepreči, da bi se omrežna težava odpravljala kot težava s poverilnicami.

Dokažite partnerja, nato izpeljite ključe

Vsak protokol potrebuje način, da prepozna predvideni strežnik, bodisi s konfiguriranim javnim ključem bodisi z verigo potrdil. Prijava uporabnika je dodatek k temu preverjanju, ne njegova zamenjava. Strežnik, ki sprejme vaše geslo, ni dokazal ničesar o svoji identiteti. Zato skupna skrivnost, vtipkana v odjemalca, ne nadomesti preverjanja, kdo je odgovoril.

Izmenjava nato izpelje prometne ključe iz lastnih vhodov protokola, prijavno geslo pa običajno ni ključ, ki se odtisne na vsak paket. Dolgoročno identitetno gradivo in kratkotrajni sejni ključi imajo različno življenjsko dobo in različne naloge. Prav o tej ločitvi govori nadaljnja tajnost.

Preverjanje pustite vključeno med odpravljanjem težav, ker tunel, ki se poveže po tem, ko izklopite preverjanje, ni dokazal ničesar razen tega, da je preverjanje nekaj počelo. Zapišite, kaj ste spremenili, in pred naslednjim testom to vrnite.

Trije protokoli, trije pogovori

V namestitvi OpenVPN, ki temelji na TLS, krmilni kanal pogaja varnostne parametre, medtem ko podatkovni kanal prenaša promet tunela, zato možnost podatkovnega kanala in težava s potrdilom živita na različnih mestih. IKEv2 overi oba udeleženca in nato vzpostavi varnostne povezave IPsec z lastnimi življenjskimi dobami. WireGuard izpelje ključe s svojo izmenjavo, ki temelji na Noise, in stanje stroja namerno drži majhno. Vedeti, katerega od treh poganjate, odloči, kateri dnevnik je vreden branja.

Podobno videti odjemalci ne pomenijo izmenljivih sporočil pod njimi, in konfiguracijsko polje, ki obstaja v enem izdelku, morda nima ustreznice v drugem. Kopiranje profila med njimi je ugibanje in ne selitev.

Česa rokovanje ne naredi

Poti, razreševanje imen in politika cilja vse ostanejo po tem. Notranje spletišče lahko ostane nedosegljivo, ker manjka pot njegove podomrežja, čeprav je partner pravilno overjen in tunel deluje. Če to obravnavate kot šibko šifriranje, iščete v napačnem sloju, in običajno se konča s spremembo šifre, ki ničesar ne popravi.

Osveževanje ključev in ponovno povezovanje sta v večini prikazov stanja videti enako, in nobeno od njiju ne pove, ali je bil običajni promet med prekinitvijo blokiran. Na to vprašanje odgovori le politika napak odjemalca, zato berite politiko in ne ikone.

Stopnje izvedite v zgornjem vrstnem redu in se ustavite pri prvi, ki ustvari napako. Vsaka naslednja stopnja podeduje stanje prejšnjih, zato napaka v tretji stopnji ne pove ničesar o četrti.

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