Ķēdes nosaukums nav āķis: iptables pret nftables
Ķēde ir konteiners; āķis izlemj, vai kodols to apskata. Pirms noteikumu rediģēšanas salīdziniet iptables iebūvētās ķēdes ar nftables bāzes ķēdēm.
Abi ugunsmūri var filtrēt pārsūtīto VPN datplūsmu, un tie pievieno noteikumus pakešu ceļam dažādos veidos. iptables ir iebūvētas ķēdes tabulas iekšienē, tāpēc FORWARD pastāv kā nosaukts āķa punkts. nftables atdala ķēdes nosaukumu no tās tipa, āķa un prioritātes, kas nozīmē, ka parasta ķēde ar nosaukumu FORWARD neko nefiltrē. Abu modeļu salīdzinājums izskaidro, kāpēc ieraksts, kas vienā rīkā izskatās pareizs, otrā neietekmē neko.
Ķēde ir konteiners. Vai kodols to apskata, atkarīgs no ieviešanas un no tā, kā noteikumu kopa to pievieno.
Divi modeļi, divi atšķirīgi pievienojumi
iptables filter tabulā ir trīs iebūvētas ķēdes, INPUT, FORWARD un OUTPUT, un -N izveido lietotāja definētu ķēdi, kas darbojas tikai tad, kad uz to pārlec no vienas no tām. nftables rokasgrāmata tā vietā definē bāzes ķēdes, kas deklarē savu tipu, āķi un prioritāti, un parastas ķēdes, kas to nedara. Bāzes ķēdei var būt jebkurš nosaukums, un parasta ķēde ar nosaukumu FORWARD no sava apzīmējuma neiegūst nekādas īpašības. Tā ir visa atšķirība, un tā nav redzama pamācībā, kas parāda tikai noteikumu tekstu.
Saderības aizmugures pievieno otru iemeslu, kāpēc neizsecināt uzvedību no komandas nosaukuma. iptables dokumentācija norāda darbības, kas atšķiras zem iptables-nft, tāpēc uzskatiet vietējo nftables, iptables-nft un mantoto noteikumu kopu par trim sistēmām, nevis viena rakstības trim variantiem.
Lasiet kļūdu tās patiesajā kontekstā
Trūkstoša tabula, atļauju kļūme, nepieejama kodola iespēja un trūkstoša nosaukta ķēde ir četri dažādi atradumi, un tikai viens no tiem attiecas uz ķēdi. Pierakstiet rīka versiju, pieprasīto adrešu saimi un tabulu, tīkla nosaukumtelpu un pirmo precīzo kļūdu. Pēc tam pārbaudiet, kura komponente pārvalda noteikumu kopu: ugunsmūra serviss vai produkta pārvaldīts vārteja var ģenerēt savas ķēdes un secību. Vietējas ķēdes pievienošana tiem blakus atstāj pārvaldīto politiku neskartu un uzskaiti mulsinošāku.
Konteineru nosaukumtelpa var saturēt citādu noteikumu kopu nekā saimnieks, tāpēc komanda, kas palaista nepareizā kontekstā, nevar parādīt, kura ķēde redzēja pārsūtīto paketi. Pilnvaru paaugstināšana tāpēc, ka gaidītā ķēde nebija redzama, nav diagnostika.
Skaitītāji pierāda sasniegšanu, nevis spriedumu
Noteikumu skaitītāji parāda, ka noteikums tika sasniegts. Tie neparāda, ka vēlāks noteikums atļāva darbību, un nepierāda, ka visi alternatīvie ceļi tika noraidīti. Lasiet tos vienas nekaitīgas atļautas plūsmas laikā, kopā ar noteikumu secību un ķēdes pievienojumu, un uzskatiet tos par vienu novērojumu, nevis spriedumu. Skaitītājs, kas nav nulle, uz drop noteikuma nozīmē, ka datplūsma tam uzgāja; tas neko neizsaka par datplūsmu, kas neuzgāja.
Kodola IP pāradresācija ir pilnīgi atsevišķs iestatījums. Ķēdes pastāvēšana neiespējo pāradresāciju, un pazīstama apzīmējuma neesamība nenozīmē, ka pāradresācija apstājās.
Aprakstiet plūsmu, kuru vēlaties aizsargāt
Pierakstiet vienu klienta pieprasījumu pēc dekapsulācijas: tā avotu, galamērķi, adrešu saimi un to, vai tas beidzas pie vārtejas vai iet caur to. Vietējā servisa ievade un pārsūtītā datplūsma tiek novērota dažādos punktos, tāpēc tiem vajag dažādus noteikumus un dažādus testus. Tilta VPN gadījumā pārbaudiet arī tilta ceļu, jo IP līmeņa ķēde automātiski nekontrolē Ethernet kadrus.
Pirms attālinātas vārtejas maiņas saglabājiet neatkarīgu atkopšanas piekļuvi. Pēc tam apstipriniet paredzēto plūsmu un nepieciešamos noraidījumus saskaņā ar to pašu noteikumu kopu. Jauna tukša ķēde ar pazīstamu nosaukumu nav labojums.
Salīdzinājums beidzas ar vienu jautājumu: kuru āķi kodols patiešām izsauc šai paketei? Atbildiet uz to, un ķēdes nosaukums vairs nav svarīgs.