IPsec-käytäntö nielee paikallisen liikenteesi: miten sen tunnistaa

Pöydällä oleva tulostin lakkaa vastaamasta heti, kun tunneli nousee, eikä mikään tunnelin asetuksissa mainitse tulostinta. Yleensä on käynyt niin, että suojattu alue kirjoitettiin niin laajaksi, että se kattaa tulostimen, joten kone yrittää nyt salata liikennettä, jonka oli tarkoitus jäädä paikalliseen segmenttiin. Asennetun käytännön lukeminen selittää sieppauksen; sen rajaaminen oikeassa paikassa pitää etäliikenteen suojattuna. Matka epäonnistuneesta pyynnöstä vastaavaan käytäntöön kestää muutaman minuutin.

Seuraa virtausta ennen kuin muutat valitsinta

Aloita epäonnistuneesta pyynnöstä ja kirjoita neljä arvoa: lähdeosoite, jota kone käyttää, tarkka kohde, reitti, jonka ydin valitsee, ja käytäntö, joka vastaa tätä paria.

Nämä neljä tosiasiaa ratkaisevat, onko sieppaus tarkoituksellinen vai tahaton. Kohde, joka osuu etävalitsimen sisään, on suojattu suunnittelun mukaan, vaikka suunnittelu olisi ollut väärä. Kohde sen ulkopuolella, joka silti siepataan, tarkoittaa, että jokin muu täsmää, eikä valitsimen muuttaminen auta. Molemmat tapaukset ovat yleisiä, ja yksi komento erottaa ne.

Tee tämä ennen kuin muokkaat mitään, sillä kiinnostava tapaus on paikallinen aliverkko, joka menee päällekkäin yhteyden suojaaman yksityisen alueen kanssa. Tutut etuliitteet kuten 192.168.0.0/16 esiintyvät monissa verkoissa, ja yhdelle niistä kirjoitettu valitsin voi hiljaa kattaa omasi.

Kolme paikallisen lajia, jotka käyttäytyvät eri tavoin

Tälle isännälle osoitettu kohde, samassa linkissä oleva kohde ja toisen liitännän takana oleva kohde ovat kolme eri tapausta. Ydin kohtelee kutakin eri tavalla, kun se päättää, tarvitseeko liikenne suojausta.

Myöskään yhdyskäytävän itsensä tuottama liikenne ei ole sama asia kuin asiakkaalta välitetty liikenne. Käytäntö, joka näyttää oikealta välitetylle liikenteelle, voi siepata yhdyskäytävän oman hallintasession, ja niin ylläpitäjä menettää pääsyn samalla kun korjaa tunnelia.

Hyödyllinen tapa on nimetä tapaus ääneen: tuleeko tämä paketti minulta, meneekö se linkilleni vai kulkeeko se minun kauttani? Jokainen vastaus osoittaa eri paikkaan, jota voi rajata. Tapauksen kirjoittaminen estää myös seuraavaa henkilöä tekemästä samaa työtä uudelleen.

Kun suojattu alue on koko yksityinen tila, kaikki kolme tapausta voivat osua siihen kerralla, ja oireeksi tulee kone, joka ei tavoita mitään paitsi tunnelin päätepisteen.

Lue asennettu käytäntö, älä tiedostoa

Asetustiedostot kuvaavat aikomuksen; ydin pitää käytännöt, jotka todella täsmäävät. Näytä molemmat ja pidä eroa ensimmäisenä löydöksenä.

Nämä komennot näyttävät kohteelle valitun reitin ja asennetut käytännöt kumpaankin suuntaan:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Reitti kertoo, mitä liitäntää paketti käyttäisi. Käytäntöjen luettelo kertoo, sovelletaanko tähän pakettiin sitten mallia, ja yhteyksien luettelo näyttää, mitkä valitsimet daemon luulee asentaneensa. Jos kohde esiintyy etävalitsimessa, olet löytänyt sieppauksen arvaamatta.

Raja valitsinta tai ohita kohde

On kaksi tuettua korjausta, ja ne vastaavat eri kysymyksiin. Valitsimen rajaaminen sanoo, että tämä yhteys suojaa vain pienempää aluetta, mikä on oikein, kun laajempi alue oli virhe. Ohituksen lisääminen sanoo, että tätä tiettyä kohdetta ei saa koskaan suojata, mikä on oikein, kun suojattu alue on todella laaja ja yksi kohde on poikkeus.

Valitse ensimmäinen, kun voit, koska pienempää valitsinta on helpompi hahmottaa ja se näkyy yhteyden määritelmässä. Valitse toinen, kun laaja alue on tarkoituksellinen ja poikkeus on yksi isäntä tai aliverkko, jonka voit nimetä.

Molemmat kuuluvat siihen asetukseen, jolle yhteys kuuluu. Käsin lisätty ajonaikainen sääntö katoaa seuraavassa uudelleenyhdistämisessä, ja vika palaa hetkellä, jolloin kukaan ei enää muista kiertotietä.

Uudelleenasennuksen kestävät poikkeukset

Toista muutoksen jälkeen sama harmiton pyyntö ja katso samoja laskureita. Paikallisen kohteen pitäisi vastata, ja aiottu etäkohde näyttää edelleen salattua liikennettä.

Nämä kaksi tarkistusta vahvistavat, että poikkeus säilyi eikä suojaus:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Katkaise sitten tunneli tarkoituksella ja yhdistä uudelleen, ja toista molemmat. Poikkeus, joka toimii ennen uudelleenyhdistämistä ja epäonnistuu sen jälkeen, kohdistettiin väärälle kerrokselle, ja se on yleisin tapa, jolla tämä ongelma palaa.