Miksi OpenVPN-reitti häviää strongSwan XFRM-käytännölle

Paketit voivat seurata OpenVPN-reittiä ja tulla silti IPsec-käytännön sieppaamiksi, ja tämä yhdistelmä näyttää reititysvialta joka kulmasta paitsi oikeasta. Linux ratkaisee reitin ja kysyy sitten erillistä tietoturvakäytäntöjen tietokantaa, joten tarkempi kohdereitti ei syrjäytä vastaavaa XFRM-käytäntöä. Näkyvä oire on liikenne, joka lähtee isännästä eikä koskaan saavu perille, kun molemmat tunnelit ilmoittautuvat terveiksi. Kolme vaihtoehtoa ratkaisee sen, ja valintasi riippuu siitä, kumman kahdesta polusta on tarkoitus kantaa tämä etuliite.

Kaksi päätöstä, ei yksi

Reitin valinta vastaa kapeaan kysymykseen: minkä seuraavan hypyn ja lähdeosoitteen pitäisi kantaa tämä paketti. Tietoturvakäytäntöjen tietokanta vastaa toiseen: vaatiiko tämä paketti IPsec-suojausta ja minkä valitsimien alla. Molemmat ajetaan samalle paketille, ja ensimmäisen täyttäminen ei kerro toisesta mitään. Siksi metriikan muuttaminen tai staattisen reitin lisääminen voi jättää oireen ennalleen.

Laaja IPsec-valitsin on tavallinen syy. Käytäntö, joka suojaa 172.16.0.0/12, kattaa myös 172.20.8.0/24:n, jonne ylläpitäjä saattaa aikoa päästä OpenVPN-tunnelin kautta. Aie on olemassa vain reititystaulussa, eikä käytäntötietokanta koskaan saanut siitä tietoa.

Käsittele sitä kahden määritetyn suojapolun välisenä ristiriitana, älä kahden metriikan kilpailuna. Korjaus kuuluu sille komponentille, joka määritettiin väärällä laajuudella.

Lue reitti, jonka ydin todella valitsee

Aloita hausta, jonka ydin tekee, mukaan lukien lähdeosoite ja mikä tahansa käytäntösääntö, joka voisi ohjata sen toiseen tauluun. Päätaulun reittiä ei ehkä koskaan tarkastella, jos aikaisempi sääntö valitsee toisen taulun, ja pisimmän etuliitteen täsmäytys pätee vain sen taulun sisällä, jonka sääntö valitsee.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Viimeinen komento on ratkaiseva, koska se tulostaa valitun reitin yhdessä sen lähdeosoitteen kanssa, jota ydin käyttäisi. Vertaa tätä tulostetta valitsimeen, johon IPsec-käytäntö osuu. Kun reitti osoittaa OpenVPN-rajapintaan ja käytäntö osuu edelleen samaan pariin, olet toistanut ristiriidan arvaamatta.

Pidä vedokset vapaina asiaankuulumattomista osoitteista ennen kuin ne päätyvät tikettiin. Tuotantoisännän reititystaulu kantaa sisäistä topologiaa, ja vain kysymykseen vastaavat rivit kannattaa liittää.

Lue myös käytäntö, joka pätee

Käytäntöluettelo näyttää suunnan, valitsimet ja mallin, joka päättää, mitä vastaavalle paketille tapahtuu. Lue ensin lähtevä suunta ja sitten tuleva puoli paluuliikenteelle, koska yksisuuntainen poikkeus tuottaa yhteyden, joka alkaa eikä koskaan valmistu.

ip -s xfrm policy
swanctl --list-sas

Vertaa luettelon valitsimia etuliitteisiin, joista yhteys neuvotteli. strongSwanin reittiasennuksen poistaminen käytöstä ei poista näitä käytäntöjä, eikä metriikan muuttaminen muuta sitä, mitä lähde-kohdeparia käytäntö suojaa. Nämä kaksi näennäiskorjausta kannattaa sulkea pois varhain, koska niitä ihmiset kokeilevat ensin.

Jos luettelo ei sisällä käytäntöä odotetulle etuliitteelle, ongelma on muualla ja reititystaulu kertoo todennäköisesti totuuden. Jos se sisältää laajemman käytännön, joka kattaa etuliitteen, olet löytänyt sieppauksen.

Kolme vaihtoehtoa, kun molemmat polut ovat laillisia

IPsec-valitsimen kaventaminen on puhtain vaihtoehto, kun laaja etuliite oli mukavuus eikä vaatimus. Kaukovalitsimen supistaminen aliverkkoihin, jotka todella kuuluvat IPsecin taakse, poistaa ristiriidan kaikilta isänniltä kerralla, ja se maksaa avainten uudelleenneuvottelun, ei uutta komponenttia.

Läpipääsypoikkeus on kirurginen vaihtoehto, kun laajan valitsimen on jäätävä. strongSwan tukee erillistä yhteyttä, jonka child käyttää pass-tilaa, mikä kertoo ytimelle, että vastaavaa liikennettä ei saa käsitellä IPsecissä. Loopback-kauko-osoite estää tämän yhteyden valitsemisen saapuville vertaisille, ja valitsimien on kuvattava todellinen valtuutettu pari eikä kaikkea.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

strongSwanin kokoonpanoesimerkit dokumentoivat tämän käytäntötyypin ja loopback-vertaisen käytännön. Kolmas vaihtoehto on reititykseen perustuva suunnittelu XFRM-rajapinnoilla, joka sitoo käytännön nimetyn rajapinnan kautta reititettyyn liikenteeseen globaalin valitsimen sijaan. Se on migraatio, ei hienosäätö, ja liikenteen on silti täytettävä neuvotellut valitsimet.

Todista poikkeus heikentämättä muuta

Kun muutos on ladattu, testaa poikkeus ja tavallinen kohde, jonka on pysyttävä suojattuna. Tarkista molemmat suunnat, pudota sitten OpenVPN-tunneli ja varmista, mitä poikkeukselle kuuluvalle liikenteelle tapahtuu. Poikkeus, joka lähettää etuliitteen hiljaa salaamattomana, kun tunneli on alhaalla, on käytäntöpäätös, joka sinun on tehtävä tarkoituksella, ei löydettävä kesken häiriön.

Kirjaa, mikä etuliite käyttää mitä polkua ja miksi. Muuten seuraava insinööri, joka näkee laajan valitsimen, avaa saman tutkinnan uudelleen, ja vastaus on commit-viestissä, jota kukaan ei lue.