strongSwanin trap-tila: miksi IPsec-tunneli odottaa liikennettä
Jouten oleva on-demand IPsec-tunneli ei näytä CHILD SA:ta ennen kuin paketti vastaa sen trap-käytäntöä. Lue tila, tarkista liipaisin ja tiedä, milloin start sopii.
Tilarivillä ei näy CHILD SA:ta, tunneli näyttää kuolleelta, ja sitten ping kaukaiseen aliverkkoon nostaa sen. On-demand IPsec -asennuksessa tämä järjestys on suunnittelua, ei vika. Trap-käytäntö asentaa valitsimen ja odottaa, ja ensimmäinen sitä vastaava paketti käynnistää IKE:n ja CHILD SA -neuvottelun.
Osa sekaannuksesta on sanastoa: “up” tarkoittaa kahta eri tilaa. Kokoonpano on ladattu ja kernel-käytäntö on olemassa, mutta data-assosiaatio ei. Monitori, joka laskee vain aktiiviset SA:t, raportoi terveen kohteen alhaiseksi niin kauan kuin kukaan ei lähetä sille liikennettä.
Jouten olevalla on-demand-tunnelilla ei ole CHILD SA:ta näytettäväksi
Trap-merkintä ei itsessään todenna mitään. Se pyytää kerneliä pitämään käytännön valitulle liikenteelle ja nostamaan acquisitionin, kun paketti tarvitsee tätä käytäntöä. Daemon vastaanottaa acquisitionin, sovittaa sen child-määritelmään ja neuvottelee siitä eteenpäin. Siihen asti näytettävää IKE SA:takaan ei ole, minkä vuoksi molemmat listat voivat olla tyhjiä yhtä aikaa.
Juuri tämä järjestys tekee lokeista luettavia. Ensin tulee acquisition, sitten IKE_SA_INIT ja IKE_AUTH, sitten CHILD SA. Jos loki päättyy heti acquisitionin jälkeen, liipaisin toimi. Neuvottelu epäonnistui, ja seuraava kysymys koskee tunnistetietoja, ehdotuksia tai tavoitettavuutta, ei trappia.
Linux-kernel-taustalla näet käytännön ennen kuin yhtään SA:ta on olemassa. Suorita ip xfrm policy ja etsi valitsin, jonka suunta on out ja jonka malline osoittaa yhteyteen. Se merkintä on on-demand-tila, ja sen olemassaolo on ensimmäinen vahvistettava asia.
start_action päättää, odottaako ylipäätään mikään
Jokainen child tiedostossa swanctl.conf kantaa start_action. start käynnistyy, kun kokoonpano ladataan, trap asentaa käytännön ja odottaa, ja none jättää käynnistämisen jollekin muulle. Vain trap tuottaa yllä kuvatun ping-ja-se-nousee-käyttäytymisen.
children {
office-lan {
local_ts = 192.168.50.0/24
remote_ts = 192.168.70.0/24
start_action = trap
}
}
Kaksi liikennevalitsinta määrittävät, mikä lasketaan kiinnostavaksi, eikä näiden etuliitteiden ulkopuolisen isännän paketti laukaise trappia; se reitittyy tavalliseen tapaan. Valitsimien leventäminen liipaisimen innostamiseksi leventää myös aluetta, jonka tunneli väittää suojaavansa, joten johda ne liikenteestä, jonka todella aiot salata.
Viite swanctl.conf luettelee hyväksytyt arvot sekä erilliset close- ja DPD-toiminnot, jotka ohjaavat sitä, mitä tapahtuu, kun SA on olemassa.
Selvitä, laukesiko liipaisin ylipäätään
Aloita komennolla swanctl --list-conns ja varmista, että child on ladattu aiottulla toiminnolla. Lähetä sitten yksi paketti isännästä, jonka osoite on local_ts ja vastaanottaja remote_ts, ja seuraa swanctl --list-sas. Jos tuloste ei muutu, mikään acquisition ei saavuttanut daemonia.
Kaksi tavallista syytä hiljaiseen trappiin: paketti lähde-NATattiin ennen kuin se osui käytäntöön eikä enää vastaa osoitetta local_ts, tai yhteys ei koskaan latautunut syntaksi- tai tunnistetietovirheen vuoksi. Suorita uudelleen swanctl --load-all ja lue sen tuloste ennen kuin kosket valitsimiin. Yhteys, joka ei latautunut, ei asenna käytäntöä, joten liikenteellä ei ole mitään laukaistavaa.
Suunnalla on myös väliä: lähtevälle liikenteelle asennettu trap ei käynnisty saapuvasta paketista. Jos kauko-osapuolen pitää nostaa tunneli, se tarvitsee oman trappinsa, tai tämä puoli tarvitsee start.
Ensimmäisen paketin odottaminen ei ole aina oikea vaihtokauppa
Interaktiiviset istunnot huomaavat asennuskustannuksen. Ensimmäinen pyyntö maksaa IKE-vaihdon ja CHILD-neuvottelun, ja lyhyen määräajan asiakas voi luovuttaa ennen kuin SA on olemassa. Proaktiivinen start poistaa tuon ensimmäisen paketin viiveen. Mutta se pitää tunnelia ylhäällä liikenteelle, joka ei ehkä koskaan saavu.
Kolme tosiasiaa ratkaisevat valinnan: kuinka usein polkua käytetään, onko ensimmäisellä pyynnöllä tiukka määräaika ja onko vastapuoli tavoitettavissa käynnistyksessä. Satunnainen eräliikenne ja käynnistyksessä mahdollisesti offline oleva vastapuoli molemmat puoltavat trap. Latenssille herkkä asiakas ja aina tavoitettavissa oleva vastapuoli puoltavat start. Jos molemmat puolet voivat käynnistää, sopikaa, kumpi omistaa liipaisimen, jotta ette saa päällekkäisiä neuvotteluja.
Asennettu käytäntö ei sekään ole vuotovarma tae. Jos vaatimus on fail-closed, palomuurin on pudotettava liikenne, jolla ei ole SA:ta, ja se sääntö elää child-määritelmän ulkopuolella.
Kirjoita kolme riviä, jotka lopettavat seuraavan väittelyn
Kirjoita valitsimet, käynnistystoiminto ja komennon tuloste, joka näyttää käytännön olevan olemassa ilman SA:ta. Ne kolme riviä erottavat tilan “on demand ja jouten” tilasta “ei lataudu”, kun joku seuraavan kerran raportoi tunnelin alhaiseksi. Niiden tallentaminen vie minuutin. Ilman niitä sama tutkinta alkaa nollasta.
Testaa isännästä, joka on todella valitsimen sisällä. Ping reitittimestä itsestään kulkee usein eri polkua eikä todista mitään käytännöstä, joka suojaa sen takana olevaa aliverkkoa.