strongSwan ESP-in-UDP: kun havaittavaa NAT:ia ei ole

NAT-tunnistus löytää osoitteiden käännöksen, ei palomuurikäytäntöä. Sivustoyhteys ilman NAT:ia voi silti vaatia nimenomaisen ESP-in-UDP-valinnan.

NAT-tunnistus vastaa yhteen kysymykseen: ovatko osoitteet tai portit muuttuneet matkan varrella? Se ei vastaa, salliiko palomuuri IP-protokollan 50. Sivuston yhdyskäytävät, joissa ei ole lainkaan käännöstä, voivat silti olla käytännön takana, joka pudottaa native ESP:n, ja tämä vaatimus on määritettävä eikä havaittava. Mekanismi on ESP-in-UDP, ja se on päätös, ei itsestään ilmestyvä varavaihtoehto.

Tunnistus on osoitteiden aritmetiikkaa, ei palomuurin luotaus

IKEv2 kuljettaa NAT-tunnistuksen hyötykuormia jotka sisältävät lähde- ja kohdeosoitteiden sekä -porttien tiivisteet. Kumpikin osapuoli vertaa vastaanottamaansa siihen, mitä se näkee paikallisesti, ja eroavuus kertoo sille, että jokin on kääntänyt paketin. Mikään siinä vaihdossa ei testaa, välittääkö välissä oleva reititin protokollaa 50.

Käytännön seuraus kannattaa sanoa suoraan. Natiivi ESP -tunneli, joka toimi, ei löydä uutta rajoittavaa palomuuria itsestään, ja sen seuraava yritys epäonnistuu datavaiheessa, kun IKE onnistuu edelleen. Näet muodostetut IKE-turva-assosiaatiot ja ei suojattua liikennettä, mikä näyttää reititysviirheeltä, kunnes kaappaat liikenteen johdosta.

Kapselointi on siis määritettävän yhteyden ominaisuus, ei tulos, josta osapuolet neuvottelevat verkon käyttäytymisen perusteella.

Miten encap muuttaa vaihtoa

Nykyaikaisessa strongSwan-asennuksessa, jota hallitaan swanctl.conf kautta, yhteyden asetus encap = yes vaikuttaa NAT-tunnistusvaihtoon niin, että molemmat osapuolet käyttävät UDP-kapselointia ESP:lle. Suojatut paketit kulkevat sitten UDP:n sisällä, tavallisesti portissa 4500, ja molempien päiden on sovittava tästä järjestelystä.

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

Tuo katkelma kuuluu oikean yhteyden määritelmän sisään eikä ole täydellinen sivustoprofiili. Säilytä vertaisosoitteet, todennus ja child-liikenteen valitsimet, joita jo ajat; ainoa lisätty avain muuttaa sitä, miten suojatut tiedot kääritään, ei sitä, mitä ne suojaavat.

strongSwanin NAT-traversal-opas kuvaa tämän käyttäytymisen, mukaan lukien vuorovaikutus portin kellumisen kanssa, kun MOBIKE on käytössä.

Käytä asetusta, joka kuuluu taustajärjestelmääsi

strongSwanilla on kaksi määritystaustajärjestelmää, ja avain eroaa niiden välillä. swanctl.conf-yhteys ottaa encap, kun taas vanha ipsec.conf-yhteys forceencaps ottaa. Yhden taustajärjestelmän avainsanan laittaminen toiseen tuottaa määrityksen, joka latautuu valittamatta ja ei muuta mitään, mikä on pahempaa kuin virhe.

Tarkista, mikä daemon todella on käynnissä, ennen kuin muokkaat mitään. Monissa jakeluissa molemmat tiedostot ovat olemassa, koska toinen on jäänne aiemmasta siirtymästä, ja aktiivinen on se, jonka palveluyksikkö käynnistää. Lue se yksikkö sen sijaan, että arvaisit tiedostojen aikaleimoista. Viiden sekunnin tarkistus tässä säästää tunnit sellaisen asetuksen testaamisen, jota mikään ei ladannut.

Käytä muutos yhteyden omistajan kautta ja palauta assosiaatio valvotussa ikkunassa. Jo asennettu child säilyttää nykyisen kapselointinsa, kunnes se korvataan, joten pelkkä tiedoston muokkaus ei todista, että uusi järjestely on käytössä.

Vahvista käärityt tiedot, älä vain porttia

Kaappaa yhdyskäytävällä, kun suojattu liikenne virtaa, ja vertaa sitä sitten strongSwanin omaan näkymään:

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

Natiivi ESP näkyy IP-protokollana 50 eikä muistuta lainkaan UDP:tä. Käärity ESP näkyy UDP-datagrammeina portissa 4500, joiden hyötykuorma ei ole IKE. IKE-liikenne samassa portissa ei ole todiste kapseloinnista, koska MOBIKE voi siirtää IKE:n sinne, kun datapolku pysyy nativina, joten lue hyötykuorma, älä porttinumeroa.

Pidä mielessä myös polun MTU. Kääre lisää ylimääräistä kuormaa, ja polku, joka kuljetti natiivia ESP:tä, voi vaatia säätöjä, kun paketit kasvavat. Tarvittava ICMP-käsittely pitäisi jo olla osa suunnittelua; kapselointi ei poista tätä riippuvuutta.

Hyväksy muutos, kun tunnelin sisäinen uusi sovellusliikenne näkyy kaappauksessa käärittynä ESP:nä molemmissa päissä ja kun sisäinen palvelu ja sen paluureitti toimivat edelleen. Kaikki vähempi on määritys, joka näyttää tiedostossa oikealta.

Aiheeseen liittyvät artikkelit