NAT për LAN përmes tun0 në një portë VPN OpenBSD

Dy inxhinierë me të njëjtën portë OpenBSD shpesh të japin dy grupe rregullash të ndryshme për të arritur një rrjet të largët, dhe të dyja mund të mbrohen. Zgjedhja midis përkthimit të burimit dhe një rruge kthimi nuk është aspak çështje sintakse. Gjithçka varet nga ajo që pala tjetër di tashmë për 192.168.88.0/24 dhe nga ajo që duhet të ruash në regjistrat e tu. Gabo këtu dhe rreshti nat-to do të duket plotësisht i saktë ndërsa përgjigjet zhduken në portën e paracaktuar të largët.

Rrugëtimi dhe rishkrimi u përgjigjen pyetjeve të ndryshme

Tabela e rrugëtimit vendos që 172.20.0.0/16 është i arritshëm përmes tun0, dhe ky vendim merret përpara se të konsultohet çdo përkthim pf. Pastaj përkthimi i burimit ndryshon kryefjalën e paketës, kështu që skaji i largët sheh adresën e tunelit të portës në vend të një hosti LAN. Asnjë mekanizëm nuk e zëvendëson tjetrin: një rregull nat nuk mund të krijojë një rrugë, dhe një rrugë nuk mund të bindë një router të largët që nuk ka dëgjuar kurrë për nënrrjetin tënd privat. Kur palës tjetër i mungon një rrugë kthimi, përgjigjet hidhen ose dërgohen drejt portës së saj të paracaktuar, dhe asnjë rregullim i rregullave nuk e rregullon këtë.

Thënë thjesht, përcjellja përgjigjet se ku shkon trafiku dhe përkthimi përgjigjet se prej nga duket se vjen. Mbaji në kuti mendore të ndara ndërsa projekton grupin e rregullave.

Tre kushte që vendosin

Bëj tre pyetje me radhë dhe projektimi zakonisht zgjedh veten. A ka rrjeti i largët një rrugë statike që tregon adresën e tunelit për 192.168.88.0/24, apo administratori i tij kontrollon routerat në atë rrugë? Nëse po, lërini adresat LAN të udhëtojnë të pandryshuara dhe kapërce përkthimin plotësisht. A të duhet dukshmëri për çdo klient në anën tjetër, qoftë për politikën e aksesit qoftë për një gjurmë auditimi? Nëse po, ruajtja e burimit ia vlen puna e rrugëtimit. A është adresa e tunelit mjaftueshëm e qëndrueshme për t'u shkruar në një rrugë të largët, apo ndryshon midis rilidhjeve?

Nëse ndonjë përgjigje është jo ose e panjohur, nat-to është opsioni pragmatik, dhe është gjithashtu ai i kthyeshëm. Një rregull përkthimi hiqet me një rresht sapo pala tjetër shton një rrugë të duhur. Një rrugë kthimi që nuk u instalua kurrë të kushton një fije mbështetjeje sa herë që dikush pyet pse tuneli funksionon vetëm në një drejtim.

Vendos fragmentin në mënyrë që pf ta vlerësojë vërtet

Fragmenti më poshtë supozon se LAN-i është 192.168.88.0/24, rrjeti i largët është 172.20.0.0/16 dhe ndërfaqja e tunelit është tun0. Asgjë në të nuk zgjedh kërcimin tjetër. Ai vetëm rishkruan burimin në paketat që po dalin tashmë përmes tunelit.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dy detaje në atë rreshtin e parë mbajnë pjesën më të madhe të peshës. Kllapat rreth tun0 i thonë pf të lexojë adresën e ndërfaqes sa herë që ndërton një zë gjendjeje, gjë që ka rëndësi kur tuneli rinumërohet pas një rilidhjeje. Fjala match do të thotë që rregulli rishkruan dhe pastaj bie poshtë, kështu që një rregull pass i veçantë duhet ende ta lejojë rrjedhën. Ndërfaqja e emërtuar në rreshtin match duhet të jetë gjithashtu ajo që zgjedh tabela e rrugëtimit, përndryshe pf e vlerëson rregullin në një rrugë dalëse të ndryshme nga ajo që paketa merr vërtet.

Mos harro anën e kernelit. Përcjellja IPv4 duhet të jetë e aktivizuar, dhe rregullat pass me gjendje për tunel dhe LAN duhet të ekzistojnë përpara se e gjithë kjo të ketë kuptim. Seksioni PF NAT në FAQ e OpenBSD është referenca e duhur për rendin e fjalëve kyçe këtu.

Verifiko grupin e rregullave përpara se t'i besosh trafikut

Kontrollo së pari sintaksën me pfctl -nf /etc/pf.conf, i cili e analizon skedarin pa e ngarkuar. Pastaj ngarko politikën dhe lexo çfarë mban vërtet kerneli, sepse një rregull i analizuar pastër mund të mbetet ende i hijezuar ose i lidhur me ndërfaqen e gabuar. pfctl -sn shtyp rregullat e përkthimit në formën e tyre të ngarkuar, dhe pfctl -sr shtyp rregullat e filtrimit sipas rendit të vlerësimit.

Pastaj vëzhgo kabllon. Në portë, tcpdump -ni tun0 'host 172.20.0.10' tregon nëse adresa burimore që del nga tuneli është adresa e tunelit apo hosti LAN. Një netstat -rn -f inet i shpejtë konfirmon në cilën ndërfaqe zgjidhet destinacioni. Sapo trafiku fillon të rrjedhë, pfctl -ss liston zërat e gjendjes; nëse një rrjedhë nuk prodhoi gjendje, paketa nuk u përplas kurrë me një rregull që e krijon një të tillë.

Nëse ana e tunelit duket e saktë dhe përgjigjet ende nuk vijnë, ndalo së redaktuarit e pf. Defekti i mbetur është në routerin e largët, ku përgjigja dërgohet drejt një adrese private që ajo anë nuk mund ta arrijë.

Kur përkthimi kushton më shumë sesa kursen

Përkthimi i fsheh klientët, dhe ndonjëherë ky është pikërisht shkëmbimi i gabuar. Nënrrjetet e mbivendosura janë një rast: nëse edhe pala tjetër përdor 192.168.88.0/24 brenda, paraqitja e hosteve LAN si porta e bën përplasjen më të keqe në vend që ta përmirësojë. Politikat IPsec që zgjedhin trafikun sipas çiftit të adresave janë një rast tjetër, sepse baza e të dhënave e politikës së sigurisë përputhet përpara përkthimit dhe nuk e sheh kurrë paketën e rishkruar. Çdo vendosje që faturon, kufizon ose auditon për përdorues gjithashtu humbet identitetin që i nevojitet në momentin kur burimi shembet në një adresë të vetme.

Derivatet portabël të pf janë një kurth më vete. Produktet që gjenerojnë skedarët e tyre të rregullave presin që NAT të konfigurohet përmes ndërfaqes së tyre, dhe fragmentet e redaktuara me dorë mbishkruhen në ringarkimin tjetër. Grupet e rregullave të kopjuara nga udhëzues të shkruar përpara se të ekzistonte fjala kyçe match nuk do të ngarkohen në një kernel aktual, prandaj porto sintaksën dhe lexo gabimin në vend që të hamendësosh.

Rregulli i vendimit që i mbijeton kontaktit me rrjete reale është i shkurtër: instalo një rrugë kthimi kur mundesh, përkthe kur nuk mundesh, dhe shkruaj cila nga tre kushtet të bëri ta zgjidhje. Ai shënim i kursen një pasdite personit tjetër.