WireGuard-profyl foar in IPsec-gateway: wat jo ynstee freegje moatte

Handshake-time-outs by in stille gateway betsjutte meastentiids twa protokollen dy't elkaar nea treffe. In WireGuard-peer praat Noise wylst in IPsec-gateway op IKE wachtet. In korrekt adres en poarte feroarje dat net.

It wergebrûk fan it einpunt yn in profyl oerbrêget de beide net. De folgjende stap is in fersyk oan wa't de gateway beheart.

Fersyk ien: de protokolferzje

IPsec neamt in famylje en net ien inkele wurkstream. IKEv2 en IKEv1 ferskille yn har útwikselings, har ferifikaasje-opsjes en har gedrach by in netwurkferoaring. In gateway dy't allinnich IKEv1 beëinigt, sil hiel oars hannelje as ien dy't IKEv2 biedt. De kliïntkonfiguraasje ferskilt dêrmei.

Freegje hokker ferzje de tsjinst beëinigt en oft dy in standertbasearre ymplemintaasje of in leveransiersfariant mei eigen klient draait. Menu's fan bestjoeringssystemen ferbergje dat antwurd faak efter ien label. It label is net it protokol.

Fersyk twa: de ferifikaasjemetoade fan 'e klient

Ferifikaasje is dêr't it measte fan it echte wurk sit. De tsjinst ferwachtet miskien in masine-sertifikaat mei in bepaald útwreide kaaigebrûk, in brûkerssertifikaat, in EAP-metoade oer IKEv2 of in foarôf dielde kaai bûn oan in identiteit. Hokker jildt, beslút wat de klient nedich hat.

In WireGuard-privekaai is net ien fan dy dingen. It is in Curve25519-kaai dy't yn ien spesifike handshake brûkt wurdt. Gjin konverzje makket der in sertifikaat of EAP-legitimaasje fan. In ark dat oars beweart, neamt it bestân om of generearret iets dat der net mei te krijen hat.

De IKEv2-spesifikaasje yn RFC 7296 beskriuwt wat in ymplemintaasje fan dy ferzje stypje moat. It is in referinsje foar in ûndúdlik antwurd fan 'e operator, gjin gids foar kliïntkonfiguraasje.

Fersyk trije: de fertroude identiteit en de bestimmingen

Freegje om 'e identiteit fan 'e gateway sa't de klient dy sjen moat, plus it fertrouwensanker dat dy falidearret. Freegje dan hokker prive-berikken en resolvers de tsjinst stjoert. Dy twa antwurden beslute wat de tunnel eins ferfiert.

Sûnder dy kin in wurkjende ferbining de taak dochs misse. In tunnel dy't stiet sûnder stjoerde resolver lit ynterne nammen ûnbeantwurde. In ûntbrekkende ferkiersselektor lit de bestimming bûten de tunnel, sels as de handshake slagge is.

In probe fan it einpunt beantwurdet in oare fraach as de kliïntflater. In berikbere poarte sûnder assosjaasje wiist op ferifikaasje, wylst in ûnberikbere poarte op it paad wiist.

# 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

Fier dy probe út foardat jo eat yn 'e klient feroarje. As de poarten antwurdzje en de assosjaasje mislearret noch, is it probleem de legitimasjes of it belied. As se hielendal net antwurdzje, helpt gjin profylwiziging.

As beide protokollen njonken elkaar bestean moatte

It behearjen fan beide netwurken is in legitime reden om beide protokollen te hâlden. It wenstige ûntwerp beëinigt WireGuard en IPsec op aparte ynterfaces of aparte gateways. Goedkard ferkear wurdt dan tusken har routen.

Dat ûntwerp yntrodusearret in fertrouwens- en autorisaasjegrins, en dy moat as sadanich fêstlein wurde. Hokker peers oerstekke meie, yn hokker rjochting en ûnder waans belied is in routing- en firewallbeslút. Gjin fan beide protokollen leveret dat.

Wat it net is, is in transparante konverzje. Ferkear dat oer WireGuard oankomt, wurdt op 'e nij yn 'e IPsec-tunnel brocht, en elk belied dertusken jildt dêrfoar.

Klearje earst de protokol- en ferifikaasje-easken fan 'e server út. Brûk dan de klient en it ynskriuwpaad dat de operator stypjet, en hâld privekaaien bûten webkonverters wylst dat bart.