WireGuard-profiel vir 'n IPsec-gateway: waarna om eerder te vra

Handskakel-tydverstrekings by 'n stil gateway beteken gewoonlik twee protokolle wat mekaar nooit ontmoet nie. 'n WireGuard-eweknie praat Noise terwyl 'n IPsec-gateway op IKE wag. 'n Korrekte adres en poort verander dit nie.

Om die eindpunt in 'n profiel te hergebruik, oorbrug nie die twee nie. Die volgende stap is 'n versoek aan die persoon wat die gateway bedryf.

Versoek een: die protokolweergawe

IPsec dui 'n familie aan, nie 'n enkele werkwyse nie. IKEv2 en IKEv1 verskil in hul uitruilings, hul verifikasiemoontlikhede en hul gedrag oor 'n netwerkverandering. 'n Gateway wat net IKEv1 termineer, sal heel anders optree as een wat IKEv2 bied. Die kliëntkonfigurasie verskil daarmee saam.

Vra watter weergawe die diens termineer en of dit 'n standaardgebaseerde implementering of 'n verskaffersvariant met sy eie kliënt gebruik. Bedryfstelselmenu's verberg dikwels daardie antwoord agter 'n enkele etiket. Die etiket is nie die protokol nie.

Versoek twee: die verifikasiemetode van die kliënt

Verifikasie is waar die meeste van die werklike werk lê. Die diens verwag moontlik 'n masjien-sertifikaat met 'n bepaalde uitgebreide sleutelgebruik, 'n gebruikersertifikaat, 'n EAP-metode oor IKEv2, of 'n vooraf gedeelde sleutel wat aan 'n identiteit gebind is. Watter een geld, bepaal wat die kliënt nodig het.

'n WireGuard-privaatsleutel is nie een van daardie dinge nie. Dit is 'n Curve25519-sleutel wat in een spesifieke handskakeling gebruik word. Geen omskakeling maak dit 'n sertifikaat of 'n EAP-aanmelding nie. 'n Gereedskap wat anders beweer, hernoem die lêer of genereer iets wat nie verband hou nie.

Die IKEv2-spesifikasie in RFC 7296 beskryf wat 'n implementering van daardie weergawe moet ondersteun. Dit is 'n verwysing vir 'n vae operateurantwoord, nie 'n gids vir kliëntkonfigurasie nie.

Versoek drie: die vertroude identiteit en die bestemmings

Vra na die gateway-identiteit soos die kliënt dit moet sien, plus die vertrouensanker wat dit valideer. Vra dan watter private reekse en oplossers die diens stuur. Daardie twee antwoorde bepaal wat die tonnel werklik vervoer.

Sonder hulle kan 'n werkende verbinding steeds die taak misluk. 'n Tonnel wat staan sonder 'n gestuurde oplosser laat interne name onbeantwoord. 'n Ontbrekende verkeerskeurder laat die bestemming buite die tonnel, selfs al het die handskakeling geslaag.

'n Peiling van die eindpunt beantwoord 'n ander vraag as die kliëntfout. 'n Bereikbare poort sonder assosiasie dui op verifikasie, terwyl 'n onbereikbare poort op die pad dui.

# 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

Voer daardie peiling uit voordat jy enigiets in die kliënt verander. As die poorte antwoord en die assosiasie steeds misluk, is die probleem die aanmeldings of die beleid. As hulle glad nie antwoord nie, sal geen profielwysiging help nie.

Wanneer albei protokolle moet saambestaan

Om albei netwerke te administreer is 'n geldige rede om albei protokolle te hou. Die gewone ontwerp termineer WireGuard en IPsec op aparte interfaces of aparte gateways. Goedgekeurde verkeer word dan tussen hulle gerouteer.

Daardie ontwerp skep 'n vertrouens- en magtigingsgrens, en dit moet as sodanig neergeskryf word. Watter eweknieë mag oorgaan, in watter rigting, en onder wie se beleid, is 'n routerings- en firewallbesluit. Nie een van die protokolle lewer dit nie.

Wat dit nie is nie, is 'n deursigtige omskakeling. Verkeer wat oor WireGuard aankom, word weer in die IPsec-tonnel uitgestuur, en elke beleid daartussen geld daarvoor.

Bepaal eers die protokol- en verifikasiemetodes van die bediener. Gebruik dan die kliënt en die registrasiepad wat die operateur ondersteun, en hou private sleutels uit web-omskakelaars terwyl dit gebeur.