Ingen tun0? Match dekryptert IPsec i nftables med meta ipsec

Du ventar eit tunnelgrensesnitt, leitar etter det, og det er ingenting å matche i brannmuren. Det er normalt for ein policybasert gateway: den krypterte utvekslinga kjem inn på det fysiske grensesnittet, og den dekrypterte indre pakken som deretter vert videresend, vert òg observert som kommande inn på same grensesnittet. Det finst ingen tun0 fordi ingenting oppretta ein.

Den indre førespurnaden er framleis ein eigen pakke med si eiga kjelde, destinasjon og teneste, og kjernen veit kva tryggingsassosiasjon han kom ut av. Det er denne kunnskapen ein brannmurregel kan matche.

To pakkar, eitt grensesnitt

Sjå føre deg den inngåande retninga. Ein ESP- eller UDP-innkapsla pakke kjem inn, kjernen finn den samsvarande policyen, dekrypterer han og gjev den klare pakken vidare til videresendingsstien. Ein regel som berre ser på grensesnittnamnet, kan ikkje skilje den pakken frå annan trafikk som kjem inn på same leidning.

Det som skil han, er konteksten for den inngåande tryggingsstien som er knytt til pakken. nftables eksponerer han som meta ipsec exists, som er sant når pakken kom inn gjennom ein IPsec-tryggingssti. Kombiner han med klientpoolen, destinasjonen og tenesta, og regelen vert spesifikk nok til å vere trygg.

Å utelate konteksten er den vanlege feilen, og det er ein tryggingsfeil snarare enn ein kosmetisk. Ein regel som godtek alt som kjem frå klientpoolen, godtek like gjerne ein forfalska pakke frå det lokale nettet, fordi kjeldeadressa ikkje er prov for noko i seg sjølv. Konteksten for tryggingsstien er den billegaste måten å gjere kjelda meiningsfull. Skriv regelen med han frå starten i staden for å leggje han til etter ein revisjon.

Skriv videresendingsregelen

Føreset ein autentisert IPv4-fjerntilgangsteneste med klientar i 10.90.0.0/24 og éin godkjend destinasjon på 203.0.113.40. Eit regelfragment for den flyten ser slik ut.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Adressene og grensesnittet er døme som skal erstattast. Plasser det gjennomgåtte ekvivalenten i videresendingspolicyen før regelen som elles ville avvise flyten, og tøm ikkje eit eksisterande regelsett for å installere det; ein gateway er ikkje eit reinrom-eksperiment.

Uttrykket oifname er verdt å behalde. Det dokumenterer utgangsavgjerda og hindrar regelen i å matche i ei retning du ikkje hadde tenkt, noko som betyr noko på ein gateway med fleire vegar til internett. På ein testboks med éi oppstraumslinje verkar uttrykket overflødig, og det er nettopp derfor det vert fjerna før boksen får ei andre linje.

Løyva for den ytre utvekslinga er separate. Inngangsstien til gatewayen treng dei IKE- og ESP- eller UDP-innkapslingsportane han faktisk brukar, og desse løyva autoriserer ingenting om den dekrypterte pakken inni. Å blande dei to er måten ein fungerande tunnel endar opp med ein brannmur som videresender alt.

Inngåande kontekst er ikkje utgåande kontekst

Den same familien av uttrykk dekkjer den andre retninga med rt ipsec, som skildrar tryggingsassosiasjonen for utgåande trafikk som ein pakke vil bruke. Det svarar på eit anna spørsmål: ikkje kvar denne pakken kom frå, men om han vil vere verna på sin neste etappe.

Denne skilnaden betyr noko på ein gateway som både avsluttar éin tunnel og videresender inn i ein annan. Ein pakke kan kome inn dekryptert og likevel måtte gå ut kryptert, og ei godkjenning skriven berre for den inngåande konteksten seier ingenting om kravet for utgåande trafikk. Viss policyen krev den vernen, bør regelsettet uttrykkje det i staden for å gå ut frå at rutinga ordnar det.

Hald dei to spørsmåla i separate reglar slik at lesaren ser kva som vert handheva. Éin smart regel som sjekkar begge er vanskelegare å gjennomgå og mykje vanskelegare å feilsøkje når den eine halvdelen sluttar å matche. To reglar med teljarar fortel deg òg kva krav som feilar, noko éin kombinert regel aldri vil gjere.

NAT er ikkje ei brannmuravgjerd

Trafikk mot internett frå ein privat klientpool treng vanlegvis kjeldeomsetjing slik at svaret finn vegen tilbake. Men trafikk som er vald for ein annan utgåande IPsec-policy, må halde på det påkravde unntaket, og å maskere kvar privat kjelde utan å tenkje på neste vernavgjerd bryt det.

Ei godkjenning inne i ei NAT-kjede er heller ikkje ei generell løyve. NAT og filtrering har ulike oppgåver, og ei NAT-kjede granskar ikkje kvar seinare pakke i ein etablert flyt, og det er nettopp derfor det å rekne med henne for tryggleik gjev reglar som ser ut til å virke i test og feilar under last.

Det motsette er òg sant og overraskar folk: ei godkjenning ein stad i éi grunnleggjande filterkjede veg ingenting mot ei seinare avvising i ei anna gjeldande kjede. Rekkjefølgje og omfanget av kjeda avgjer resultatet, ikkje tilstadeveringa av ei godkjenning i fila.

Stadfest den nøyaktige indre tenesta

Test den spesifikke destinasjonen og porten du godkjende, frå ein ekte klient, og stadfest at svaret kjem tilbake. Test deretter noko du ikkje godkjende, og kontroller at det ikkje går gjennom, fordi ein for brei regel står den første testen like godt som ein korrekt. Ein førespurnad som aldri forlèt klienten, er heller ikkje eit brannmurresultat, så les teljarane for å sjå om pakken i det heile vart vurdert. To testar og éi teljaravlesing fortel deg meir enn ein heil ettermiddag med å lese regelsettet.

nftables-referansen dokumenterer meta ipsec, rt ipsec og dei retningsspesifikke uttrykka, og det er staden for å kontrollere syntaksen mot din installerte versjon. Og hald omfanget eksplisitt: dette er eit IPv4-døme, det seier ingenting om IPv6, og det gjer ikkje vilkårleg offentleg portvideresending til ein del av VPN-tenesta.