Divi klienti aiz viena maršrutētāja sazinās ar vienu IPsec vārteju, un viens pastāvīgi atkrīt, kamēr otrs paliek savienots. Vietējais ESP ir IP protokols 50 bez portiem, tāpēc tulkotājam nav kam piesaistīt kartējumu, kad vairāki klienti dala vienu adresi. NAT šķērsošana aizpilda šo robu, iesaiņojot ESP UDP 4500 portā, un šī galvene izskaidro lielāko daļu turpmāko simptomu. Tā arī norāda ierīci, kas jāmaina.

Kāpēc datu plakne pārvietojas uz 4500 portu

Iestatīšanas laikā IKEv2 salīdzina adreses un portus, ko katra puse uzskata, ka izmanto, apmainoties ar jaucējkodiem savos NAT noteikšanas paziņojumos. Ja jaucējkodi nesakrīt, kaut kur ceļā sēž tulkotājs, un abas puses pārslēdz aizsargāto trafiku uz UDP iekapsulēšanu. Tāpēc sesija, kas saskārās ar tulkotāju, izskatās citādi nekā tā, kas nesaskārās.

Ietinums ir aploksne, nevis protokola maiņa: ESP saglabā savu galveni, integritātes pārbaudi un šifrēšanu, un UDP nodrošina tikai tos portus, kas tulkotājam nepieciešami. 500 ports pārvadā IKE apmaiņu; 4500 pārvadā iekapsulētos datus pēc noteikšanas, un bieži arī vēlākos IKE ziņojumus. Neviens no portiem nepadara plūsmu par TCP savienojumu, un šis pieņēmums maldina lielāko daļu cilvēku, kas lasa ierakstu.

Pārbaudiet abus posmus pēc kārtas

Vispirms pierādiet vadības apmaiņu, pēc tam datu ceļu, un turiet abus atsevišķi savās piezīmēs. Ieraksts, kas rāda trafiku 500 portā un nekad 4500, parasti nozīmē, ka datu ceļš tiek filtrēts, tāpēc labojums pieder ugunsmūra noteikumam, nevis klientam.

Novērojiet abus portus ar tcpdump -ni any 'udp port 500 or udp port 4500', un lasiet maršrutētāja tulkošanas tabulu, kamēr sesija ir aktīva. Šī tabula rāda avota portu, ko vārteja patiešām redzēs, un ieraksts portatīvajā datorā apzināti nesakrīt: portatīvais uzskata, ka ir 500, kamēr vārteja redz 4500 ar pārtulkotu avota portu, un abi ir pareizi. Tā pati plūsma pirms un pēc tulkošanas:

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

Simptomi, ko ietinums izskaidro, un divi, ko ne

Maršrutētājs, kas atļauj vadības apmaiņu un bloķē iekapsulētos datus rada ziņojumu „tunelis ir uzcelts, bet nekas neiet cauri“. Kartēšanas tabulas beidzas, tāpēc neaktīvai sesijai nepieciešams uzturēšanas trafiks, ko puses apzināti sūta, un šie paketes nav veselības pārbaudes. Ja vairāki klienti aiz vienas vārtejas neizdodas vienlaikus, izpētiet šīs vārtejas tulkojumu un jebkuru veco caurejas funkciju. Ietinums neizskaidro lietojumprogrammu, kas neizdodas katram klientam pēc tuneļa uzcelšanas, nedz arī sertifikāta brīdinājumu bloķēšanas lapā; abi atrodas virs šī slāņa.

Lasiet kartēšanas tabulu diviem klientiem vienlaikus: ja abi rāda to pašu pārtulkoto portu, ierīce tos neatdala tā, kā prasa vārteja. Caurejas režīms, kas vietējo ESP dod tikai vienam resursdatoram, nav līdzvērtīgs vairāku pārtulkotu klientu apkalpošanai, lai gan ražotāji abus raksturo kā IPsec draudzīgus. Dubultais NAT pievieno kartēšanas slāni un vēl vienu beigu punktu, bet tas automātiski nepārtrauc izejošos savienojumus.

Uzturēšanas trafiks ir pelnījis savu rindu ekspluatācijas rokasgrāmatā, jo tieši tas notur atbildes ceļu atvērtu dīkstāves periodos. Iespējojiet to tur, kur ražotājs to dokumentē, un pārbaudiet to vispirms, kad sesija mirst pēc dažām minūtēm klusuma, nevis pirmajā lietošanas reizē.

Mainiet kartējuma īpašnieku, pēc tam pārbaudiet vēlreiz

Ievērojiet abās pusēs atbalstītos NAT šķērsošanas iestatījumus, nevis miniet portu. Vietējā avota porta rediģēšana vienā klientā nevar mainīt pakalpojumu, kas klausās otrā galā, un tas parasti salauž jau izveidoto kartējumu. Ja klients atrodas aiz ierīces, kuru jūs nekontrolējat, izmaiņa pieder tās īpašniekam.

Pēc jebkuras izmaiņas atkārtojiet abas posmu pārbaudes un apstipriniet, ka datu pakete iet cauri, nevis tikai to, ka statusa ekrāns kļuva zaļš. Turiet kortežus, kartēšanas tabulas izvadi un noteikuma izmaiņu vienā piezīmē, lai nākamais cilvēks nesāktu no jauna no vadības apmaiņas. strongSwan piezīmes par NAT šķērsošanu aptver iekapsulēšanas un uzturēšanas iestatījumus aiz abiem posmiem.

Saistītie raksti