Kvifor nftables ikkje ser OpenVPN-trafikk mellom klientar

To klientar på éin server byter filer, overføringa lukkast, og kvar vidaresendingsregel du peikar mot tunnelen rapporterer null pakkar. Reglane er ikkje øydelagde, og kjeda står ikkje feil. Når vidaresending mellom partar er slått på, vert pakken levert inne i serverprosessen, og vertsstakken vert aldri rutaren, så brannmuren i kjernen har ingenting å telje. Å forstå denne delinga avgjer om du held på snarvegen eller byggjer stien på nytt gjennom kjernen.

Følg éin pakke gjennom serveren

I ein ruta tunnel gjev daemonen den dekrypterte pakka til kvar klient til tunneleininga. Derifrå rutar verten henne, vidaresendingskroken køyrer, og ein regel som samsvarar med tunneleininga kan telje eller forkaste trafikken. Det er stien dei fleste brannmureksempla føreset.

Snarvegen tek verten ut av midten. Den dekrypterte pakka til éin sesjon vert gjeven til ein annan sesjon inne i daemonen, og den indre pakka vert aldri send ut på tunneleininga og vert ikkje ruta av verten. Innpakka trafikk kryssar framleis det fysiske grensesnittet, så ei ytre fangst ser oppteken ut medan dei indre reglane er stille. Ei fangst teken på tunneleininga viser absolutt ingenting, noko som overraskar alle som ventar å sjå overføringa der. Den asymmetrien er den raskaste måten å kjenne att snarvegen utanfrå daemonen.

Teljartesten som avgjer kva sti som vart brukt

Fest ein teljar til regelen som burde gjelde, køyr ei overføring mellom to klientar som regelen burde blokkere, og les teljaren etterpå.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Viss overføringa lukkast og teljaren vert ståande på null, har kjernen aldri handsama desse pakkane, og inga regelendring endrar det. Gjenta den same testen mot ein teneste på serveren sjølv, for den straumen går faktisk gjennom vertsstakken, og teljaren flyttar seg. Det er samanlikninga av dei to resultata som gjev svaret.

To detaljar hindrar ei feil avlesing. Eit grensesnittnamn skrive i ei kjedetikett filtrerer ingenting i seg sjølv, fordi samsvar skjer på grensesnittfelt inne i reglane. Og eit brua lag-2-design oppfører seg annleis igjen: der deler klientane eitt kringkastingsdomene, så partsoppdaging er venta og ikkje ein ruterfeil.

Ein svitsj er ikkje ei tilgangsliste

Dette er delen som kostar ein ettermiddag. Vidaresending mellom partar er éin innstilling på eller av, og medan ho er på, er daemonen det einaste vidaresendingspunktet. Brannmuren til verten kan ikkje uttrykkje kven som kan nå kven, og filer per klient gjer ikkje svitsjen til ein policymatrise.

Viss du treng reglar per part, er valet mellom å gje opp snarvegen og å gje opp brannmuren til verten som kontroll. Å slå han av gjenopprettar kjernevidaresending, som krev IP-vidaresending på serveren og uttrykkelege reglar for straumane du vil ha. Å la han stå på tyder at policyen lever i konfigurasjonen til daemonen, som i praksis er alle partar eller ingen partar.

Åtskilde serverprosessar med eigne adressepuljar og portar er den gjennomførbare mellomvegen. Kvar prosess ber nøyaktig éi tilgangsavgjerd, så to grupper kan ha ulike reglar utan ein policymatrise. Verten kan rute mellom puljane når det er meininga, og då ser brannmuren desse straumane fordi dei kryssar verten. Kostnaden er ekstra portar, ekstra sertifikat og ein profil per gruppe.

Å velje vidaresendingspunktet

Vel kjernevidaresending når brannmuren er policymotoren, når du treng logging per straum, eller når rekneskap tel. Kostnaden er gjennomstrøyming gjennom vertsstakken og fleire reglar å vedlikehalde. Fordelen er at kvart eksisterande verktøy, frå teljarar til straumeksportørar, skildrar trafikken igjen. På ein liten server er den kostnaden usynleg; på eit travelt relay er han ikkje.

Vel vidaresending i prosessen når trafikk mellom partar anten er heilt tillaten eller heilt forboden og serveren er dimensjonert for det. Kostnaden er at teljarar, kødisiplinar og tilkoplingssporing ikkje lenger skildrar dei indre straumane; det er berre akseptabelt om ingen seinare byggjer på dei.

Uansett kva du vel, skriv det ned ved sida av brannmurreglane. Eit regelsett som ser ut til å tillate trafikk mellom partar medan daemonen uansett avgjer, villeder den neste som feilsøkjer ei mislukka overføring. Den som berre les reglane, vil tru at kjernen er porten.

Kva du bør kontrollere før du endrar reglar

Les konfigurasjonen serveren faktisk lasta, ikkje fila du hugsar å ha redigert, og stadfest om partvalet er til stades. Viss du endra det, må du syte for at tenesta lasta på nytt og ikkje berre skreiv om ei fil på disken.

Gjenta så testen med ein straum frå klient til server for å prove at regelen i det heile samsvarar, og kontroller rutene som vert pusha, for ei manglande rute ser frå klientsida nøyaktig ut som ein brannmurstopp. Endre rekkjefølgja på reglane først når du veit kva vidaresendingspunkt som eig avgjerda.