Razbija li hardverski NAT offload vaša VPN pravila usmeravanja?

Uključivanje hardverskog NAT ubrzanja može učiniti VPN postavku bržom, a može i učiniti da politika usmeravanja prestane da se primenjuje na neke pakete bez ikakve greške. Koje će se od toga dogoditi zavisi od toga šta brza putanja preskače, a to se razlikuje između firmvera, verzije kernela i vrste ubrzanja koja se koristi. Meni sa podešavanjima retko kaže koje ste upravo uključili.

Dve tvrdnje zaslužuju razdvajanje pre nego što se optuži ubrzivač: da je pravilo prestalo da se primenjuje i da je brojač prestao da se ažurira. To nije isto zapažanje.

Tri različita ubrzanja se mešaju u jedno

Offload prosleđivanja, kriptografsko ubrzanje i offload podatkovnog kanala tunela su odvojeni mehanizmi koji često dele jedan prekidač. Offload prosleđivanja omogućava uspostavljenim tokovima da preskoče deo normalnog steka, kriptografsko ubrzanje čini rad šifrovanja jeftinijim, a offload tunela premešta enkapsulaciju u hardver. Ruter koji ubrzava običan usmereni saobraćaj može ostaviti saobraćaj tunela potpuno na sporoj putanji, što je rezultat performansi, a ne promena politike. Postoji i obrnuto, kada se saobraćaj tunela offloaduje dok se okolna politika još ocenjuje.

Linux flowtables su dokumentovani slučaj koji je najvredniji čitanja, jer se uspostavljeni tokovi mogu predati brzoj putanji. Njihovo računovodstvo i rukovanje stanjem tada se razlikuju od klasičnog prosleđivanja, i zato brojači počinju da izgledaju čudno.

Brojač koji prestane da se kreće dokazuje malo

Brojači pravila broje pakete koji prolaze kroz pravilo, a offloadovan tok možda nikada više neće proći kroz njega posle prvog paketa. To stvara brojač koji se zamrzava dok saobraćaj traje, i izgleda tačno kao zaobilaznica ako verujete broju. Posmatranje brojača je i dalje korisno kao nagoveštaj da je tok napustio brojanu putanju. Ostatak dijagnostike mora doći iz toga gde paketi zaista idu.

Suprotan zaključak pada isto tako loše. Brzo preuzimanje ne pokazuje da vaša pravila izuzetaka i rukovanje greškama još važe, jer vežba jedan tok, a ne politiku.

Tri uslova odlučuju da li offload razbija politiku

Prvi uslov je da li brza putanja konsultuje kuku od koje zavisi vaša politika, jer politika izražena oznakama i rutama preživljava češće od one izgrađene na filtriranju po paketu. Drugi je da li firmver uopšte dozvoljava takvu kombinaciju, jer neke gradnje automatski isključuju offload kada je tunel ili funkcija firewall-a aktivna. Treći je da li je saobraćaj podoban, jer je ubrzanje obično vezano za uspostavljene tokove i može isključiti fragmentisane ili neobične pakete. Tamo gde sva tri favorizuju ubrzanje, politika se i dalje primenjuje, a tamo gde prvi uslov zakaže, nikakvo podešavanje je ne vraća.

Čitajte dokumentaciju proizvođača za kombinaciju koju pokrećete, a ne za model rutera uopšte. Verzije firmvera tiho menjaju te odgovore.

Testirajte politiku, a ne propusnost

Izmerite šta politika treba da garantuje pre nego što izmerite koliko brzo radi. Komande ispod pokazuju da li je flowtable instaliran, šta praćenje veza vidi i sa koje adrese klijent izlazi. Uporedite novu vezu posle promene, jer uspostavljena može zadržati staru putanju.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

Unos u flowtable koji pokriva saobraćaj tunela govori vam da je brza putanja u igri, a tabela veza pokazuje da li se tok prati kako očekujete. Provera adrese potvrđuje izlaz kada se politika tiče izlaska na internet, dok ping potvrđuje privatno odredište koje treba da ostane dostupno. Pokrenite isti skup sa isključenim, a zatim uključenim ubrzanjem i uporedite rezultate, a ne vremena.

Zapišite prethodno podešavanje da eksperiment ostane reverzibilan. Opšte uputstvo da se offload isključi svuda računa se kao zaobilazno rešenje, a ne kao nalaz.