Ekkert tun0? Passið afkóðað IPsec í nftables með meta ipsec

Þú býst við túnel-tengi, leitar að því, og það er ekkert til að passa í eldveggnum. Það er eðlilegt fyrir stefnumiðaða gátt: dulkóðuðu skiptin berast á eðlisfræðilega tengið og afkóðaði innri pakkinn sem er svo sendur áfram sést líka berast á sama tenginu. Það er ekkert tun0 því ekkert bjó það til.

Innri beiðnin er enn sérstakur pakki með eigin uppruna, áfangastað og þjónustu, og kjarninn veit úr hvaða öryggissamtökum hann kom. Þekkingin sem eldveggsregla getur passað er einmitt þessi.

Tveir pakkar, eitt tengi

Sjáðu fyrir þér innkomandi áttina. ESP- eða UDP-umbúinn pakki berst, kjarninn finnur samsvarandi stefnu, afkóðar hann og afhendir klára pakkann sendingarleiðinni. Regla sem lítur aðeins á nafn tengisins getur ekki greint þann pakka frá annarri umferð sem berst á sama vír.

Það sem greinir hann er samhengi innkomandi öryggisleiðar sem fylgir pakkanum. nftables sýnir það sem meta ipsec exists, sem er satt þegar pakkinn barst um öryggisleið IPsec. Sameinaðu það við hóp skjólstæðinga, áfangastaðinn og þjónustuna, og reglan verður nógu nákvæm til að vera örugg.

Að sleppa samhenginu er algenga mistökin, og það eru öryggismistök en ekki snyrtileg. Regla sem samþykkir allt sem kemur frá hópi skjólstæðinga samþykkir jafn gjarnan fölsuðum pakka úr staðarnetinu, því upprunafangið er eitt og sér ekki sönnun fyrir neinu. Samhengi öryggisleiðarinnar er ódýrasta leiðin til að gera upprunann merkingarbæran. Skrifaðu regluna með því frá byrjun í stað þess að bæta því við eftir úttekt.

Skrifaðu sendingarregluna

Gerðu ráð fyrir sannvottaðri IPv4 fjarnámsþjónustu með skjólstæðinga í 10.90.0.0/24 og einn samþykktan áfangastað á 203.0.113.40. Reglubrot fyrir það flæði lítur svona út.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Föngin og tengið eru dæmi sem á að skipta út. Setjið yfirfarna jafngildið í sendingarstefnuna á undan reglunni sem myndi ella hafna flæðinu, og tæmdu ekki fyrirliggjandi reglusafn til að setja það upp; gátt er ekki tilraun í hreinu herbergi.

Hugtakið oifname er þess virði að halda. Það skjalfestir útleiðarákvörðunina og kemur í veg fyrir að reglan passi í átt sem þú ætlaðir ekki, sem skiptir máli á gátt með nokkrar leiðir á internetið. Á prófunarboxi með eina upptengingu virðist hugtakið óþarft, og einmitt þess vegna er því sleppt áður en boxið fær aðra upptengingu.

Heimildir fyrir ytri skiptin eru aðskildar. Inntaksleið gáttarinnar þarf IKE- og ESP- eða UDP-umbúðarportin sem hún notar í raun, og þessar heimildir leyfa ekkert varðandi afkóðaða pakkann inni. Að blanda þessu tvennu saman er leiðin sem virkur túnel endar með eldvegg sem sendir allt áfram.

Innkomandi samhengi er ekki útleiðarsamhengi

Sama fjölskylda orðasambanda nær yfir hina áttina með rt ipsec, sem lýsir útleiðaröryggissamtökunum sem pakki mun nota. Það svarar annarri spurningu: ekki hvaðan þessi pakki kom, heldur hvort hann verði varinn á næsta kafla.

Sá greinarmunur skiptir máli á gátt sem lýkur annarri göngu og sendir samt áfram í aðra. Pakki getur borist afkóðaður og á samt að fara dulkóðaður, og samþykkt sem skrifuð er aðeins fyrir innkomandi samhengi segir ekkert um útleiðarkröfuna. Ef stefnan krefst þeirrar varnar ætti reglusafnið að tjá hana í stað þess að gera ráð fyrir að leiðsögnin sjái um það.

Haltu spurningunum tveimur í aðskildum reglum svo lesandinn sjái hvor sé framfylgt. Ein snjöll regla sem athugar báðar er erfiðari yfirferðar og mun erfiðari að aflúsa þegar annar helmingur hennar hættir að passa. Tvær reglur með teljurum segja þér líka hvaða kröfu mistekst, sem ein sameinuð regla mun aldrei gera.

NAT er ekki eldveggsákvörðun

Umferð á internetið frá einkahópi skjólstæðinga þarf venjulega upprunaaðlögun svo svarið finni leið til baka. En umferð sem valin er fyrir aðra útleiðarstefnu IPsec verður að halda tilskildri undanþágu sinni, og að dylja hvern einkauppruna án þess að hugsa um næstu varnarákvörðun brýtur það.

Samþykkt inni í NAT-keðju er heldur ekki almenn heimild. NAT og síun hafa ólík störf, og NAT-keðja skoðar ekki hvern síðari pakka komins flæðis, og einmitt þess vegna framleiðir það að treysta á hana fyrir öryggi reglur sem virðast virka í prófun og bregðast undir álagi.

Hið gagnstæða er líka satt og kemur fólki á óvart: samþykkt einhvers staðar í einni grunnsíukeðju hefur ekkert vægi gegn síðari höfnun í annarri gildri keðju. Röð og umfang keðjunnar ráða úrslitum, ekki nærvera samþykktar í skránni.

Sannprófaðu nákvæmu innri þjónustuna

Prófaðu tiltekinn áfangastað og port sem þú heimilaðir, frá raunverulegum skjólstæðingi, og staðfestu að svarið komi til baka. Prófaðu svo eitthvað sem þú heimilaðir ekki og athugaðu að það fari ekki í gegn, því of breið regla stenst fyrstu prófun jafn vel og rétt regla. Beiðni sem fer aldrei frá skjólstæðingnum er líka ekki eldveggsniðurstaða, svo lestu teljarana til að sjá hvort pakkinn var yfirleitt metinn. Tvær prófanir og ein teljaralestur segja þér meira en heil síðdegi af lestri reglusafnsins.

nftables-viðmiðin skjalfesta meta ipsec, rt ipsec og áttarsértæk orðasambönd, og það er staðurinn til að athuga setningafræðina gagnvart uppsettu útgáfunni þinni. Og haltu umfanginu skýru: þetta er IPv4-dæmi, það segir ekkert um IPv6, og það gerir handahófskennda opinbera portasendingu ekki að hluta af VPN-þjónustunni.