Blokkearje ien bestimmingsberik foar elke VPN-klantpool
Ien nftables-regel kin in bestimmingsprefiks wegerje foar in talitten VPN-pool sûnder it eigen ferkear fan de gateway oan te reitsjen. Pas de hook en de posysje.
Ien regel kin in talitten VPN-pool by in bestimmingsberik wei hâlde sûnder eat oars te fersteuren dat de gateway docht. De regel sels is koart; de dielen dy't beslute oft er wurket, binne de hook dêr't er yn libbet en syn posysje yn 'e keatling. Krijst dy twa ferkeard, dan krijst in firewall dy't korrekt liket en him inkonsistint draacht. Begjin by wat it pakket docht as de regel it sjocht.
Wat de regel eins oerienkomt
De regel komt trije dingen tagelyk oerien: in ynfierynterface, in boarneprefiks en in bestimmingsprefiks. Alle trije moatte wier wêze foar't de drop jildt, en dat hâldt him smel. It lêzen as ien útdrukking is makliker as it lêzen as trije aparte beliedsregels.
De interface-oerienkomst is wat trochstjoerd klantferkear fan 'e eigen ferbiningen fan 'e gateway ûnderskiedt. Sûnder dy soe in regel dy't allinnich de boarnepool neamt, ek pakketten reitsje dy't de gateway sels fan dat adres ôf makket, as er dat ea docht. It boarneprefiks beheint it belied ta talitten klanten, en it bestimmingsprefiks beheint it ta ien berik. Lês de regel as in krusing en net as in list.
Skriuw de trije wearden op foar'tsto eat bewurkest: de namme fan 'e tunnelinterface, de pool dy't de server útdielt, en it prefiks datsto wegerje wolst. In typflater yn ien fan harren jout in regel dy't skjin parsearre wurdt en neat beskermet. Hâld dy trije wearden yn 'e feroaringslog njonken de regel.
De hook beslút foar wa't de regel jildt
In netfilter-keatling is oan in hook fêstmakke, en de hook beslút hokker pakketten de keatling ea sjocht. De forward-hook sjocht ferkear dat troch de gateway rûte wurdt, en dat is krekt klant-nei-bestimming-ferkear. Al it oare yn 'e keatling is op in oar publyk rjochte.
De input-hook sjocht ferkear dat oan 'e gateway sels adressearre is, dat in regel dy't dêr pleatst wurdt regelet tagong ta syn eigen tsjinsten ynstee fan transit. De output-hook sjocht ferkear dat de gateway sels makket, en dat is it tsjinoerstelde fan wat in klantpoolbelied nedich hat. Keatlingnammen binne willekeurige labels dy't keazen binne troch wa't de regels skreaun hat, dat lied de hook net fan 'e namme ôf. Kontrolearje wêr't de keatling fêstmakke is foar'tsto oannimst wat er oerienkomme kin.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
It lêzen fan 'e oansluting is in kontrôle fan ien rigel dy't foarkomt dat in regel yn in keatling bedarret dy't it pakket nea sjocht.
Pleatstje de regel foar de brede accept
Regels wurde yn folchoarder beoardiele en it earste oardiel wint. In brede accept earder yn 'e keatling einiget de beoardieling foar de pakketten dy't er oerienkomt, dat in drop dy't letter tafoege wurdt rint foar harren nea. Dy folchoarderregel is de hiele reden wêrom't in korrekt likende regel gjin effekt hawwe kin.
Foegje de regel foar de accept yn ynstee fan him oan 'e ein ta te foegjen. As de keatling al in algemiene accept foar de tunnelinterface befettet, moat de nije regel dêrfoar komme, oars is er allinnich fersiering. Kontrolearje de folchoarder dy't derút komt en net it bestân datsto bewurke hast, want in regelbondel dy't út ferskate bestannen gearstald is, kin miskien mei gjinien dêrfan oerienkomme. Befêstigje it dan mei in testpakket út 'e pool.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confIt tredde kommando parsearret it bestân sûnder it ta te passen, wat syntaksfouten fangt foar't se in útfal wurde. Pas it ta mei in weromsetplan, want in ferkearde regel yn in forward-keatling kin de tunnel trochsnije dêr'tsto oer wurkest.
Besteande streamen jouwe neat om dyn nije regel
In conntrack-ynskriuwing makke foar't de regel bestie, bliuwt oerienkomme mei de eardere accept. Dêrom liket in nije drop soms te wurkjen foar nije ferbiningen en docht er neat foar dy't test wurdt.
Lês de steatoerienkomst boppe-oan de keatling. As dy established- en related-ferkear foar dyn regel akseptearret, bliuwt elke stream dy't al rint trochgean oant er ticht giet. Dat is meastentiids it gedrach datsto foar in needregel wolst, en it is betiizjend assto in direkte snij ferwachtest. Beslút hokker effektsto wolst foar'tsto útrolst. In test dy't in iepen ferbining werbrûkt, fertelt dy it ferkearde ferhaal.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'It earste kommando lit sjen oft der in stream is, en it twadde oft in betide steatregel him noch akseptearret. Beide binne allinnich-lêze en feilich om te rinnen yn in ynsidint.
Wat dizze regel net is
De regel is gjin swarte list fan domeinen, in IPv6-belied of in beheining foar ien inkeld applikaasje-account.
Elk fan dy hat syn eigen meganisme nedich. In domeinblokkade moat nammen oplosse, wat in pakketfilter net docht. IPv6-ferkear hat syn eigen oerienkomst nedich, want in ip-útdrukking seit neat oer ip6-pakketten. In beheining op applikaasjenivo heart by de tsjinst of by in autentisearre proxy en net by in prefiksoerienkomst. Krekt it apart hâlden fan dy easken foarkomt dat ien smelle regel fjouwer taken dien krijt.
It kontrakt dat dizze regel leveret is presys: ferkear fan in talitten pool nei ien bestimmingsprefiks wurdt wegere, wylst besibbe gateway-ferkear syn besteande belied hâldt. Skriuw dy sin njonken de regel, dan wit de folgjende persoan wêr't er foar wie.