Sådan låser du Linux' udgang, så intet lækker, når VPN'en falder

Forestil dig en medieboks på en hjemmeforbindelse, som kun skal nå internettet gennem en tunnel. Når tunnelen falder, bør applikationen gå i stå i stedet for stille at fortsætte over det fysiske interface. At få den adfærd er et firewallproblem snarere end et routingproblem, og forskellen betyder noget, fordi en rute kan erstattes af en genstart af daemonen, mens et filter bliver, hvor du satte det. Det følgende handler om, hvordan pakkestien faktisk beslutter, og derefter om, hvordan undtagelserne, der holder tunnelen genopkoblet, afgrænses.

Lokal output er en anden krog end videresendelse

En pakke, der forlader en applikation på maskinen, passerer output-krogen; en pakke, som maskinen router for en anden vært, passerer videresendelse. En politik, der kun nævner forward, begrænser den anden og lader den første stå vidt åben, og derfor ser så mange udgangslåse korrekte ud og gør intet. Interfacematchning hører i samme regel: oifname "tun0" accept slipper trafik igennem, som allerede er routet ud gennem tunnelen. Routing og filtrering er også fortsat separate beslutninger, så en uplink-rute kan eksistere, mens filteret afviser pakken. Den adskillelse er den mekanisme, du regner med.

En gateway, der videresender for andre enheder, har brug for begge kroge. At låse kun output beskytter maskinen selv og lader enhver klient længere nede stå frit til at lække.

Skriv undtagelseslisten fra endpointet og udad

Start med tunneleendpointet: én destinationsadresse eller et lille godkendt sæt, transportprotokollen og destinationsporten, for eksempel udp dport 1194 ip daddr 203.0.113.7 accept. Hvis klienten opløser et værtsnavn, har bootstrap-DNS-udvekslingen brug for sin egen regel afgrænset til resolveren og til port 53, ikke en blanket tilladelse til den resolvers adresse. Hver undtagelse bør nævne grunden til, at den findes. En tilladelse til al UDP-trafik til VPN-porten dækker langt mere end den ene autentificerede tjeneste, du havde i tankerne.

Bootstrap-opløsning er der, hvor låse normalt rådner. Et adressesæt, der opdateres på en timer, har brug for defineret adfærd, når opdateringen fejler, og den adfærd kan ikke være at åbne forbindelsen, indtil det lykkes. Opdater gennem tunnelen, mens tunnelen er oppe, og fald ellers tilbage til det sidste kendte gode endpoint.

Lokal administration har brug for samme behandling. Et administrationssubnet er ikke troværdigt, fordi dets adresser er private, og en regel, der stoler på det, inviterer en anden vej uden om låsen.

Interfacematchning er ikke bevis på en sund tunnel

Regler, der accepterer alt, der forlader tun0, antager, at en pakke på det interface kom fra tunnelen. Interfacenavne genskabes, og et navn er ikke en kryptografisk identitet. Peeren kan også være væk, mens interfacet bliver oppe, hvilket gør reglen til en meget overbevisende no-op.

Forbindelsessporing tilføjer en beslægtet fælde. En bred regel for etablerede forbindelser genafspiller den tilladelse, en flow fik tidligere, så en session, der startede før tunnelen faldt, fortsætter bagefter. Begræns tilstandsbaseret accept til de interfaces og adresser, du faktisk mener, ellers har du bygget en lås, der åbner sig selv. Input- og outputregler besvarer også forskellige spørgsmål, og at hærde den ene, mens du ignorerer den anden, efterlader maskinen tilgængelig i den retning, du ikke overvejede.

Hvad overlever et daemonnedbrud

Et filter, der installeres af et script, som kører efter tunnelen kommer op, forsvinder sammen med tunnelen, på præcis det tidspunkt, hvor det var nødvendigt. Indlæs låsen ved boot, og lad daemonen kun styre sine undtagelser.

At slette standardruten er heller ikke en erstatning. Ruten er tilstand, som daemonen ejer og omskriver, og at fjerne den kan tage den vej væk, der er nødvendig for at genoprette forbindelsen. IPv6 har brug for sin egen plan, fordi nabo-opdagelse og routerannoncering er linktjenester, som skal blive ved med at virke, mens almindelig trafik er blokeret. DHCP hører i samme kategori. Skriv disse ting ned som undtagelser med et formål i stedet for at opdage dem senere som nedbrud.

Gendannelsesvej før udrulning

Test låsen på den måde, den vil fejle: boot uden tunnel, dræb daemonen, skift endpoint, og genopret forbindelsen. Hvert tilfælde bør standse applikationerne og efterlade gendannelseskanalen fungerende. Gør det fra en konsol, fordi en fjernshell er den session, der mest sandsynligt bliver låst ude af din egen regel.

Tjek derefter, hvad en almindelig applikation stadig kan nå, med en uskadelig destination og en anmodning, du kan verificere. Det resultat, du vil have, er en afvisning på uplink og succes gennem tunnelen, ikke en tvetydig timeout, der kan betyde begge dele. Hold regelsættet under samme ejer som resten af firewallen i stedet for at erstatte hele tabellen fra et shellscript. En politik, hvor hver tilladelse kan begrunde sig selv, er mere værd end et langt regelsæt, som ingen kan forklare.