Slik låser du Linux-utgangen så ingenting lekker når VPN-en faller

Se for deg en medieboks på en hjemmelinje som bare skal nå internett gjennom en tunnel. Når tunnelen faller, bør applikasjonen stoppe i stedet for stille å fortsette over det fysiske grensesnittet. Å få den oppførselen er et brannmurproblem og ikke et ruteproblem, og forskjellen betyr noe fordi en rute kan erstattes av en omstart av daemonen, mens et filter blir der du satte det. Det følgende handler om hvordan pakkestien faktisk bestemmer, og deretter om hvordan unntakene som holder tunnelen tilkoblet, avgrenses.

Lokal utgang er en annen krok enn videresending

En pakke som forlater en applikasjon på maskinen, passerer utgangskroken; en pakke som maskinen ruter for en annen vert, passerer videresending. En policy som bare nevner forward, begrenser den andre og lar den første stå vidåpen, og derfor ser så mange utgangslåser riktige ut og gjør ingenting. Grensesnittmatching hører i samme regel: oifname "tun0" accept slipper gjennom trafikk som allerede er rutet ut gjennom tunnelen. Ruting og filtrering er også fortsatt separate beslutninger, så en uplink-rute kan finnes mens filteret avviser pakken. Det er denne delingen du regner med.

En gateway som videresender for andre enheter, trenger begge krokene. Å låse bare utgangen beskytter maskinen selv og lar hver klient lenger ned stå fritt til å lekke.

Skriv unntakslisten fra endepunktet og utover

Start med tunneleendepunktet: én destinasjonsadresse eller et lite godkjent sett, transportprotokollen og destinasjonsporten, for eksempel udp dport 1194 ip daddr 203.0.113.7 accept. Hvis klienten slår opp et vertsnavn, trenger den første DNS-utvekslingen sin egen regel avgrenset til resolveren og til port 53, ikke en blankofullmakt til den resolverens adresse. Hvert unntak bør nevne grunnen til at det finnes. En tillatelse for all UDP-trafikk til VPN-porten dekker langt mer enn den ene autentiserte tjenesten du hadde i tankene.

Første oppslag er der låsene vanligvis råtner. Et adressesett som oppdateres på en timer, trenger definert oppførsel når oppdateringen feiler, og den oppførselen kan ikke være å åpne linjen til det lykkes. Oppdater gjennom tunnelen mens tunnelen er oppe, og fall ellers tilbake til det siste kjente friske endepunktet.

Lokal administrasjon trenger samme behandling. Et administrasjonssubnett er ikke pålitelig fordi adressene er private, og en regel som stoler på det, inviterer en andre vei rundt låsen.

Grensesnittmatching er ikke bevis på en frisk tunnel

Regler som godtar alt som forlater tun0, antar at en pakke på det grensesnittet kom fra tunnelen. Grensesnittnavn gjenskapes, og et navn er ikke en kryptografisk identitet. Peeren kan også være borte mens grensesnittet blir stående, noe som gjør regelen til en svært overbevisende ikke-handling.

Tilkoblingssporing legger til en beslektet felle. En bred regel for etablerte tilkoblinger spiller av tillatelsen en flyt fikk tidligere, så en økt som startet før tunnelen falt, fortsetter etterpå. Begrens tilstandsbasert aksept til grensesnittene og adressene du faktisk mener, ellers har du bygget en lås som åpner seg selv. Inn- og utregler svarer også på forskjellige spørsmål, og å herde den ene mens du ignorerer den andre, lar maskinen være tilgjengelig i den retningen du ikke tenkte på.

Hva som overlever en daemon-krasj

Et filter som installeres av et skript som kjører etter at tunnelen kommer opp, forsvinner sammen med tunnelen, på nøyaktig det tidspunktet det var nødvendig. Last låsen ved oppstart og la daemonen bare administrere unntakene sine.

Å slette standardruten er heller ingen erstatning. Ruten er tilstand som daemonen eier og skriver om, og å fjerne den kan ta bort veien som trengs for å koble til på nytt. IPv6 trenger sin egen plan, fordi nabo-oppdagelse og ruterannonseringer er lenketjenester som må fortsette å virke mens vanlig trafikk er blokkert. DHCP hører i samme kategori. Skriv disse ned som unntak med et formål, i stedet for å oppdage dem senere som avbrudd.

Gjenopprettingsvei før utrulling

Test låsen slik den vil feile: start uten tunnel, drep daemonen, endre endepunktet og koble til på nytt. Hvert tilfelle bør stoppe applikasjonene og la gjenopprettingskanalen virke. Gjør det fra en konsoll, fordi et eksternt skall er økten som mest sannsynlig blir låst ute av din egen regel.

Sjekk deretter hva en vanlig applikasjon fortsatt kan nå, med en ufarlig destinasjon og en forespørsel du kan verifisere. Resultatet du vil ha, er en avvisning på linjen og suksess gjennom tunnelen, ikke en tvetydig tidsavbrudd som kan bety begge deler. Hold regelverket under samme eier som resten av brannmuren i stedet for å erstatte hele tabellen fra et skallskript. En policy der hver tillatelse kan begrunne seg selv, er mer verdt enn et langt regelverk ingen kan forklare.