Klientët në LAN zgjidhin përmes tunelit dhe kërkimet e vetë routerit nuk e bëjnë këtë në heshtje. Përditësimet e paketave, sinkronizimi i kohës dhe DNS dinamik dalin të gjitha përmes uplinkut të zakonshëm, ndërsa çdo kërkesë e përcjellë merr VPN-në, dhe asgjë në ndërfaqe nuk sugjeron se ekzistojnë dy rrugë të ndryshme. Shpjegimi nuk është gabim në politikë por një çështje e cila grep e sheh paketën. Dy rrjedha, një adresë zgjidhësi, dhe vetëm njëra prej tyre kalon routerin. Ndarja e tyre është e gjithë rregullimi.

Dy rrjedha, një adresë zgjidhësi

Rrjedha e parë është ajo që njerëzit imagjinojnë. Një klient pyet zgjidhësin e routerit, zgjidhësi përcjell lart, dhe ajo paketë e përcjellë kalon routerin gjatë daljes. Ajo paketë është e dukshme për çdo gjë që vëzhgon trafikun e përcjellë.

Rrjedha e dytë nuk mbërrin kurrë nga askund. Routeri e krijon, pra nuk ka paketë hyrëse as hap përcjelljeje për t'u përputhur.

Të dyja mund të synojnë të njëjtën adresë zgjidhësi, dhe pikërisht për këtë dallimi kapet lehtë. E njëjta destinacion, origjinë tjetër, zinxhir tjetër. Pasi të shihni origjinën, pjesa tjetër e diagnostikimit vijon.

Paketat e përcjella dhe ato të krijuara lokalisht hyjnë ndryshe

Trafiku i përcjellë vlerësohet kur vjen nga një ndërfaqe tjetër. Paketat e rutimit të politikave e ekspozojnë atë si zinxhir prerouting, dhe një rregull i vendosur atje sheh çdo paketë që kalon routerin. Prandaj kërkesat e klientëve sillen pikërisht siç përshkruan politika, dhe prandaj routeri e injoron atë. Rregulli nuk është i gabuar, thjesht është i lidhur me një grep ku routeri nuk arrin kurrë. Zhvendose atë, dhe e njëjta përputhje fillon të funksionojë.

Trafiku i krijuar lokalisht krijohet nga një proces në router dhe hyn në rrugën e daljes. Rutimin e tij e bën vendimi i vetë routerit dhe ai takohet me politikën vetëm nëse politika mbulon atë zinxhir. Nuk ka ndërfaqe hyrëse për t'u përputhur as vendim përcjelljeje për t'u vëzhguar.

Ky është një veti e vendit ku lindin paketat, jo e ndonjë pakete të veçantë. Një rregull i shkruar për një zinxhir thjesht nuk ka mendim për tjetrin. Asnjë rregullim i rregullave nuk e ndryshon këtë.

Zgjidhni zinxhirin e daljes, pastaj ngushtoni përputhjen

Rregullimi është t'i bashkëngjitni të njëjtin qëllim edhe zinxhirit të daljes, ose ta zhvendosni rregullin atje kur kërkesat e vetë routerit janë ato që ju interesojnë. Në një konfigurim OpenWrt të ndërtuar mbi një paketë rutimi politikash, kjo do të thotë të zgjidhni output në vend të prerouting në cilësimin e zinxhirit të rregullit. Mbani të dy rregullat nëse të dyja popullatat kanë nevojë për mbulim.

Pastaj ngushtoni atë që përputh rregulli. Adresat e zgjidhësit të destinacionit në portën që zgjidhësi përdor vërtet janë një vendim shumë më i vogël sesa dërgimi në tunel i gjithçkaje që krijon routeri.

Mbani dy rregullat eksplicite në vend që të provoni të shkruani një që mbulon të dy zinxhirët. Rregullat e ndara lexohen më lehtë, dhe ju lejojnë të çaktivizoni rrugën e routerit pa shqetësuar trafikun e klientëve ndërsa korrigjoni gabime. Ato gjithashtu i bëjnë numëruesit kuptimplotë një nga një.

Mbajeni transportin e vetë tunelit jashtë rregullit

Lidhja e jashtme e tunelit krijohet gjithashtu nga routeri. Një rregull që dërgon të gjithë trafikun e krijuar lokalisht në tunel do ta rrutojë tunelin përmes vetvetes, dhe ai nuk do të ngrihet fare.

Qasja e menaxhimit është viktima e dytë. Seancat administrative që burojnë nga routeri, ose përgjigjet për to, mund të tërhiqen në tunel nga një rregull lokal tepër i gjerë dhe të bëhen të paarritshme nga LAN-i.

Përjashtoni pikën fundore të tunelit nga përputhja, dhe mbajeni rregullin të kufizuar te adresat e zgjidhësit. Kjo mjafton për kërkesën e DNS-së dhe është mjaft e vogël për të menduar rreth saj.

Testoni të dyja popullatat, jo një

Vëzhgoni routerin duke bërë kërkesën e vet dhe vini re cila ndërfaqe e mbajti. Përsëritni kërkimin nga një host i LAN-it dhe vini re cilën rrugë zgjodhi. Numëruesit në rregullat e politikës i bëjnë të dyja përgjigjet të dukshme pa hamendësuar.

Trajtojini rezultatet si dy gjetje. Një klient që zgjidh përmes tunelit nuk thotë asgjë për routerin, dhe një router që zgjidh saktë nuk thotë asgjë për një klient në një dëgjues tjetër. Shkruajini si rreshta të ndarë në regjistrin e ndryshimeve.

Kontrolloni edhe portën: një rregull që përputh portën e destinacionit 53 humbet një zgjidhës që arrihet përmes DNS over TLS në 853 ose një pikë fundore HTTPS. Përputhni transportin që upstream-i i konfiguruar përdor vërtet, dhe rrjedhja mbyllet për arsyen e duhur.

Artikuj të ngjashëm