Miksi IPsec-tietoturvakäytäntö ei ole reititystaulun merkintä
Toimiva reitti ei todista mitään IPsecistä. Lue saman virtauksen reittihaku ja käytännön valitsimet ja vahvista sitten, että assosiaatio kattaa sen.
Pingaa 10.20.0.5 tunnelin läpi eikä mitään tule takaisin, vaikka reititystaulu väittää, että aliverkko on tavoitettavissa. Reititys ja IPsec vastaavat eri kysymyksiin, ja vain toinen niistä koskee tavoitettavuutta. Eteenpäin suuntautuva haku valitsee polun, sitten tietoturvakäytännön tietokanta päättää, onko polku suojattava, jätettävä rauhaan vai hylättävä. Kun kaksi ovat eri mieltä, paketti kuolee hiljaa, joten lue ne tässä järjestyksessä.
Aloita hausta, älä taulusta
Kysy ytimeltä, mitä se todella tekisi: ip route get 10.20.0.5 tulostaa valitun reitin, lähtevän liitännän ja lähdeosoitteen, jota se käyttäisi. Etuliite, käytäntösääntö, merkintä tai ensisijainen lähde voivat muuttaa vastausta, minkä vuoksi elävä haku voittaa taulun silmämääräisen lukemisen.
Testaa kohde suojatun alueen sisällä, älä yhdyskäytävän osoitetta. Vastakkaisen puolen yhdyskäytävään pääseminen todistaa vain, että jokin reitti on olemassa; se ei kerro mitään aliverkosta, jota todella tarvitset. Vahvista sitten, että haun valitsema liitäntä on se, jonka odotat tunnelin käyttävän.
Sovita valitsimet molemmilla puolilla
Käytäntötietokannalla on omat merkintänsä, ja jokainen nimeää suunnan, lähteen, kohteen ja protokollan ja kertoo sitten, mitä vastaaville paketeille pitää tehdä. Listaa ne komennolla ip xfrm policy; liput näyttävät, onko toiminto suojata, ohittaa vai estää. Käytäntö, jonka valitsimet ovat testivirtaustasi leveämmät tai kapeammat, ei vastaa sitä, ja paketti lähtee suojaamattomana. Se on se vika, jota etsit, ei puuttuva reitti.
Vertaa todellisia arvoja: lähde, kohde, protokolla ja portit. Jos haku ratkaisi yhden osoiteparin, kun käytäntömerkintä kattaa toisen, kaksi näkymää kuvaavat eri liikennettä. Aja molemmat uudelleen samalla monikolla ennen johtopäätöstä, muuten muokkaat käytäntöä, joka ei koskaan ollut polulla.
Käytäntöosuma ei ole asennettu tila
Vastaava käytäntö sanoo vain, että paketti on suojattava; ydin tarvitsee silti tietoturva-assosiaation suojauksen tekemiseen. Listaa ne komennolla ip xfrm state tai komennolla swanctl --list-sas, kun strongSwan neuvottelee, ja lue jokaisen merkinnän valitsimet ja laskurit.
Kun käytäntö vastaa eikä mikään assosiaatio kata samoja valitsimia, paketti pudotetaan sen sijaan, että se lähetettäisiin selkokielisenä. Se on se pudotus, jota pitää etsiä, kun tunneli on ylhäällä mutta yksi aliverkko ei toimi. Laskurit kertovat loput: assosiaatio, joka ei koskaan kasva, ei koskaan valittu, kun taas se, joka kasvaa ja päättyy silti pudotukseen, osoittaa etäpäähän. Valitsimien korjaaminen ja avainten uusiminen ovat eri korjauksia, joten päätä, kumman tarvitset, ennen kuin kosket asetuksia.
Mitä reittipohjainen tunneli yhä vaatii
XFRM-liitäntä saa tunnelin näyttämään laitteelta, johon voi reitittää, mikä on todella hyödyllistä. Se ei poista käytäntöä ja tilaa, jotka päättävät, mitä tapahtuu, kun paketti saapuu sinne. Reitti antaa seuraavan hypyn eikä mitään muuta.
Jos laite on olemassa ja reitti osoittaa siihen, mutta mikään assosiaatio ei vastaa sisäisiä valitsimia, paketti hylätään, eikä mikään määrä reittien muokkausta tuota avaimia tai valitsimia. Tarkista liitäntä samalla lähteellä ja kohteella, jonka reititit, ja vertaa sitä sitten tilaluetteloon.
Selvitä omistajuus ennen kuin muokkaat mitään
Isäntäkoneen palomuuri lisää kolmannen päätöksen, jota kumpikaan tietokanta ei tunne. Oikea reitti plus vastaava käytäntö plus asennettu assosiaatio voivat silti päättyä pudotettuun pakettiin, ja sovellus ilmoittaa vain aikakatkaisusta. Vahvista, että palomuuri sallii suojatun liikenteen, ennen kuin syytät IPseciä. Kaappaus tunnelilaitteella ja fyysisellä liitännällä näyttää, kummalla puolella salausta paketti katosi.
Asetusten omistajuus ratkaisee, selviääkö korjauksesi uudelleenkäynnistyksestä. Yksi komponentti voi asentaa tilaa, kun toinen hallitsee reittejä, ja toisen käsin tehty muokkaus ylikirjoitetaan seuraavan kerran, kun tunneli nousee. Muuta omistavaa asetusta ja lue sitten molemmat näkymät uudelleen; RFC 4301 pitää kaksi tietokantaa erillään, kun sinun on selitettävä jako jollekulle muulle.