„WireGuard“ profilis IPsec tinklų sietuvui: ko verčiau prašyti

Rankos paspaudimo laiko limitai su tyliu tinklų sietuvu paprastai reiškia du protokolus, kurie niekada nesusitinka. „WireGuard“ partneris kalba „Noise“, o IPsec tinklų sietuvas laukia IKE. Teisingas adresas ir prievadas to nekeičia.

Galutinio taško pakartotinis naudojimas profilyje nesujungia abiejų. Kitas žingsnis – prašymas tam, kas valdo tinklų sietuvą.

Pirmasis prašymas: protokolo versija

IPsec įvardija šeimą, o ne vieną darbo eigą. IKEv2 ir IKEv1 skiriasi savo mainais, autentifikavimo parinktimis ir elgsena keičiantis tinklui. Tinklų sietuvas, kuris baigia tik IKEv1, elgsis visiškai kitaip nei tas, kuris siūlo IKEv2. Kliento konfigūracija keičiasi kartu.

Paklauskite, kurią versiją baigia paslauga ir ar ji vykdo standartais pagrįstą įgyvendinimą, ar tiekėjo variantą su savo klientu. Operacinės sistemos meniu dažnai paslepia šį atsakymą už vienos etiketės. Etiketė nėra protokolas.

Antrasis prašymas: kliento autentifikavimo metodas

Autentifikavimas yra vieta, kurioje slypi didžioji dalis tikro darbo. Paslauga gali tikėtis mašinos sertifikato su tam tikru išplėstiniu rakto naudojimu, naudotojo sertifikato, EAP metodo per IKEv2 arba su tapatybe susieto iš anksto bendro rakto. Kuris taikomas, nulemia, ko klientui reikia.

„WireGuard“ privatusis raktas nėra nieko iš to. Tai Curve25519 raktas, naudojamas viename konkrečiame rankos paspaudime. Jokia konversija nepaverčia jo sertifikatu ar EAP kredencialais. Įrankis, kuris teigia priešingai, pervadina failą arba sukuria su tuo nesusijusį dalyką.

IKEv2 specifikacija RFC 7296 aprašo, ką turi palaikyti tos versijos įgyvendinimas. Tai nuoroda neaiškiam operatoriaus atsakymui, o ne kliento konfigūracijos vadovas.

Trečiasis prašymas: patikima tapatybė ir paskirties vietos

Paprašykite tinklų sietuvo tapatybės taip, kaip klientas turi ją matyti, kartu su ja patvirtinančiu pasitikėjimo inkaru. Tada paklauskite, kokius privačius diapazonus ir resolverius paslauga siunčia. Šie du atsakymai nulemia, ką tunelis iš tikrųjų perneša.

Be jų veikiantis ryšys vis tiek gali nepavykti atlikti užduoties. Tunelis, pakeltas be išsiųsto resolverio, palieka vidinius vardus neatsakytus. Trūkstamas srauto parinkiklis palieka paskirties vietą už tunelio, nors rankos paspaudimas pavyko.

Galutinio taško patikra atsako į kitą klausimą nei kliento klaida. Pasiekiamas prievadas be susiejimo rodo autentifikavimą, o nepasiekiamas prievadas – kelią.

# 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

Atlikite šią patikrą prieš ką nors keisdami kliente. Jei prievadai atsako, o susiejimas vis tiek nepavyksta, problema yra kredencialuose arba politikoje. Jei jie visai neatsako, jokia profilio pataisa nepadės.

Kai abu protokolai turi egzistuoti kartu

Abiejų tinklų administravimas yra teisėta priežastis palikti abu protokolus. Įprasta konstrukcija baigia „WireGuard“ ir IPsec atskiruose sąsajose arba atskiruose tinklų sietuvuose. Patvirtintas srautas tada maršrutizuojamas tarp jų.

Ši konstrukcija įveda pasitikėjimo ir įgaliojimo ribą, ir ją reikėtų taip užrašyti. Kurie partneriai gali pereiti, kuria kryptimi ir pagal kieno politiką – tai maršrutizavimo ir užkardos sprendimas. Nė vienas protokolas to nesuteikia.

Tai, kas tai nėra, yra skaidri konversija. Srautas, atvykstantis per „WireGuard“, iš naujo sukuriamas IPsec tunelyje, ir kiekviena tarpinė politika jam taikoma.

Pirmiausia išsiaiškinkite serverio protokolo ir autentifikavimo reikalavimus. Tada naudokite klientą ir registracijos kelią, kuriuos palaiko operatorius, ir tuo metu laikykite privačiuosius raktus atokiau nuo žiniatinklio keitiklių.