nftables-marken en VPN-routing: hokker regel wint echt

In mark dy’t yn nftables set is, heart ien klasse ferkear troch de tunnel te stjoeren, en it ferkear bliuwt troch de fysike ynterface nei bûten gean. De regelset liket op himsels korrekt. Wat ornaris bard is, is dat eat oars deselde mark skreaun hat, of dat de routingsregel oerienkomt mei in masker dat de nije wearde net mear foldocht.

Kontrôle 1: lês de regel dêr’t de kern mei oerienkomt

Begjin by de beliedsregel ynstee fan de firewall. De kern rieplachtet regels yn prioriteitsfolchoarder en de earste oerienkomst beslút de tabel. Lês de fwmark-wearde en it masker út de regel sels, en befêstigje dan dat in pakket mei de mark dy’t jo set hawwe der echt mei oerienkomt. In regel dy’t in folsleine 32-bits wearde ferwachtet, sil net oerienkomme mei in pakket dat mar ien bit draacht.

Befêstigje dan hokker tabel dy regel kiest en wat de tabel befettet. In regel dy’t nei in lege tabel wiist, produsearret in mislearre syktocht, wat op in protte systemen betsjut dat it pakket trochfalt nei de folgjende regel en út ’e fysike ynterface.

Twa opdrachten besljochtsje dit: de regellist en de rûtesyktocht foar de bestimming yn dy tabel.

Kontrôle 2: pakketmark of ferbiningmark

nftables kin in mark op it pakket en in mark op de ferbiningsfolchynskriuwing sette, en dat binne ferskate objekten. De pakketmark libbet foar de ferwurkingsgong fan it pakket, wylst de ferbiningmark foar de stream bliuwt en bewust kopiearre wurde moat. Ien sette en de oare ferwachtsje is in gewoane heale oplossing.

As de routingsregel op ’e pakketmark leaut, docht it werstellen fan ’e ferbiningmark letter yn it paad neat foar dat beslút, om’t it beslút al nommen is.

Beslis hokker objekt it routingssignaal besit, en set it dan op it punt dêr’t it routingsbeslút nommen wurdt.

Kontrôle 3: wa skriuwt dy mark noch mear

WireGuard syn eigen ark markearret syn UDP-pakketten sadat it fersifere ferfier net werom rutearre wurdt nei de tunnel dêr’t it by heart. As jo regelset in net besibbe wearde oan itselde fjild jout, ferdwynt dy útsluting en besiket it bûtenferfier fan ’e tunnel himsels yn te gean. It symptoom is in tunnel dy’t oprjochte wurdt en dan ophâldt mei ferkear troch te litten.

Marken wurde ek brûkt troch oar firewall-ark, troch container-netwurken en troch beliedsrouting foar oare doelen, dus twa subsystemen dy’t it hiele fjild skriuwe is in konflikt sels as elk apart korrekt is.

List de skriuwers op foardat jo noch ien tafoegje.

Kontrôle 4: it masker beslút wat jo hâlde

In mark is in 32-bits fjild, en maskers binne hoe’t ferskate eigners it diele. In wearde mei in masker sette behâldt de bits dy’t jo net besitte; it hiele fjild sette ferneatiget dy fan alle oaren. Lês it masker yn elke regel dy’t it fjild rekket, ek yn dy’t jo net skreaun hawwe.

Dokumintearje de bitferdieling njonken de regelset.

Oars sil de folgjende persoan in wearde wergebrûke dy’t al in eigner hat, en in konflikt hjir liket op in routingflater wylst it in adressearringsflater is. De nftables-dokumintaasje oer pakketmetadata beskriuwt de markbewurkingen sels.

Kontrôle 5: ferifiearje mei in echte stream, net mei in syktocht

In gewoane rûtesyktocht draacht gjin mark, dus kin in oar paad sjen litte as it echte pakket. Generearje it ferkear dêr’t jo om jouwe en observearje de tellers, de ferbiningsfolchynskriuwing en de ynterface dêr’t it echt út giet. Test sawol de ynbegrepen klasse as de útsletten klasse, want in mark dy’t te breed is brekt de útsluting wylst it suksesfol liket. As de ynbegrepen klasse wurket en de útsletten klasse giet ek de tunnel yn, is de mark te breed en net te smel.

Foarkom dat jo ferbiningstastân flushje om in ferfarsking ôf te twingjen yn in libbene sesje, om’t nije en besteande streams wetlik ferskate paden nimme kinne.

Skriuw de mark, it masker en de tabel op ien plak, en de folgjende bewurking wurdt neisjoenber.