Kuidas NAT-i läbimine pakib ESP UDP sisse

Kaks sama ruuteri taga olevat klienti räägivad ühe IPsec-lüüsiga, ja üks kukub pidevalt välja, samal ajal kui teine püsib. Päris ESP on IP-protokoll 50 ilma portideta, seega pole tõlkijal millelegi vastendust kinnitada, kui mitu klienti jagavad ühte aadressi. NAT-i läbimine sulgeb selle lünga, pakkides ESP 4500 juures UDP sisse, ja see päis selgitab enamikku järgnevaid sümptomeid. See osutab ka seadmele, mida tuleb muuta.

Miks andmetasand liigub pordile 4500

Seadistamise ajal võrdleb IKEv2 aadresse ja porte, mida kumbki pool arvab kasutavat, vahetades oma NAT-tuvastusteatistes räsiväärtusi. Kui räsiväärtused ei klapi, asub kusagil teel tõlkija, ja mõlemad pooled lülitavad kaitstud liikluse UDP-kapseldusele. Seetõttu näeb tõlkijaga kokku puutunud seanss teistsugune välja kui see, mis ei puutunud.

Ümbrik on ümbris, mitte protokolli muudatus: ESP säilitab oma päise, terviklikkuse kontrolli ja krüpteerimise, ja UDP annab ainult need pordid, mida tõlkija vajab. Port 500 kannab IKE-vahetust; 4500 kannab kapseldatud andmeid pärast tuvastust ja sageli ka hilisemaid IKE-sõnumeid. Kumbki port ei tee voogu TCP-ühenduseks, see on eeldus, mis eksitab enamikku inimesi, kes jäädvustust loevad.

Kontrollige kahte etappi järjekorras

Tõestage esmalt juhtimisvahetus, seejärel andmetee, ja hoidke neid märkmetes eraldi. Jäädvustus, mis näitab liiklust 500 juures ja mitte kunagi 4500 juures, tähendab tavaliselt, et andmetee on filtreeritud, seega kuulub parandus tulemüüri reeglisse, mitte kliendisse.

Jälgige mõlemat porti käsuga tcpdump -ni any 'udp port 500 or udp port 4500' ja lugege ruuteri tõlketabelit, kui seanss on aktiivne. See tabel näitab lähtepordi, mida lüüs tegelikult näeb, ja sülearvuti jäädvustus erineb selle kavatsuslikult: sülearvuti usub, et see on 500, samal ajal kui lüüs näeb tõlgitud lähtepordiga 4500, ja mõlemad on õiged. Sama voog enne ja pärast tõlkimist:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Sümptomid, mida ümbrik selgitab, ja kaks, mida see ei selgita

Ruuter, mis lubab juhtimisvahetust ja blokeerib kapseldatud andmed annab teate, et tunnel on püsti, aga midagi läbi ei lähe. Vastendustabelid aeguvad, seega vajab jõudeolev seanss hoiutrafiklit, mida pooled sihilikult saadavad, ja need paketid ei ole tervisekontrollid. Kui mitu klienti ühe lüüsi taga ebaõnnestuvad korraga, uurige selle lüüsi tõlget ja mis tahes vana läbilaskefunktsiooni. Ümbrik ei selgita rakendust, mis ebaõnnestub igal kliendil pärast tunneli püstipanekut, ega blokeerimislehe sertifikaadihoiatust; mõlemad asuvad sellest kihist kõrgemal.

Lugege vastendustabelit kahe kliendi jaoks korraga: kui mõlemad näitavad sama tõlgitud porti, ei eralda seade neid nii, nagu lüüs nõuab. Läbilaskerežiim, mis annab päris ESP ainult ühele hostile, ei ole samaväärne mitme tõlgitud kliendi teenindamisega, kuigi müüjad kirjeldavad mõlemat IPsec-sõbralikuna. Kahekordne NAT lisab vastenduskihi ja veel ühe aegumispunkti, kuid ei katkesta väljaminevaid ühendusi automaatselt.

Hoiutrafik väärib omaette rida halduskäsiraamatus, sest just see hoiab vastusetee jõudeperioodidel avatuna. Lubage see seal, kus müüja seda dokumenteerib, ja kontrollige seda esimesena, kui seanss sureb pärast mitut minutit vaikust, mitte esimesel kasutusel.

Muutke vastenduse omanikku ja testige uuesti

Järgige mõlemas pooles toetatud NAT-i läbimise seadeid, selle asemel et porti oletada. Kohaliku lähtepordi muutmine ühes kliendis ei saa muuta teenust, mis kuulab teises otsas, ja see rikub tavaliselt juba loodud vastenduse. Kui klient asub seadme taga, mida te ei kontrolli, kuulub muudatus selle omanikule.

Pärast igasugust muudatust korrake mõlemat etapikontrolli ja kinnitage, et andmepakett läbib, mitte ainult et olekuekraan muutus roheliseks. Hoidke korteežid, vastendustabeli väljund ja reeglimuudatus ühes märkmes, et järgmine inimene ei alustaks uuesti juhtimisvahetusest. strongSwan-i NAT-i läbimise märkmed hõlmavad kapseldamise ja hoiu seadeid mõlema etapi taga.