Malplena VPN-tabelo mem nenion blokas

Politika regulo sendas markitajn pakaĵojn al dediĉita tabelo, kaj la kutima atendo estas, ke la perdo de la VPN-vojo ilin blokas. La meĥanismo faras ion alian. Kiam tabelo enhavas neniun kongruan vojon, la serĉo daŭras al la sekva regulo anstataŭ halti, kaj la tabelo main ankoraŭ tenas ordinaran implicitan vojon por la suprenligo. La rezulto estas agordo, kiu aspektas fail-closed kaj kondutas kiel fail-open.

Nenio estas rompita; tiel estas specifita politika vojigo.

La serĉo daŭras, kiam tabelo havas nenion

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

Prenu tiun regulan aron: markita serĉo iras al tabelo 42, kaj posta regulo sendas la saman markon al tabelo nomata default. Dum tabelo 42 tenas uzeblan implicitan vojon, la unua serĉo liveras la vojon. Kiam tiu vojo malaperas kaj nenio alia en tabelo 42 kongruas, la serĉo ne fariĝas forĵeto; la prilaborado iras al la sekva regulo, kaj kiam ankaŭ tiu trovas nenion, ĝi atingas la tabelon main. Nenio en tiu sinsekvo raportas, kiu regulo produktis la finan respondon, do funkcianta konekto aspektas kiel funkcianta politiko.

Tabelo 253, kutime nomata default, estas ordinara vojiga tabelo kaj normale malplena. Ĝia nomo ne estas instrukcio forĵeti pakaĵojn, kaj ĝi ne samas kiel implicita celloka vojo ene de tabelo.

Finaj agoj finas la serĉadon

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

Fina regulo povas sekvi la VPN-serĉon anstataŭ serĉo en malplena tabelo. Kun la sama marko, ago prohibit metita post la regulo de tabelo 42 finas la serĉon, kiam tiu tabelo donas nenion, kaj redonas administran malakcepton anstataŭ doni al la tabelo main ankoraŭ unu ŝancon. Unreachable kaj blackhole ankaŭ estas finaj, kun malsama erara konduto por la sendinto.

Vojo de tipo throw malsamas: ene de tiu tabelo ĝi kondutas kvazaŭ nenio kongruis, do postaj reguloj ankoraŭ ricevas sian vicon. Tio faras throw utila por intenca retrofalo kaj malĝusta kiel fina bloko.

Kontrolu per la reala marko kaj interfaco

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

Ekzamenu la realajn regulojn kaj tabelon anstataŭ diagramo, poste demandu la fluon per la fonta, marka kaj enira kunteksto, kiun ĝi vere havas. Nurlega serĉo celita al celloko, al kiu oni diras la fontan adreson, interfacon kaj markon, raportas la vojon, kiun la kerno elektus sen eliro de pakaĵo. Doni markon en la demando ne pruvas, ke la fajroŝirmilo markas realan trafikon; tio estas aparta kontrolo de la markaj reguloj. Konfirmu la valoron per nombrilo aŭ protokolo antaŭ ol fari konkludojn el la demando.

Loke generitaj petoj bezonas sian propran kuntekston, ĉar ilia marka vojo ofte diferencas de tiu de plusendita trafiko. Kontrolu ilin per la elira interfaco, kiun la aplikaĵo vere uzus.

Du fiaskaj statoj, ne unu

Unu fiaska stato estas la malapero de la VPN-vojo kaj la falo de trafiko al la suprenligo. Morta tunelo, kies vojo restas instalita, estas alia: pakaĵoj restas direktitaj en neuzeblan vojon anstataŭ fali, kaj la simptomo estas silenta perdo anstataŭ videbla rekta konekto. Testu ambaŭ, kaj ankaŭ la konduton ĉe starto, rekonekto kaj halto de la servo.

Tia regulo helpas nur dum ĝi ekzistas kaj dum pakaĵoj ankoraŭ portas la markon, kiu elektas ĝin. Malŝalta skripto, kiu forigas la regulon, aŭ vojo, kiu forprenas la markon, restarigas la malferman konduton. Tiuj transiroj indas esti ekzercitaj.

Apliku la politikon al IPv6 aparte, kaj tenu aprobitajn esceptojn de finpunktoj eksplicitaj anstataŭ implicitaj.