Politiikkasääntö lähettää merkityt paketit omaan taulukkoon, ja tavallinen odotus on, että VPN-reitin katoaminen estää ne. Mekanismi tekee jotain muuta. Kun taulukossa ei ole vastaavaa reittiä, haku jatkuu seuraavaan sääntöön sen sijaan että pysähtyisi, ja taulukko main pitää yhä tavallisen oletusreitin uplinkille. Tuloksena on kokoonpano, joka näyttää fail-closedilta ja käyttäytyy fail-openina.

Mikään ei ole rikki; näin politikkoihin perustuva reititys on määritelty.

Haku jatkuu, kun taulukossa ei ole mitään

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Ota tuo sääntöjoukko: merkitty haku menee taulukkoon 42, ja myöhempi sääntö lähettää saman merkin taulukkoon nimeltä default. Niin kauan kuin taulukossa 42 on käyttökelpoinen oletusreitti, ensimmäinen haku antaa polun. Kun se reitti katoaa eikä mikään muu taulukossa 42 vastaa, hausta ei tule hylkäystä; käsittely siirtyy seuraavaan sääntöön, ja kun sekään ei löydä mitään, se saavuttaa taulukon main. Mikään tuossa sarjassa ei raportoi, mikä sääntö tuotti lopullisen vastauksen, joten toimiva yhteys näyttää toimivalta politiikalta.

Taulukko 253, jota tavallisesti kutsutaan nimellä default, on tavallinen reititystaulukko ja on yleensä tyhjä. Sen nimi ei ole käsky hylätä paketteja, eikä se ole sama asia kuin taulukon sisäinen oletusreitti kohteeseen.

Terminaaliset toiminnot lopettavat haun

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Terminaalinen sääntö voi seurata VPN-hakua tyhjän taulukon haun sijaan. Samalla merkillä prohibit-toiminto, joka on sijoitettu taulukon 42 säännön jälkeen, lopettaa haun, kun kyseinen taulukko ei anna mitään, ja palauttaa hallinnollisen hylkäyksen sen sijaan, että antaisi taulukolle main vielä yhden mahdollisuuden. Unreachable ja blackhole ovat myös terminaalisia, lähettäjälle erilaisella virhekäyttäytymisellä.

Tyypin throw reitti on erilainen: kyseisen taulukon sisällä se käyttäytyy kuin mikään ei olisi vastannut, joten myöhemmät säännöt saavat silti vuoronsa. Tämä tekee throwista hyödyllisen tahalliselle paluulle ja väärän lopullisena blokkina.

Vahvista todellisella merkillä ja rajapinnalla

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Tarkastele todellisia sääntöjä ja taulukkoa kaavion sijaan ja kysy sitten virtaa lähteen, merkin ja saapumiskontekstin kanssa, jotka sillä todella on. Vain lukuun tarkoitettu haku kohteeseen, jolle annetaan lähdeosoite, rajapinta ja merkki, raportoi reitin, jonka ydin valitsisi ilman että paketti lähtee. Merkin antaminen kyselyssä ei todista, että palomuuri merkitsee todellista liikennettä; se on erillinen merkintäsääntöjen tarkistus. Vahvista arvo laskurilla tai lokilla ennen kuin teet kyselystä johtopäätöksiä.

Paikallisesti luodut pyynnöt tarvitsevat oman kontekstinsa, koska niiden merkintäpolku eroaa usein välitetyn liikenteen polusta. Tarkista ne lähtörajapinnalla, jota sovellus todella käyttäisi.

Kaksi virhetilaa, ei yksi

Yksi virhetila on VPN-reitin katoaminen ja liikenteen putoaminen uplinkille. Kuollut tunneli, jonka reitti pysyy asennettuna, on toinen: paketit pysyvät ohjattuina käyttökelvottomaan polkuun putoamisen sijaan, ja oire on hiljainen menetys eikä näkyvä suora yhteys. Testaa molemmat ja myös käynnistyksen, uudelleenyhdistämisen ja palvelun pysäytyksen käyttäytyminen.

Tällainen sääntö auttaa vain niin kauan kuin se on olemassa ja paketit yhä kantavat sen valitsevan merkin. Sammutusskripti, joka poistaa säännön, tai polku, joka poistaa merkin, palauttaa avoimen käyttäytymisen. Ne siirtymät kannattaa harjoitella.

Käytä politiikkaa IPv6:een erikseen ja pidä hyväksytyt päätepistepoikkeukset selkeinä implisiittisten sijaan.

Aiheeseen liittyvät artikkelit