Aplikacion lokal, rregull VPN: pse zinxhiri FORWARD nuk aktivizohet kurrë

Shtoni një rregull për trafikun VPN në zinxhirin FORWARD, ekzekutoni kërkesën nga e njëjta makinë Linux, dhe numëruesi mbetet në zero. Rregulli me gjasë është i saktë. Paketa nuk e mori kurrë atë rrugë, sepse një kërkesë e krijuar në vetë makinën nuk përcillet prej saj. Ndjekja e jetës së paketës nga socketa te kablloja shpjegon pse, dhe ku duhet të jetë rregulli në vend të kësaj.

Gjeni ku lindi paketa

Rendi i grepave të Netfilter ndan tre raste, dhe vetëm njëri prej tyre përfshin FORWARD:

Një aplikacion lokal fillon në shtegun OUTPUT, sepse kerneli tashmë ka përcaktuar që paketa origjinon këtu dhe nuk është kurrë kandidat për përcjellje. Krijimi i një tuneli nuk e ndryshon atë klasifikim; tuneli është një pajisje përmes së cilës paketa mund të dalë, jo një fazë që e kthen daljen lokale në tranzit.

Dy paketa, një histori

Pasi tuneli është ngritur, paketa e brendshme e aplikacionit dhe paketa e jashtme e kriptuar janë objekte të ndryshme. Paketa e brendshme mbart destinacionin dhe ngarkesën që zgjodhi aplikacioni. Paketa e jashtme mbart tekst të kriptuar drejt adresës dhe portës së partnerit, dhe është ajo që kalon vërtet ndërfaqen fizike.

Politika juaj ka të bëjë me njërën prej tyre, dhe zgjedhja e gabuar është një shkak i zakonshëm që një rregull të duket se nuk bën asgjë. Një rregull që përputhet me adresën e jashtme të partnerit e sheh çdo paketë të tunelit njësoj, çfarëdo që bën aplikacioni brenda. Një rregull që përputhet me një destinacion të brendshëm e sheh trafikun që ju intereson, dhe do të aktivizohet vetëm nëse ajo paketë arrin grepin ku e instaloni rregullin.

Hapësirat e emrave e zhvendosin kufirin

Një kontejner e bën këtë më të vështirë pa ndryshuar parimin. Kërkesa e aplikacionit është dalje lokale brenda hapësirës së emrave të rrjetit të kontejnerit. Host-i e merr atë trafik në një ndërfaqe virtuale Ethernet dhe mund ta përcjellë, kështu që një rregull FORWARD në host mund të ketë kuptim edhe pse procesi që krijoi kërkesën nuk e preku kurrë zinxhirin OUTPUT të host-it.

Përpara se të zgjidhni një grep, përcaktoni ku jetojnë vërtet grupi i rregullave dhe tuneli. Tunel brenda kontejnerit, tunel në host me kontejnerin e rrugëzuar përmes tij, dhe tunel në një hapësirë të veçantë emrash janë tre topologji të ndryshme me tre vendosje të ndryshme rregullash. Lexoni rregullat brenda hapësirës së emrave që zotëron pajisjen, jo vetëm në atë të paracaktuar.

Pyesni nëse ju nevojitet fare një shenjë

Nëse qëllimi është të dërgohet një prefiks destinacioni përmes tunelit, një rrugë për atë prefiks mund të mjaftojë. Kontrolloni fillimisht rrugët efektive, përfshirë gjithçka që serveri ka shtyrë: një rrugë e paracaktuar e ridrejtuar dërgon shumë më tepër trafik përmes VPN-së sesa politika e ngushtë që kishit në mendje, dhe asnjë sasi shënimi nuk do ta bëjë rezultatin në përputhje me qëllimin.

Klasifikimi nevojitet kur vendimi varet nga diçka që një rrugë nuk mund ta shprehë, si burimi, përdoruesi ose procesi. Për trafikun e marrë, shënimi në PREROUTING funksionon. Për trafikun lokal, shënimi duhet të ndodhë në një fazë daljeje që mund të nxisë një kërkim të ri rruge pasi shenja është vendosur. Me nftables kjo është një zinxhir i tipit route në grepin e daljes; një zinxhir i zakonshëm filtri daljeje do ta vendosë vlerën dhe do ta lërë rrugën të pandryshuar.

Me iptables, ekuivalenti jeton në rregullimin mangle OUTPUT, dhe zbatohet e njëjta kërkesë: vendimi i rrugëzimit duhet të rishqyrtohet pasi shenja ekziston. Pastaj një rregull politike duhet ta konsumojë shenjën dhe të tregojë një tabelë që përmban një rrugë të përdorshme. Vendosja e një shenje conntrack është një operacion i tretë, i veçantë; ai ruan një vlerë në rrjedhë dhe nuk e vendos vetë atë vlerë në paketën aktuale që rrugëzimi ta lexojë.

Verifikoni kërkimin dhe numëruesin së bashku

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Adresa dhe shenja janë ilustrative, dhe dy pyetjet e rrugës u përgjigjen pyetjeve të ndryshme. E dyta pyet çfarë do të bënte kerneli nëse një paketë do të mbarte atë shenjë; nuk tregon se grupi juaj i rregullave cakton një të tillë. Trajtojeni si provë hipoteze, jo si provë që politika funksionon.

Pastaj ekzekutoni një kërkesë të padëmshme dhe shikoni dy gjëra njëkohësisht: numëruesin në grepin që zgjodhët, dhe daljen që paketa mori vërtet. Nëse numëruesi lëviz dhe paketa del diku tjetër, shenja ose tabela është e gabuar. Nëse asnjëri nuk lëviz, paketa nuk e arrin fare atë grep, dhe pyetja tjetër është hapësira e emrave ose shtegu.

Së fundi, kufizojeni provën në atë që mekanizmi mund të shprehë. Një rrugë për një adresë nuk bëhet politikë e përhershme për një shërbim adresat e të cilit rrotullohen. Vendosni fillimisht shtrirjen e paketave, pastaj kontrolloni nëse dizajni i rrugëzimit dhe shënimit mund ta mbajë atë shtrirje pas një rilidhjeje.