nftables-merke en VPN-roetering: watter reël wen werklik

’n Merk wat in nftables gestel is, behoort een klas verkeer deur die tonnel te stuur, en tog bly die verkeer deur die fisiese koppelvlak uitgaan. Die reëlversameling lyk op sigself korrek. Wat gewoonlik gebeur het, is dat iets anders dieselfde merk geskryf het, of dat die roeteringsreël ’n masker pas wat die nuwe waarde nie meer bevredig nie.

Kontrole 1: lees die reël wat die kern pas

Begin by die beleidsreël eerder as by die firewall. Die kern raadpleeg reëls in prioriteitsorde en die eerste passing bepaal die tabel. Lees die fwmark-waarde en die masker uit die reël self, en bevestig dan dat ’n pakket met die merk wat jy gestel het, dit werklik pas. ’n Reël wat ’n volledige 32-biswaarde verwag, sal nie ’n pakket pas wat slegs een bis dra nie.

Bevestig dan watter tabel daardie reël kies en wat die tabel bevat. ’n Reël wat na ’n leë tabel wys, veroorsaak ’n mislukte opsoeking, wat op baie stelsels beteken die pakket val deur na die volgende reël en uit die fisiese koppelvlak.

Twee opdragte besleg dit: die reëllijst en die roete-opsoeking vir die bestemming in daardie tabel.

Kontrole 2: pakketmerk of verbindingsmerk

nftables kan ’n merk op die pakket en ’n merk op die verbindingnasporingsinskrywing stel, en dit is verskillende objekte. Die pakketmerk leef vir die pakket se verwerkingsronde, terwyl die verbindingsmerk vir die vloei bly staan en doelbewus gekopieer moet word. Om een te stel en die ander te verwag, is ’n algemene halwe oplossing.

As die roeteringsreël op die pakketmerk staatmaak, doen die herstel van die verbindingsmerk later in die pad niks vir daardie besluit nie, want die besluit het reeds plaasgevind.

Bepaal watter objek die roeteringssein besit, en stel dit dan op die punt waar die roeteringsbesluit geneem word.

Kontrole 3: wie skryf nog daardie merk

WireGuard se eie gereedskap merk sy UDP-pakkette sodat die geënkripteerde vervoer nie terug na die tonnel geroteer word waaraan dit behoort nie. As jou reëlversameling ’n onverwante waarde aan dieselfde veld toeken, verdwyn daardie uitsluiting en probeer die tonnel se buitenste verkeer homself binnegaan. Die simptoom is ’n tonnel wat tot stand kom en dan ophou om verkeer deur te laat.

Merke word ook deur ander firewall-gereedskap, deur houer-netwerking en deur beleidsroetering vir ander doeleindes gebruik, so twee substelsels wat die hele veld skryf, is ’n konflik selfs wanneer elkeen afsonderlik korrek is.

Lys die skrywers voordat jy nog een byvoeg.

Kontrole 4: die masker bepaal wat jy behou

’n Merk is ’n 32-bisveld, en maskers is hoe verskeie eienaars dit deel. Om ’n waarde met ’n masker te stel, bewaar die bisse wat jy nie besit nie; om die hele veld te stel, vernietig almal anders se bisse. Lees die masker in elke reël wat die veld raak, insluitend dié wat jy nie geskryf het nie.

Dokumenteer die bis-toekenning langs die reëlversameling.

Die volgende persoon sal andersins ’n waarde hergebruik wat reeds ’n eienaar het, en ’n konflik hier lyk soos ’n roeteringsfout terwyl dit ’n adresseringsfout is. Die nftables-dokumentasie oor pakketmetadat beskryf die merkbewerkings self.

Kontrole 5: verifieer met ’n werklike vloei, nie ’n opsoeking nie

’n Gewone roete-opsoeking dra nie ’n merk nie, so dit kan ’n ander pad as die werklike pakket wys. Genereer die verkeer waaroor jy bekommerd is en kyk na die tellers, die verbindingnasporingsinskrywing en die koppelvlak waaruit dit werklik uitgaan. Toets beide die ingeslote klas en die uitgeslote klas, want ’n merk wat te breed is, breek die uitsluiting terwyl dit suksesvol lyk. As die ingeslote klas werk en die uitgeslote klas ook die tonnel binnegaan, is die merk te wyd eerder as te smal.

Vermy dit om verbindingtoestand te spoel om ’n verversing tydens ’n lewendige sessie af te dwing, aangesien nuwe en bestaande vloeie wettiglik verskillende paaie kan volg.

Teken die merk, die masker en die tabel op een plek aan, en die volgende wysiging word hersienbaar.