Täystunneli strongSwanissa vaatii 0.0.0.0/0:n molemmilla puolilla

strongSwan-yhteys, joka toimii yhdelle yksityiselle aliverkolle, ei välitä internettiliikennettä vain siksi, että joku muokkasi yhtä riviä. Täystunneli on kahden osapuolen sopimus siitä, mitä osoitteita child SA suojaa, ja kumpikin osapuoli nimeää toisen osapuolen suhteessa itseensä. Tee toinen puoli oikein ja toinen väärin, niin child SA joko ei nouse tai nousee aiottua kapeampana. Alla olevat viisi tarkistusta seuraavat tätä sopimusta asiakkaasta yhdyskäytävän kautta internettiin.

Tarkista ensin asiakkaan valitsin

Asiakas kuvaa sen, mitä haluaa suojata kaukokentällä, muodossa remote_ts, ja kaikki mitä se lähettää, tulee sen omasta osoitteesta. Internettiliikenteessä arvon on katettava kohteet, joihin käyttäjä todella pääsee, mikä tarkoittaa käytännössä koko IPv4-avaruutta. Asiakas, joka edelleen listaa yhden aliverkon, pyytää jaettua tunnelia, mitä profiilia käyttöliittymässä kutsutaankin. Lähdepuoli on yleensä dynamic, koska osoite annetaan yhteyden muodostuksen yhteydessä. Sinne kirjoitettu kiinteä lähde rikkoutuu heti, kun osoitejoukko muuttuu.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Katkelma ei ole täydellinen yhteystiedosto, ja tämä olettaa, että todennus, identiteetit ja virtuaaliosoitteiden joukko on jo määritetty. Asiakkaan lähdevalitsimen ja palvelimen antaman osoitteen on edelleen vastattava toisiaan, tai child SA nousee laajuudella, jota kumpikaan puoli ei odottanut. Lataa se komennolla swanctl --load-all ja lue tuloste ennen kuin oletat onnistumista. Tiedosto, joka jäsennetään, voidaan silti hylätä valitsimen vuoksi, joka ei mene päällekkäin toisen osapuolen ehdotuksen kanssa.

Tarkista yhdyskäytävän valitsin sen omalla puolella

Yhdyskäytävä lukee saman käsitteen vastakkaisesta suunnasta. Internettikohteet ovat yhdyskäytävälle paikallisia, joten sen local_ts on laaja ja remote_ts kuvaa asiakasjoukkoa. Tämä käänteisyys on yleisin virhe täystunnelin määrityksessä, ja se selviää tarkistuksesta, koska molemmat rivit näyttävät erikseen uskottavilta.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Asiakaskatkelman kopioiminen yhdyskäytävän tiedostoon tuottaa valitsinparin, joka ei kuvaa mitään hyödyllistä, koska molemmat puolet vaatisivat saman roolin. strongSwanin edelleenlähetysopas dokumentoi asiakkaan ja yhdyskäytävän parituksen nimenomaisesti, ja se kannattaa lukea yhteystiedoston vieressä eikä vasta epäonnistumisen jälkeen. Yhdyskäytävän tiedosto tarvitsee myös sen osoitejoukon määritelmän, johon remote_ts viittaa. Valitsin, joka nimeää olemattoman osoitejoukon, latautuu valittamatta ja epäonnistuu yhdistettäessä.

Vanha ipsec.conf käyttää vasenta ja oikeaa roolia eri avaimilla, eikä rightsubnet-rivi ole suora korvaaja swanctl-arvolle. Pidä kaksi syntaksia eri tiedostoissa sen sijaan, että liittäisit toisen toiseen. Niiden sekoittaminen samaan hakemistoon on tapa, jolla toimiva yhteys palaa hiljaa uudelleenkäynnistyksen jälkeen.

Tarkista neuvoteltu child SA, älä tiedostoa

