Tuščia VPN lentelė pati savaime nieko neblokuoja

Politikos taisyklė siunčia pažymėtus paketus į atskirą lentelę, ir įprastas lūkestis yra tai, kad praradus VPN maršrutą jie bus užblokuoti. Tačiau mechanizmas daro ką kita. Kai lentelėje nėra atitinkančio maršruto, paieška tęsiasi prie kitos taisyklės o ne sustoja, ir lentelė main vis dar turi įprastą numatytąjį maršrutą uplink’ui. Rezultatas – konfigūracija, kuri atrodo kaip fail-closed, bet elgiasi kaip fail-open.

Niekas nesugedę; taip apibrėžiamas politikos pagrindu veikiantis maršrutizavimas.

Paieška tęsiasi, kai lentelėje nieko nėra

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

Paimkite tą taisyklių rinkinį: pažymėta paieška eina į 42 lentelę, o vėlesnė taisyklė siunčia tą patį žymeklį į lentelę, vardu default. Kol 42 lentelėje yra tinkamas numatytasis maršrutas, pirmoji paieška pateikia kelią. Kai tas maršrutas išnyksta ir niekas kitas 42 lentelėje nebeatitinka, paieška netampa atmetimu; apdorojimas pereina prie kitos taisyklės, o kai ir ji nieko neranda, pasiekia lentelę main. Niekas toje sekoje nepraneša, kuri taisyklė pateikė galutinį atsakymą, todėl veikiantis ryšys atrodo kaip veikianti politika.

Lentelė 253, įprastai vadinama default, yra įprasta maršrutizavimo lentelė ir paprastai būna tuščia. Jos pavadinimas nėra nurodymas mesti paketus, ir tai nėra tas pats, kas numatytasis paskirties maršrutas lentelės viduje.

Galiniai veiksmai užbaigia paiešką

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

Galinė taisyklė gali sekti po VPN paieškos vietoj paieškos tuščioje lentelėje. Su tuo pačiu žymekliu veiksmas prohibit, įdėtas po 42 lentelės taisyklės, užbaigia paiešką, kai ta lentelė nieko neduoda, ir grąžina administracinį atmetimą, o ne suteikia lentelei main dar vieną galimybę. Unreachable ir blackhole taip pat yra galiniai, su skirtingu klaidos elgesiu siuntėjui.

throw tipo maršrutas yra kitoks: toje lentelėje jis elgiasi taip, tarsi niekas neatitiko, todėl vėlesnės taisyklės vis tiek gauna savo eilę. Tai daro throw naudingą tyčiniam atsitraukimui ir klaidingą kaip galutinį bloką.

Patikrinkite su tikruoju žymekliu ir sąsaja

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

Išnagrinėkite tikrąsias taisykles ir lentelę, o ne diagramą, tada užklauskite srautą su šaltinio, žymeklio ir įėjimo kontekstu, kurį jis tikrai turi. Tik skaitymui skirta paieška, nukreipta į paskirties vietą, kuriai nurodytas šaltinio adresas, sąsaja ir žymeklis, praneša maršrutą, kurį branduolys pasirinktų, paketui neišėjus. Žymeklio pateikimas užklausoje neįrodo, kad ugniasienė žymi tikrą srautą; tai atskiras žymėjimo taisyklių patikrinimas. Patvirtinkite reikšmę skaitikliu ar žurnalu, prieš darydami išvadas iš užklausos.

Vietoje sugeneruotos užklausos turi savo kontekstą, nes jų žymėjimo kelias dažnai skiriasi nuo persiunčiamo srauto kelio. Patikrinkite jas išvesties sąsaja, kurią programa tikrai naudotų.

Dvi gedimo būsenos, o ne viena

Viena gedimo būsena yra tai, kad VPN maršrutas išnyksta ir srautas nukrenta į uplink. Negyvas tunelis, kurio maršrutas lieka įdiegtas, yra kita: paketai lieka nukreipti į netinkamą kelią, o ne nukrenta, ir simptomas yra tyli netektis, o ne matomas tiesioginis ryšys. Patikrinkite abi, taip pat paleidimo, pakartotinio prisijungimo ir paslaugos sustabdymo elgesį.

Tokia taisyklė padeda tik tol, kol ji egzistuoja ir kol paketai dar neša ją pasirenkantį žymeklį. Išjungimo scenarijus, kuris ištrina taisyklę, arba kelias, kuris pašalina žymeklį, atkuria atvirą elgesį. Tuos perėjimus verta išbandyti.

Taikykite politiką IPv6 atskirai ir laikykite patvirtintas galinių taškų išimtis aiškias, o ne numanomas.