Profil WireGuard pentru un gateway IPsec: ce să ceri în schimb

Expirările handshake-ului cu un gateway tăcut înseamnă de obicei două protocoale care nu se întâlnesc niciodată. Un peer WireGuard vorbește Noise în timp ce un gateway IPsec așteaptă IKE. Adresa și portul corecte nu schimbă asta.

Reutilizarea endpoint-ului într-un profil nu le unește pe cele două. Următorul pas este o cerere către cel care administrează gateway-ul.

Prima cerere: versiunea protocolului

IPsec numește o familie, nu un singur flux de lucru. IKEv2 și IKEv1 diferă prin schimburile lor, opțiunile de autentificare și comportamentul la o schimbare de rețea. Un gateway care încheie doar IKEv1 se va comporta cu totul altfel decât unul care oferă IKEv2. Configurația clientului se schimbă odată cu el.

Întrebați ce versiune încheie serviciul și dacă rulează o implementare bazată pe standarde sau o variantă de furnizor cu propriul client. Meniurile sistemelor de operare ascund adesea acel răspuns în spatele unei singure etichete. Eticheta nu este protocolul.

A doua cerere: metoda de autentificare a clientului

Autentificarea este locul unde se află cea mai mare parte a muncii reale. Serviciul poate aștepta un certificat de mașină cu o anumită utilizare extinsă a cheii, un certificat de utilizator, o metodă EAP peste IKEv2 sau o cheie partajată în prealabil și legată de o identitate. Care se aplică decide de ce are nevoie clientul.

O cheie privată WireGuard nu este niciuna dintre acestea. Este o cheie Curve25519 folosită într-un singur handshake anume. Nicio conversie nu o transformă într-un certificat sau într-o acreditare EAP. Un instrument care susține contrariul redenumește fișierul sau generează ceva fără legătură.

Specificația IKEv2 din RFC 7296 descrie ce trebuie să accepte o implementare a acelei versiuni. Este o referință pentru un răspuns vag al operatorului, nu un ghid de configurare a clientului.

A treia cerere: identitatea de încredere și destinațiile

Cereți identitatea gateway-ului așa cum clientul trebuie să o vadă, plus ancora de încredere care o validează. Apoi întrebați ce intervale private și rezolvitoare trimite serviciul. Acele două răspunsuri decid ce transportă de fapt tunelul.

Fără ele, o conexiune funcțională poate totuși rata sarcina. Un tunel ridicat fără un rezolvitor trimis lasă numele interne fără răspuns. Un selector de trafic lipsă lasă destinația în afara tunelului, deși handshake-ul a reușit.

O sondare a endpoint-ului răspunde la o altă întrebare decât eroarea clientului. Un port accesibil fără asociere indică autentificarea, în timp ce un port inaccesibil indică calea.

# 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

Rulați acea sondare înainte de a schimba ceva în client. Dacă porturile răspund și asocierea tot eșuează, problema sunt acreditările sau politica. Dacă nu răspund deloc, nicio editare a profilului nu va ajuta.

Când ambele protocoale trebuie să coexiste

Administrarea ambelor rețele este un motiv legitim pentru a păstra ambele protocoale. Proiectarea obișnuită încheie WireGuard și IPsec pe interfețe separate sau gateway-uri separate. Traficul aprobat este apoi rutat între ele.

Această proiectare introduce o graniță de încredere și autorizare, și ar trebui consemnată ca atare. Care peer-uri pot trece, în ce direcție și sub politica cui este o decizie de rutare și firewall. Niciunul dintre protocoale nu o oferă.

Ceea ce nu este este o conversie transparentă. Traficul care sosește prin WireGuard este reoriginat în tunelul IPsec, iar fiecare politică dintre ele se aplică asupra lui.

Clarificați mai întâi cerințele serverului privind protocolul și autentificarea. Apoi folosiți clientul și calea de înregistrare pe care le acceptă operatorul, și țineți cheile private departe de convertoarele web în timp ce se întâmplă asta.