Slik låser du Linux-utgangen så ingenting lek når VPN-en fell

Sjå føre deg ein medieboks på ei heimelinje som berre skal nå internett gjennom ein tunnel. Når tunnelen fell, bør applikasjonen stoppe i staden for stille å halde fram over det fysiske grensesnittet. Å få den åtferda er eit brannmurproblem og ikkje eit ruteproblem, og skilnaden tel fordi ei rute kan erstattast av ein omstart av daemonen, medan eit filter blir der du sette det. Det følgjande handlar om korleis pakkestien faktisk avgjer, og deretter om korleis unntaka som held tunnelen tilkopla, blir avgrensa.

Lokal utgang er ein annan krok enn videresending

Ein pakke som forlèt ein applikasjon på maskinen, passerer utgangskroken; ein pakke som maskinen rutar for ein annan vert, passerer videresending. Ein policy som berre nemner forward, avgrensar den andre og lèt den første stå vidopen, og difor ser så mange utgangslåsar riktige ut og gjer ingenting. Grensesnittmatching høyrer i same regel: oifname "tun0" accept slepp gjennom trafikk som alt er ruta ut gjennom tunnelen. Ruting og filtrering er òg framleis skilde avgjerder, så ei uplink-rute kan finnast medan filteret avviser pakken. Det er denne delinga du reknar med.

Ein gateway som videresender for andre einingar, treng begge krokane. Å låse berre utgangen verner maskinen sjølv og lèt kvar klient lenger nede stå fritt til å leke.

Skriv unntakslista frå endepunktet og utover

Start med tunneleendepunktet: éin destinasjonsadresse eller eit lite godkjent sett, transportprotokollen og destinasjonsporten, til dømes udp dport 1194 ip daddr 203.0.113.7 accept. Viss klienten slår opp eit vertsnamn, treng den første DNS-utvekslinga si eiga regel avgrensa til resolvaren og til port 53, ikkje ein blankofullmakt til adressa til den resolvaren. Kvart unntak bør nemne grunnen til at det finst. Ei tillating for all UDP-trafikk til VPN-porten dekkjer langt meir enn den eine autentiserte tenesta du hadde i tankane.

Første oppslag er der låsane vanlegvis råtner. Eit adressesett som blir oppdatert på ein timer, treng definert åtferd når oppdateringa feilar, og den åtferda kan ikkje vere å opne linja til det lykkast. Oppdater gjennom tunnelen medan tunnelen er oppe, og fall elles tilbake til det siste kjende friske endepunktet.

Lokal administrasjon treng same handsaming. Eit administrasjonssubnett er ikkje påliteleg fordi adressene er private, og ein regel som stolar på det, inviterer ein andre veg rundt låsen.

Grensesnittmatching er ikkje prov på ein frisk tunnel

Reglar som godtar alt som forlèt tun0, føreset at ein pakke på det grensesnittet kom frå tunnelen. Grensesnittnamn blir attskapte, og eit namn er ikkje ein kryptografisk identitet. Peeren kan òg vere borte medan grensesnittet blir ståande, noko som gjer regelen til ei svært overtydande ikkje-handling.

Tilkoplingssporing legg til ei skyld felle. Ein brei regel for etablerte tilkoplingar spelar av tillatinga ein flyt fekk tidlegare, så ei økt som starta før tunnelen fall, held fram etterpå. Avgrens tilstandsbasert aksept til grensesnitta og adressene du faktisk meiner, elles har du bygd ein lås som opnar seg sjølv. Inn- og utreglar svarar òg på ulike spørsmål, og å herde den eine medan du ignorerer den andre, lèt maskinen vere tilgjengeleg i den retninga du ikkje tenkte på.

Kva som overlever ein daemon-krasj

Eit filter som blir installert av eit skript som køyrer etter at tunnelen kjem opp, forsvinn saman med tunnelen, på nøyaktig det tidspunktet det var naudsynt. Last låsen ved oppstart og la daemonen berre administrere unntaka sine.

Å slette standardruta er heller inga erstatning. Ruta er tilstand som daemonen eig og skriv om, og å fjerne ho kan ta bort vegen som trengst for å kople til på nytt. IPv6 treng sin eigen plan, fordi nabo-oppdaging og ruterannonseringar er lenketenester som må halde fram med å verke medan vanleg trafikk er blokkert. DHCP høyrer i same kategori. Skriv desse ned som unntak med eit føremål, i staden for å oppdage dei seinare som avbrot.

Gjenopprettingsveg før utrulling

Test låsen slik han vil feile: start utan tunnel, drep daemonen, endre endepunktet og kople til på nytt. Kvart tilfelle bør stoppe applikasjonane og la gjenopprettingskanalen verke. Gjer det frå ein konsoll, fordi eit eksternt skal er økta som mest sannsynleg blir låst ute av din eigen regel.

Sjekk deretter kva ein vanleg applikasjon framleis kan nå, med ein ufarleg destinasjon og ein førespurnad du kan verifisere. Resultatet du vil ha, er ei avvising på linja og suksess gjennom tunnelen, ikkje ein tvitydig tidsavbrot som kan bety begge delar. Hald regelverket under same eigar som resten av brannmuren i staden for å erstatte heile tabellen frå eit skalskript. Ein policy der kvar tillating kan grunngje seg sjølv, er meir verdt enn eit langt regelverk ingen kan forklare.