WireGuard profil za IPsec pristupnik: što tražiti umjesto toga

Istek vremena rukovanja s tihim pristupnikom obično znači dva protokola koja se nikad ne susreću. WireGuard partner govori Noise dok IPsec pristupnik čeka IKE. Ispravna adresa i port to ne mijenjaju.

Ponovno korištenje odredišta u profilu ne spaja njih dvoje. Sljedeći je korak zahtjev onome koji upravlja pristupnikom.

Prvi zahtjev: verzija protokola

IPsec označava obitelj, a ne jedan tijek rada. IKEv2 i IKEv1 razlikuju se u svojim razmjenama, mogućnostima provjere autentičnosti i ponašanju pri promjeni mreže. Pristupnik koji prekida samo IKEv1 ponašat će se posve drukčije od onoga koji nudi IKEv2. Konfiguracija klijenta razlikuje se s time.

Pitajte koju verziju usluga prekida i pokreće li standardnu implementaciju ili proizvođačku varijantu s vlastitim klijentom. Izbornici operacijskih sustava često skrivaju taj odgovor iza jedne oznake. Oznaka nije protokol.

Drugi zahtjev: metoda provjere autentičnosti klijenta

Provjera autentičnosti mjesto je gdje leži većina stvarnog rada. Usluga može očekivati potvrdu stroja s određenom proširenom namjenom ključa, korisničku potvrdu, EAP metodu preko IKEv2 ili unaprijed dijeljeni ključ vezan uz identitet. Koja se primjenjuje, određuje što klijent treba.

Privatni ključ WireGuarda nije ništa od toga. To je ključ Curve25519 koji se koristi u jednom određenom rukovanju. Nikakva pretvorba ne čini ga potvrdom ni EAP vjerodajnicom. Alat koji tvrdi suprotno preimenuje datoteku ili stvara nešto nepovezano.

Specifikacija IKEv2 u RFC 7296 opisuje što implementacija te verzije mora podržavati. To je referenca za neodređen odgovor operatera, a ne vodič za konfiguraciju klijenta.

Treći zahtjev: pouzdani identitet i odredišta

Zatražite identitet pristupnika onako kako ga klijent mora vidjeti, uz sidro povjerenja koje ga potvrđuje. Zatim pitajte koje privatne raspone i razrješivače usluga šalje. Ta dva odgovora određuju što tunel zapravo prenosi.

Bez njih radna veza ipak može podbaciti u zadatku. Tunel koji je podignut bez poslanog razrješivača ostavlja interna imena neodgovorenima. Nedostajući birač prometa ostavlja odredište izvan tunela iako je rukovanje uspjelo.

Provjera odredišta odgovara na drugo pitanje od pogreške klijenta. Dostupan port bez pridruživanja upućuje na provjeru autentičnosti, a nedostupan port na put.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Izvedite tu provjeru prije nego što bilo što promijenite u klijentu. Ako portovi odgovaraju, a pridruživanje i dalje ne uspijeva, problem je u vjerodajnicama ili pravilima. Ako uopće ne odgovaraju, nikakva izmjena profila neće pomoći.

Kada oba protokola moraju supostojati

Upravljanje objema mrežama legitiman je razlog za zadržavanje oba protokola. Uobičajen dizajn prekida WireGuard i IPsec na odvojenim sučeljima ili odvojenim pristupnicima. Odobreni se promet zatim usmjerava između njih.

Taj dizajn uvodi granicu povjerenja i ovlaštenja i treba je takvom i zapisati. Koji partneri smiju prijeći, u kojem smjeru i po čijim pravilima, odluka je o usmjeravanju i vatrozidu. Nijedan od ta dva protokola to ne pruža.

Ono što nije jest prozirna pretvorba. Promet koji dolazi preko WireGuarda iznova se uspostavlja u IPsec tunel i svako se pravilo između primjenjuje na njega.

Najprije razjasnite zahtjeve poslužitelja za protokol i provjeru autentičnosti. Zatim upotrijebite klijent i put registracije koje operater podržava i držite privatne ključeve podalje od web pretvarača dok se to odvija.