Poliitikareegel saadab märgistatud paketid sihtotstarbelisse tabelisse ja tavaline ootus on, et VPN-marsruudi kadumine blokeerib need. Mehhanism teeb midagi muud. Kui tabelis pole sobivat marsruuti, jätkub otsing järgmise reegliga selle asemel et peatuda, ja tabel main hoiab endiselt tavalist vaikemarsruuti uplink’i jaoks. Tulemuseks on konfiguratsioon, mis näeb välja fail-closed, kuid käitub fail-open’ina.

Miski pole katki; nii on poliitikapõhine marsruutimine määratletud.

Otsing jätkub, kui tabelis pole midagi

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

Võtke see reeglistik: märgistatud otsing läheb tabelisse 42 ja hilisem reegel saadab sama märgi tabelisse nimega default. Kuni tabel 42 hoiab kasutatavat vaikemarsruuti, annab esimene otsing tee. Kui see marsruut kaob ja midagi muud tabelis 42 ei sobi, ei muutu otsing äraviskamiseks; töötlemine liigub järgmise reegli juurde ja kui seegi midagi ei leia, jõuab see tabelini main. Miski selles järjestuses ei teata, milline reegel andis lõpliku vastuse, seega näeb töötav ühendus välja nagu töötav poliitika.

Tabel 253, mida tavapäraselt nimetatakse default’iks, on tavaline marsruutimistabel ja on tavaliselt tühi. Selle nimi ei ole korraldus pakette ära visata ja see pole sama asi kui tabelis olev vaikimisi sihtkoha marsruut.

Terminaalsed toimingud lõpetavad otsingu

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

Terminaalne reegel võib järgneda VPN-otsingule tühja tabeli otsingu asemel. Sama märgiga lõpetab prohibit-toiming, mis on paigutatud tabeli 42 reegli järele, otsingu, kui see tabel midagi ei anna, ja tagastab administratiivse keeldumise, selle asemel et anda tabelile main veel üks võimalus. Unreachable ja blackhole on samuti terminaalsed, saatja jaoks erineva veakäitumisega.

Tüübi throw marsruut on erinev: selle tabeli sees käitub see nii, nagu miski ei sobiks, seega hilisemad reeglid saavad ikkagi oma järje. See teeb throw’st kasuliku tahtlikuks tagasilanguseks ja vale lõplikuks blokeeringuks.

Kontrollige tegeliku märgi ja liidesega

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

Uurige tegelikke reegleid ja tabelit, mitte diagrammi, seejärel pärige voogu lähte-, märgi- ja sisenemiskontekstiga, mis sellel tegelikult on. Ainult lugemiseks mõeldud otsing sihtkoha suunas, millele on antud lähteaadress, liides ja märk, teatab marsruudi, mille tuum valiks, ilma et pakett väljuks. Märgi andmine päringus ei tõesta, et tulemüür märgistab tegelikku liiklust; see on märgistusreeglite eraldi kontroll. Kinnitage väärtust loenduri või logiga enne, kui teete päringust järeldusi.

Kohapeal loodud päringud vajavad oma konteksti, sest nende märgistustee erineb sageli edastatud liikluse teest. Kontrollige neid väljundliidesega, mida rakendus tegelikult kasutaks.

Kaks tõrkeolekut, mitte üks

Üks tõrkeolek on see, et VPN-marsruut kaob ja liiklus langeb uplink’i. Surnud tunnel, mille marsruut jääb paigaldatuks, on teine: paketid jäävad suunatuks kasutuskõlbmatule teele, selle asemel et läbi langeda, ja sümptom on vaikne kadu, mitte nähtav otsene ühendus. Testige mõlemat ning ka käivitamise, taasühendamise ja teenuse peatamise käitumist.

Selline reegel aitab ainult seni, kuni see eksisteerib ja kuni paketid kannavad endiselt märki, mis selle valib. Sammutusskript, mis reegli kustutab, või tee, mis märgi eemaldab, taastab avatud käitumise. Neid üleminekuid tasub harjutada.

Rakendage poliitikat IPv6-le eraldi ja hoidke kinnitatud lõpp-punktide erandid selgesõnalistena, mitte kaudsetena.

Seotud artiklid