Ez dago tun0? Lotu nftables-en deskifratutako IPsec meta ipsec erabiliz

Tunel-interfaze bat espero duzu, bilatu egiten duzu, eta suebakian ez dago ezer lotzeko. Hori normala da politiketan oinarritutako atebide batean: truke zifratua interfaze fisikoan iristen da, eta gero birbidaltzen den barne pakete deskifratua ere interfaze berera iristen dela ikusten da. Ez dago tun0-ik, ezerk ez baitzuen sortu.

Barne eskaera oraindik bereizitako paketea da, bere jatorri, helmuga eta zerbitzuekin, eta nukleoak badaki zein segurtasun-elkartetatik atera zen. Ezagutza horixe da suebaki-arau batek lotu dezakeena.

Bi pakete, interfaze bat

Imajinatu sarrerako norabidea. ESP edo UDP-n kapsulatutako paketea iristen da, nukleoak dagokion politika aurkitzen du, deskifratu eta pakete argia birbidaltze-bideari ematen dio. Interfazearen izenari soilik begiratzen dion arauak ezin du pakete hori kable beretik iristen den beste edozein trafikotatik bereizi.

Hura bereizten duena paketeari atxikitako sarrerako segurtasun-bidearen testuingurua da. nftables-ek meta ipsec exists gisa erakusten du, eta hori egia da paketea IPsec segurtasun-bide batetik iritsi bada. Konbinatu bezero-taldearekin, helmugarekin eta zerbitzuarekin, eta araua nahikoa zehatza izango da segurua izateko.

Testuingurua alde batera uztea ohiko akatsa da, eta segurtasun-akatsa da, ez kosmetikoa. Bezero-taldetik datorren edozer onartzen duen arau batek sare lokaletik datorren pakete faltsutu bat ere berdin onartzen du, jatorri-helbidea berez ez baita ezeren froga. Segurtasun-bidearen testuingurua da jatorria esanguratsu egiteko modurik merkeena. Idatzi araua harekin hasieratik, auditoretza baten ondoren gehitu beharrean.

Idatzi birbidaltze-araua

Demagun 10.90.0.0/24 sarean bezeroak dituen IPv4 urruneko sarbide-zerbitzu autentifikatu bat eta 203.0.113.40 helbidean onartutako helmuga bat daudela. Fluxu horretarako arau-zatiak itxura hau du.

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

Helbideak eta interfazea ordezkatzeko adibideak dira. Jarri berrikusitako baliokidea birbidaltze-politikan fluxua bestela baztertuko lukeen arauaren aurretik, eta ez ezabatu lehendik dagoen arau-multzo bat instalatzeko; atebidea ez da gela zuriko esperimentu bat.

oifname terminoa mantentzea merezi du. Irteera-erabakia dokumentatzen du eta arauak asmoa ez zenukeen norabide batean bat egitea eragozten du, eta hori garrantzitsua da interneteko bide batzuk dituen atebide batean. Goiko esteka bakarreko proba-kutxa batean terminoa soberan dagoela ematen du, eta horrexegatik kentzen da kutxak bigarren esteka lortu aurretik.

Kanpoko trukerako baimenak bereiziak dira. Atebidearen sarrera-bideak benetan erabiltzen dituen IKE eta ESP edo UDP kapsulatze-portuak behar ditu, eta baimen horiek ez dute ezer baimetzen barruneko pakete deskifratuaren inguruan. Biak nahastea da lan egiten duen tunel bat dena birbidaltzen duen suebaki batekin amaitzeko bidea.

Sarrerako testuingurua ez da irteerako testuingurua

Adierazpen-familia berak beste norabidea estaltzen du rt ipsec erabiliz, pakete batek erabiliko duen irteerako segurtasun-elkartea deskribatzen baitu. Beste galdera bati erantzuten dio: ez pakete hau nondik etorri zen, baizik eta hurrengo zatian babestuta egongo den.

Bereizketa horrek garrantzia du tunel bat amaitzen eta beste batera birbidaltzen duen atebide batean. Pakete bat deskifratuta irits daiteke eta hala ere zifratuta irten behar du, eta sarrerako testuingururako soilik idatzitako onarpen batek ez du ezer esaten irteerako baldintzaren inguruan. Politikak babes hori eskatzen badu, arau-multzoak hura adierazi beharko luke bideratzeak konponduko duela suposatu beharrean.

Eduki bi galderak arau bereizietan, irakurleak zein betetzen ari den ikus dezan. Biak egiaztatzen dituen arau azkar bakar bat zailagoa da berrikusten eta askoz zailagoa arazten bere erdi batek bat egiteari uzten dionean. Kontagailuak dituzten bi arauk zein baldintza ari den huts egiten ere esaten dute, arau konbinatu batek inoiz egingo ez duena.

NAT ez da suebaki-erabakia

Bezero-talde pribatu batetik internet alderako trafikoak jatorriaren itzulpena behar izan ohi du, erantzunak itzulerako bidea aurki dezan. Baina irteerako beste IPsec politika baterako hautatutako trafikoak bere salbuespen beharrezkoa mantendu behar du, eta jatorri pribatu guztiak maskaratzeak hurrengo babes-erabakian pentsatu gabe hori apurtzen du.

NAT kate baten barruko onarpena ere ez da baimen orokorra. NAT-ek eta iragazketak lan desberdinak dituzte, eta NAT kate batek ez du finkatutako fluxu baten ondorengo pakete bakoitza aztertzen, eta horrexegatik ematen du segurtasunerako harengan fidatzeak proban funtzionatzen duela diruditen eta karga-egoeran huts egiten duten arauak.

Alderantzizkoa ere egia da eta jendea harritzen du: iragazketa-oinarrizko kate bateko nonbaiteko onarpen batek ez du pisurik beste kate aplikagarri bateko ondorengo bazterketaren aurrean. Katearen ordenak eta hedadurak erabakitzen dute emaitza, ez fitxategian onarpen bat egoteak.

Egiaztatu barneko zerbitzu zehatza

Probatu baimendu duzun helmuga eta portu zehatzak, benetako bezero batetik, eta egiaztatu erantzuna itzultzen dela. Gero probatu baimendu ez duzun zerbait eta egiaztatu ez dela pasatzen, arau zabalegia bat egoki batek bezain ondo pasatzen baita lehen probatik. Bezeroa inoiz uzten ez duen eskaera ere ez da suebakiaren emaitza, beraz irakurri kontagailuak paketea ebaluatu zen ala ez ikusteko. Bi probak eta kontagailu-irakurketa batek arau-multzoa irakurtzen emandako arratsalde oso batek baino gehiago esango dizute.

nftables erreferentziak meta ipsec, rt ipsec eta norabidearen araberako adierazpenak dokumentatzen ditu, eta horixe da sintaxia zure instalatutako bertsioarekin egiaztatzeko tokia. Eta eduki irismena argi: hau IPv4 adibidea da, ez du ezer esaten IPv6-ri buruz, eta ez du portu publikoen birbidaltze arbitrarioa VPN zerbitzuaren parte bihurtzen.