Blokkeer een bestemmingsreeks vir elke VPN-kliëntpoel
Een nftables-reël kan 'n bestemmingsvoorvoegsel vir 'n toegelate VPN-poel weier sonder om die poort se eie verkeer te raak. Pas die haak en die posisie.
Een reël kan 'n toegelate VPN-poel by 'n bestemmingsreeks weghou sonder om enigiets anders wat die poort doen te steur. Die reël self is kort; die dele wat besluit of dit werk, is die haak waarin dit leef en sy posisie in die ketting. Kry jy daardie twee verkeerd, dan kry jy 'n vuurmuur wat korrek lyk en onbestendig optree. Begin by wat die pakkie doen wanneer die reël dit sien.
Wat die reël werklik pas
Die reël pas drie dinge gelyktydig: 'n invoerkakking, 'n bronvoorvoegsel en 'n bestemmingsvoorvoegsel. Al drie moet waar wees voordat die drop geld, en dit is wat dit smal hou. Om dit as een uitdrukking te lees is makliker as om dit as drie afsonderlike beleide te lees.
Die koppelvlak-passing is wat doorgestuurde kliëntverkeer van die poort se eie verbindings onderskei. Daarsonder sou 'n reël wat net die bronpoel noem, ook pakkies raak wat die poort self vanaf daardie adres genereer, as dit ooit gebeur. Die bronvoorvoegsel beperk die beleid tot toegelate kliënte, en die bestemmingsvoorvoegsel beperk dit tot een reeks. Lees die reël as 'n snyding eerder as as 'n lys.
Skryf die drie waardes neer voordat jy iets wysig: die tonnelkoppelvlak se naam, die poel wat die bediener uitdeel, en die voorvoegsel wat jy wil weier. 'n Tikfout in enigeen van hulle lewer 'n reël wat skoon ontleed en niks beskerm nie. Hou daardie drie waardes in die veranderingsrekord langs die reël.
Die haak bepaal op wie die reël van toepassing is
'n netfilter-ketting word aan 'n haak gekoppel, en die haak bepaal watter pakkies die ketting ooit sien. Die doorstuurhaak sien verkeer wat deur die poort gerouteer word, en dit is wat kliënt-na-bestemming-verkeer is. Alles anders in die ketting is op 'n ander gehoor gemik.
Die invoerhaak sien verkeer wat aan die poort self gerig is, so 'n reël wat daar geplaas word, beheer toegang tot sy eie dienste eerder as deurgang. Die uitvoerhaak sien verkeer wat die poort self genereer, wat die teenoorgestelde is van wat 'n kliëntpoelbeleid nodig het. Kettingname is willekeurige etikette wat deur die skrywer van die reëlstel gekies is, so moenie die haak uit die naam aflei nie. Kontroleer waar die ketting gekoppel is voordat jy aanvaar wat dit kan pas.
| 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 |
Om die koppeling te lees is 'n eenreëlkontrole wat verhoed dat 'n reël in 'n ketting beland wat die pakkie nooit sien nie.
Plaas die reël voor die breë aanvaarding
Reëls word in volgorde geëvalueer, en die eerste uitspraak wen. 'n Breë aanvaarding vroeër in die ketting beëindig die evaluering vir die pakkies wat dit pas, so 'n drop wat daarna bygevoeg word, loop nooit vir hulle nie. Daardie ordeningsreël is die hele rede waarom 'n korrek-lykende reël geen effek kan hê nie.
Voeg die reël voor die aanvaarding in eerder as om dit aan die einde by te voeg. As die ketting reeds 'n algemene aanvaarding vir die tonnelkoppelvlak bevat, moet die nuwe reël dit voorafgaan, anders is dit net versiering. Kontroleer die resulterende volgorde eerder as die lêer wat jy gewysig het, want 'n reëlstel wat uit verskeie lêers saamgestel is, stem dalk nie met enige een ooreen nie. Bevestig dan met 'n toetspakkie uit die poel.
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.confDie derde opdrag ontleed die lêer sonder om dit toe te pas, wat sintaksfoute vang voordat hulle 'n onderbreking word. Pas toe met 'n terugrolplan, want 'n foutiewe reël in 'n doorstuurketting kan die tonnel sny waarmee jy werk.
Bestaande vloei steur hom nie aan jou nuwe reël nie
'n conntrack-inskrywing wat geskep is voordat die reël bestaan het, pas steeds die vroeëre aanvaarding. Dit is waarom 'n nuwe drop soms vir vars verbindings te werk lyk en niks doen vir die een wat getoets word nie.
Lees die toestandpassing boaan die ketting. As dit gevestigde en verwante verkeer voor jou reël aanvaar, hou elke vloei wat reeds aan die gang is, aan vloei totdat dit sluit. Dit is gewoonlik die gedrag wat jy vir 'n noodreël wil hê, en dit is verwarrend wanneer jy 'n onmiddellike snit verwag. Besluit watter effek jy wil hê voordat jy ontplooi. 'n Toets wat 'n oop verbinding hergebruik, sal jou die verkeerde verhaal vertel.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'Die eerste opdrag wys of 'n vloei bestaan, en die tweede wys of 'n vroeë toestandreël dit aanhou aanvaar. Albei is lees-alleen en veilig om tydens 'n voorval te hardloop.
Wat hierdie reël nie is nie
Die reël is nie 'n domeinswartlys, 'n IPv6-beleid of 'n beperking op 'n individuele toepassingrekening nie.
Elkeen van daardie dinge het sy eie meganisme nodig. 'n Domeinblokkade moet name oplos, wat 'n pakkiefilter nie doen nie. IPv6-verkeer het sy eie passing nodig, want 'n ip-uitdrukking sê niks oor ip6-pakkies nie. 'n Beperking op toepassingsvlak hoort by die diens of by 'n geauthentiseerde volmag, nie by 'n voorvoegselpassing nie. Om daardie vereistes apart te hou, is wat verhoed dat een smal reël gevra word om vier take te doen.
Die kontrak wat hierdie reël lewer, is presies: verkeer van 'n toegelate poel na een bestemmingsvoorvoegsel word geweier, terwyl onverwante poortverkeer sy bestaande beleid behou. Skryf daardie sin langs die reël, dan sal die volgende persoon weet waarvoor dit was.