Tallennettu määritys todistaa aikomuksen eikä mitään muuta. Toinen osapuoli voi kaventaa pyydettyä, eikä olemassa olevaa child SA:ta korvata vain siksi, että sen alla oleva tiedosto on muuttunut. Vahvista, mikä on todella asennettu, ennen kuin muutat mitään muuta.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Ensimmäinen komento näyttää, mitä daemon latasi, toinen näyttää muodostetut child SA:t ja kolmas ne käytännöt, joita ydin soveltaa. Jos tiedosto sanoo 0.0.0.0/0 ja listaus näyttää yhden aliverkon, neuvottelu kavensi laajuutta, eikä tiedoston uudelleenlukeminen selitä sitä. Lopeta child, käynnistä se uudelleen ja vertaa kaikkia kolmea tulostetta uudestaan. Child, joka palaa samalla kapealla laajuudella, on kavennettu kaukokentän eikä paikallisen tiedoston toimesta, ja se on keskustelu toisen ylläpitäjän kanssa paikallisen muutoksen sijaan.

Lue molemmat suunnat käytäntölistauksesta, koska tunneli, joka asentaa yhden suunnan eikä toista, on reititysongelma määrityksen asussa. Eteen- ja taaksepäin käytäntöjen tulee nimetä sama valitsinpari peilikuvana, ja puuttuva peili on vika daemonissa tai ehdotuksessa eikä valitsimen tekstissä.

Tarkista edelleenlähetys ja paluureitti

Valitsin päästää liikenteen yhdyskäytävälle; se ei saa yhdyskäytävää reitittämään liikennettä eteenpäin. Edelleenlähetys on otettava käyttöön, palomuurin on sallittava virtaus ja vastauksen on löydettävä tie takaisin asiakasjoukkoon. Nämä ovat kolme erillistä vaatimusta, ja jokainen epäonnistuu eri oireella. Puuttuva edelleenlähetyssääntö käyttäytyy kuin musta aukko, kun taas puuttuva paluureitti käyttäytyy kuin yksisuuntainen tunneli.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Yksityiset asiakasosoitteet tarvitsevat yleensä tarkoituksellisen lähdeosoitteen muunnoksen ennen kuin ne voivat lähteä julkisesta rajapinnasta, kun taas eksplisiittisesti reititetty varaus vaatii erilaista käsittelyä. Jos NAT on mukana, säilytä toteutuksen tukemat poikkeukset, jotta liikenne, jonka tietoturvakäytännön pitäisi tarkastaa, ei ohita sitä muunnettuna. Toisesta yhdyskäytävästä kopioitu laaja masquerade-sääntö muuttaa paljon useampia virtauksia kuin sen kirjoittaja tarkoitti. Kirjoita sääntö vain asiakasjoukolle ja jätä kommentti siitä, miksi se on olemassa.

Vahvista asiakkaassa ne reitit, jotka backend asensi, älä niitä, joita oletit. Hallinta, jonka reittien asennus on pois päältä, tarvitsee käsin ylläpidettävän reitityssuunnitelman, ja sitä suunnitelmaa on päivitettävä aina, kun tunneli muuttuu. Tarkista reititystaulu uudelleenyhdistämisen jälkeen, ei vain tuoreen käynnistyksen jälkeen.

Tarkista, mitä tunneli ei vieläkään kata

Valitsinpari kattaa IPv4:n eikä mitään muuta. IPv6, DNS ja mikä tahansa sovellustason käytäntö ovat erillisiä päätöksiä, jotka laaja IPv4-valitsin jättää hiljaa huomiotta. Tunneli, joka kuljettaa jokaisen IPv4-paketin, voi silti vuotaa jokaisen nimihaun.

Ilmoita aiottu DNS-polku nimenomaisesti, koska täystunneli, joka yhä ratkaisee nimiä paikallisen resolverin kautta, vuotaa kyselyt tunnelin ulkopuolelle ja rikkoo yksityiset nimet. Jos asiakkaalle annetaan IPv6-osoite, tuo osoiteperhe tarvitsee saman kohtelun, tai isäntä suosii polkua, jota tunneli ei suojaa. Testaa nimellä, johon vain yksityinen puoli voi vastata, ja käsittele julkinen vastaus vuotona.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Vahvista ketju noilla kahdella komennolla sekä yllä olevan listauksen neuvotelluilla valitsimilla. Jos traceroute näyttää paikallisen reitittimen ensimmäisenä hyppynä, liikenne ei käytä tunnelia, mitä valitsimet väittävätkään. Internet-yhteys on täydellinen vasta, kun valittu liikenne päästetään sisään, välitetään eteenpäin ja palautetaan suunnitellun yhdyskäytävän kautta. 0.0.0.0/0:n löytäminen profiilista on tuon ketjun alku eikä sen todiste.