Ĉu aparatara NAT-malŝarĝo rompas viajn VPN-adresajn regulojn?

Ŝalti aparataran NAT-akcelon povas igi VPN-agordon pli rapida, kaj ĝi ankaŭ povas igi adresan politikon ĉesi validi por iuj pakaĵoj tute sen ia eraro. Kiu el la du okazas dependas de tio, kion la rapida vojo preterpasas, kaj tio diferencas inter firmvaro, kernversio kaj la speco de akcelo uzata. La agorda menuo malofte diras al vi, kiun vi ĵus ebligis.

Du asertoj meritas apartigon antaŭ ol kulpi la akcelilon: ke regulo ĉesis esti plenumata, kaj ke nombrilo ĉesis esti ĝisdatigata. Ili ne estas la sama observo.

Tri malsamaj akceloj estas kunmiksataj

Malŝarĝo de plusendado, kriptografia akcelo kaj malŝarĝo de la datumkanalo de la tunelo estas apartaj mekanismoj, kiuj ofte dividas unu solan ŝaltilon. Malŝarĝo de plusendado lasas establiĝintajn fluojn preterpasi parton de la normala stako, kriptografia akcelo malmultekostigas la ĉifran laboron, kaj tunela malŝarĝo movas la enkapsuligon en la aparataron. Enkursigilo, kiu akcelas ordinaran enkursigitan trafikon, povas lasi la tunelan trafikon tute sur la malrapida vojo, kio estas rezulto de rendimento, ne ŝanĝo de politiko. Ankaŭ la malo ekzistas, kie la tunela trafiko estas malŝarĝata dum la ĉirkaŭa politiko ankoraŭ estas taksata.

Flowtables de Linux estas la dokumentita kazo plej inda legi, ĉar establiĝintaj fluoj povas esti transdonitaj al rapida vojo. Ilia kalkulado kaj stato-administrado tiam diferencas de klasika plusendado, kaj tial la nombriloj komencas aspekti strangaj.

Nombrilo, kiu ĉesas moviĝi, pruvas malmulte

Regulnombriloj kalkulas la pakaĵojn, kiuj trapasas la regulon, kaj malŝarĝita fluo eble neniam plu trapasos ĝin post la unua pakaĵo. Tio produktas nombrilon, kiu frostas dum trafiko daŭras, kaj ĝi aspektas precize kiel preterpaso, se vi fidas la nombron. Observi la nombrilon ankoraŭ utilas kiel signo, ke la fluo forlasis la kalkulatan vojon. La resto de la diagnozo devas veni de tio, kien la pakaĵoj fakte iras.

La kontraŭa konkludo malsukcesas same malbone. Rapida elŝuto ne montras, ke viaj esceptaj reguloj kaj erartraktado ankoraŭ validas, ĉar ĝi ekzercas unu fluon kaj ne la politikon.

Tri kondiĉoj decidas, ĉu malŝarĝo rompas politikon

La unua kondiĉo estas ĉu la rapida vojo konsultas la hokon, de kiu via politiko dependas, ĉar politiko esprimita per markoj kaj vojoj pluvivas pli ofte ol unu konstruita el filtrado laŭ pakaĵo. La dua estas, ĉu la firmvaro entute permesas tiun kombinaĵon, ĉar iuj konstruoj aŭtomate malŝaltas malŝarĝon kiam tunelo aŭ fajroŝirma funkcio estas aktiva. La tria estas, ĉu la trafiko taŭgas, ĉar akcelo kutime ligiĝas al establiĝintaj fluoj kaj povas ekskludi fragmentitajn aŭ nekutimajn pakaĵojn. Kie ĉiuj tri favoras akcelon, la politiko ankoraŭ validas, kaj kie la unua malsukcesas, nenia agordado ĝin restarigas.

Legu la dokumentaron de la vendisto por la kombinaĵo, kiun vi uzas, ne por la enkursigila modelo ĝenerale. Firmvaraj versioj ŝanĝas tiujn respondojn silente.

Testu la politikon, ne la trafikan kapaciton

Mezuru, kion la politiko devas garantii, antaŭ ol mezuri, kiom rapide ĝi iras. La subaj komandoj montras, ĉu flowtable estas instalita, kion vidas konekta spurdo kaj de kiu adreso la kliento eliras. Komparu novan konekton post la ŝanĝo, ĉar establiĝinta konekto povas konservi sian malnovan vojon.

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

Flowtable-ero, kiu kovras la tunelan trafikon, diras al vi, ke la rapida vojo estas en ludo, kaj la konekta tabelo montras, ĉu la fluo estas spurata tiel, kiel vi atendas. La adresa kontrolo konfirmas la eliron, kiam la politiko koncernas interretan eliron, dum la ping konfirmas privatan celon, kiu devas resti atingebla. Rulu la saman aron kun akcelo malŝaltita kaj poste ŝaltita, kaj komparu la rezultojn anstataŭ la tempojn.

Notu la antaŭan agordon, por ke la eksperimento restu reigebla. Ĝenerala instrukcio malŝalti malŝarĝon ĉie validas kiel provizora solvo, ne kiel trovo.