WireGuard-profiili IPsec-yhdyskäytävälle: mitä sen sijaan kannattaa kysyä

Kättelyn aikakatkaisut hiljaisen yhdyskäytävän kanssa tarkoittavat yleensä kahta protokollaa, jotka eivät koskaan kohtaa. WireGuard-vertaispiste puhuu Noisea, kun taas IPsec-yhdyskäytävä odottaa IKE:tä. Oikea osoite ja portti eivät muuta sitä.

Päätepisteen uudelleenkäyttö profiilissa ei silloita niitä kahta. Seuraava askel on pyyntö sille, joka yhdyskäytävää hallinnoi.

Ensimmäinen pyyntö: protokollan versio

IPsec nimeää perheen, ei yhtä työnkulkua. IKEv2 ja IKEv1 eroavat vaihdoissaan, todennusvaihtoehdoissaan ja käyttäytymisessään verkon vaihtuessa. Yhdyskäytävä, joka päättää vain IKEv1:n, käyttäytyy aivan eri tavoin kuin se, joka tarjoaa IKEv2:n. Asiakasohjelman kokoonpano muuttuu sen mukana.

Kysy, minkä version palvelu päättää ja ajaako se standardipohjaista toteutusta vai toimittajakohtaista varianttia omalla asiakasohjelmalla. Käyttöjärjestelmien valikot kätkevät vastauksen usein yhden merkinnän taakse. Merkintä ei ole protokolla.

Toinen pyyntö: asiakasohjelman todennusmenetelmä

Todennus on se paikka, jossa suurin osa todellisesta työstä on. Palvelu voi odottaa konelaitteen varmennetta tietyllä laajennetulla avaimenkäytöllä, käyttäjän varmennetta, EAP-menetelmää IKEv2:n yli tai identiteettiin sidottua ennalta jaettua avainta. Se, mikä niistä pätee, ratkaisee, mitä asiakasohjelma tarvitsee.

WireGuardin yksityinen avain ei ole mitään noista. Se on Curve25519-avain, jota käytetään yhdessä tietyssä kättelyssä. Mikään muunnos ei tee siitä varmennetta tai EAP-tunnistetietoa. Työkalu, joka väittää muuta, nimeää tiedoston uudelleen tai tuottaa jotain asiaankuulumatonta.

IKEv2:n määritelmä RFC 7296:ssa kuvaa, mitä kyseisen version toteutuksen on tuettava. Se on viite epämääräiselle operaattorin vastaukselle, ei asiakasohjelman kokoonpano-opas.

Kolmas pyyntö: luotettu identiteetti ja kohteet

Pyydä yhdyskäytävän identiteetti sellaisena kuin asiakasohjelman on se nähtävä, sekä sitä validoiva luottamusankkuri. Kysy sitten, mitä yksityisiä alueita ja nimipalvelimia palvelu työntää. Ne kaksi vastausta ratkaisevat, mitä tunneli todella kuljettaa.

Ilman niitä toimiva yhteys voi silti epäonnistua tehtävässä. Tunneli, joka on pystyssä ilman työnnettyä nimipalvelinta, jättää sisäiset nimet vastaamatta. Puuttuva liikenteen valitsin jättää kohteen tunnelin ulkopuolelle, vaikka kättely onnistui.

Päätepisteen luotaus vastaa eri kysymykseen kuin asiakasohjelman virhe. Saavutettava portti ilman liitosta viittaa todennukseen, kun taas saavuttamaton portti viittaa reittiin.

# 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

Suorita luotaus ennen kuin muutat asiakasohjelmassa mitään. Jos portit vastaavat ja liitos epäonnistuu edelleen, ongelma on tunnistetiedoissa tai käytännössä. Jos ne eivät vastaa lainkaan, mikään profiilin muokkaus ei auta.

Kun molempien protokollien on oltava olemassa

Molempien verkkojen hallinnointi on perusteltu syy pitää molemmat protokollat. Tavallinen ratkaisu päättää WireGuardin ja IPsecin erillisillä liitynnöillä tai erillisillä yhdyskäytävillä. Hyväksytty liikenne reititetään sitten niiden välillä.

Tämä ratkaisu tuo luottamuksen ja valtuutuksen rajan, ja se pitäisi kirjata sellaisena. Mitkä vertaispisteet saavat ylittää, mihin suuntaan ja kenen käytännön alla, on reititys- ja palomuuripäätös. Kumpikaan protokolla ei tarjoa sitä.

Se, mitä se ei ole, on läpinäkyvä muunnos. WireGuardin kautta saapuva liikenne luodaan uudelleen IPsec-tunneliin, ja jokainen välissä oleva käytäntö koskee sitä.

Selvitä ensin palvelimen protokolla- ja todennusvaatimukset. Käytä sitten asiakasohjelmaa ja rekisteröintipolkua, jota operaattori tukee, ja pidä yksityiset avaimet poissa verkkopohjaisista muuntimista sen tapahtuessa.