WireGuard profila IPsec atebiderako: zer eskatu horren ordez

Atebide isil batekin eskuko keinuaren denbora-mugak sarritan inoiz elkartzen ez diren bi protokolo esan nahi ditu. WireGuard pare batek Noise hitz egiten du, IPsec atebideak IKE itxaroten duen bitartean. Helbide eta portu zuzenek ez dute hori aldatzen.

Profil batean mutur-puntua berrerabiltzeak ez ditu biak lotzen. Hurrengo urratsa atebidea kudeatzen duenari eskaera bat egitea da.

Lehen eskaera: protokoloaren bertsioa

IPsec-ek familia bat izendatzen du, ez lan-fluxu bakarra. IKEv2 eta IKEv1 ezberdinak dira beren trukeetan, autentifikazio-aukeretan eta sare-aldaketaren aurreko jokabidean. IKEv1 soilik amaitzen duen atebide bat IKEv2 eskaintzen duenaren oso bestelakoa izango da. Bezeroaren konfigurazioa harekin batera aldatzen da.

Galdetu zer bertsio amaitzen duen zerbitzuak eta estandarretan oinarritutako inplementazioa ala bere bezero propioa duen hornitzaile-bariantea exekutatzen duen. Sistema eragileen menuak askotan erantzun hori etiketa bakar baten atzean ezkutatzen dute. Etiketa ez da protokoloa.

Bigarren eskaera: bezeroaren autentifikazio metodoa

Autentifikazioa da benetako lanaren zatirik handiena dagoen tokia. Zerbitzuak makina-ziurtagiri bat espero dezake gako-erabilera hedatu zehatz batekin, erabiltzaile-ziurtagiri bat, IKEv2 gaineko EAP metodo bat edo identitate bati lotutako aldez aurretik partekatutako gako bat. Zein aplikatzen den erabakitzen du bezeroak zer behar duen.

WireGuard gako pribatu bat ez da horietako bat ere ez. Eskuko keinu zehatz batean erabiltzen den Curve25519 gako bat da. Inolako bihurketak ez du ziurtagiri edo EAP kredentzial bihurtzen. Kontrakoa dioen tresna batek fitxategia berrizendatzen ari da edo zerikusirik ez duen zerbait sortzen.

RFC 7296ko IKEv2 zehaztapenak deskribatzen du bertsio horren inplementazio batek zer onartu behar duen. Operadorearen erantzun lauso baterako erreferentzia da, ez bezeroaren konfigurazio-gida.

Hirugarren eskaera: konfiantzazko identitatea eta helmugak

Eskatu atebidearen identitatea bezeroak ikusi behar duen moduan, eta hura baliozkotzen duen konfiantza-aingura. Gero galdetu zer barruti pribatu eta ebazle bultzatzen dituen zerbitzuak. Bi erantzun horiek erabakitzen dute tuneletik zer doan benetan.

Haiek gabe, funtzionatzen duen konexio batek huts egin dezake zereginean. Ebazlerik bultzatu gabe altxatutako tunel batek barne-izenak erantzunik gabe uzten ditu. Trafiko-hautatzaile bat falta bada, helmuga tunelaz kanpo geratzen da eskuko keinua lortu arren.

Mutur-puntuaren zundaketa batek bezeroaren erroreak ez bezalako galdera bati erantzuten dio. Irisgarri den portu batek elkartzerik gabe autentifikazioa adierazten du, eta irisgarri ez den portuak bidea.

# 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

Exekutatu zundaketa hori bezeroan ezer aldatu aurretik. Portuek erantzuten badute eta elkartzeak huts egiten jarraitzen badu, arazoa kredentzialak edo politika dira. Batere erantzuten ez badute, ez du profil-aldaketak lagunduko.

Bi protokoloek elkarrekin egon behar dutenean

Bi sareak administratzea bi protokoloak mantentzeko arrazoi legitimoa da. Ohiko diseinuak WireGuard eta IPsec interfaze bereizietan edo atebide bereizietan amaitzen ditu. Onartutako trafikoa bien artean bideratzen da orduan.

Diseinu horrek konfiantza eta baimen muga bat sartzen du, eta horrela idatzi beharko litzateke. Zein pare pasa daitekeen, zein norabidetan eta noren politikaren pean bideratze eta suebaki erabakia da. Bi protokoloetako batek ere ez du hori ematen.

Hori ez dena bihurketa garden bat da. WireGuard bidez iristen den trafikoa IPsec tunelean berriro sortzen da, eta tartean dagoen politika oro aplikatzen zaio.

Argitu lehenik zerbitzariaren protokolo- eta autentifikazio-baldintzak. Gero erabili operadoreak onartzen duen bezeroa eta izen-emate bidea, eta eduki gako pribatuak web-bihurgailuetatik kanpo hori gertatzen den bitartean.