strongSwan ESP-in-UDP: kapag walang NAT na matutuklasan

Ang tiktik ng NAT ay sumasagot sa isang tanong: nagbago ba ang mga address o port sa daan? Hindi nito sinasagot kung pinapayagan ng firewall ang IP protocol 50. Ang mga gateway ng site na walang anumang salin ay maaari pa ring nasa likod ng patakarang nagtatapon ng native ESP, at ang pangangailangang iyon ay dapat i-configure sa halip na matuklasan. Ang mekanismo ay ESP-in-UDP, at ito ay desisyon, hindi reserbang opsyon na kusang lumilitaw.

Ang tiktik ay aritmetika sa mga address, hindi pagsusuri ng firewall

Nagdadala ang IKEv2 ng mga payload ng tiktik ng NAT na may mga hash ng mga address at port ng pinagmulan at destinasyon. Inihahambing ng bawat panig ang natanggap sa nakikita nito nang lokal, at ang pagkakaiba ay nagsasabi nito na may nagsalin ng packet. Wala sa palitan na iyon ang sumusubok kung ipinapasa ng router sa gitna ang protocol 50.

Sulit sabihin nang tuwiran ang praktikal na bunga. Ang tunnel na gumana sa native ESP ay hindi kusang makakatuklas ng bagong mahigpit na firewall, at ang susunod na pagtatangka nito ay mabibigo sa yugto ng data habang nagpapatuloy ang tagumpay ng IKE. Makikita mo ang mga naitatag na IKE security association at walang protektadong trapiko, na mukhang sira sa routing hanggang makakuha ka ng capture sa kable.

Kaya ang encapsulation ay katangian ng koneksyong iyong kino-configure, hindi resultang pinagkasunduan ng mga peer mula sa pag-uugali ng network.

Paano binabago ng encap ang palitan

Sa makabagong deployment ng strongSwan na pinamamahalaan sa pamamagitan ng swanctl.conf, ang setting na encap = yes sa koneksyon ay nakakaapekto sa palitan ng tiktik ng NAT upang ang dalawang peer ay gumamit ng UDP encapsulation para sa ESP. Ang mga protektadong packet ay naglalakbay sa loob ng UDP, karaniwang sa port 4500, at dapat magkasundo ang dalawang dulo sa kaayusang iyon.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Ang bahaging iyon ay kabilang sa loob ng tunay na depinisyon ng koneksyon at hindi kumpletong profile ng site. Panatilihin ang mga address ng peer, authentication at child traffic selector na pinapatakbo mo na; ang nag-iisang idinagdag na key ay nagbabago kung paano binabalot ang protektadong data, hindi kung ano ang pinoprotektahan nito.

Inilalarawan ng gabay ng strongSwan sa NAT-traversal ang pag-uugaling ito, kasama ang interaksyon sa port floating kapag ginagamit ang MOBIKE.

Gamitin ang setting na kabilang sa iyong backend

May dalawang backend ng configuration ang strongSwan, at magkaiba ang key sa pagitan nila. Ang isang swanctl.conf koneksyon ay tumatanggap ng encap, samantalang ang lumang ipsec.conf koneksyon ay tumatanggap ng forceencaps. Ang ilagay ang keyword ng isang backend sa isa pa ay gumagawa ng configuration na naglo-load nang walang reklamo at walang binabago, na mas masama kaysa error.

Tingnan kung aling daemon ang talagang tumatakbo bago mag-edit ng anuman. Sa maraming distribusyon, umiiral ang dalawang file dahil ang isa ay labi ng naunang migrasyon, at ang aktibo ay ang sinisimulan ng service unit. Basahin ang unit na iyon sa halip na manghula mula sa mga timestamp ng file. Ang limang segundong pagsusuri dito ay pumipigil sa mga oras ng pagsubok sa setting na wala namang nag-load.

Ilapat ang pagbabago sa pamamagitan ng may-ari ng koneksyon at muling itatag ang association sa loob ng kontroladong window. Ang naka-install nang child ay pinapanatili ang kasalukuyang encapsulation hanggang mapalitan, kaya ang pag-edit ng file lamang ay hindi nagpapatunay na ginagamit ang bagong kaayusan.

I-verify ang nakabalot na data, hindi lamang ang port

Kumuha ng capture sa gateway habang dumadaloy ang protektadong trapiko, pagkatapos ay ihambing iyon sa sariling pananaw ng strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Lumilitaw ang native ESP bilang IP protocol 50 at hindi talaga kamukha ng UDP. Lumilitaw ang nakabalot na ESP bilang mga UDP datagram sa 4500 na ang payload ay hindi IKE. Ang trapikong IKE sa parehong port ay hindi patunay ng encapsulation, dahil maaaring ilipat ng MOBIKE ang IKE doon habang nananatiling native ang data path, kaya basahin ang payload, hindi ang numero ng port.

Isaalang-alang din ang MTU ng landas. Nagdaragdag ng overhead ang balot, at ang landas na nagdala ng native ESP ay maaaring mangailangan ng pagsasaayos kapag lumaki ang mga packet. Ang kinakailangang paghawak ng ICMP ay dapat bahagi na ng disenyo; hindi inaalis ng encapsulation ang dependency na iyon.

Tanggapin ang pagbabago kapag ang sariwang trapiko ng aplikasyon sa loob ng tunnel ay nakikita sa capture bilang nakabalot na ESP sa dalawang dulo, at kapag gumagana pa rin ang panloob na serbisyo at ang ruta ng pagbabalik nito. Anumang kulang dito ay configuration na mukhang tama sa isang file.