Hvorfor en OpenVPN-klientblokkeringsregel aldri treffer FORWARD

To klienter på samme OpenVPN-server kan nå hverandre selv om du har lagt til en DROP-regel for utvalget deres. Regelen sitter i FORWARD-kjeden, trafikken flyter tydelig, og telleren for den regelen blir stående på null. Den naturlige konklusjonen er at brannmuren er ødelagt. Oftere har pakken aldri kommet inn i kjeden i det hele tatt.

Det er to veier en peer-pakke kan ta gjennom en OpenVPN-server, og de bestemmes av konfigurasjonen, ikke av brannmuren. Å vite hvilken vei som brukes forteller deg om en vertsregel i det hele tatt er på riktig sted.

To veier en peer-pakke kan ta

Når alternativet for intern videresending er slått av, kommer en pakke fra klient A inn på tunnelgrensesnittet med en destinasjon innenfor klient Bs tildelte adresse. Serverens rutetabell sender den ut igjen gjennom samme tunnelgrensesnitt, fordi serveren eier ruten til Bs adresse. Det er en inn-og-ut-strøm gjennom verten, og IPv4-videresendingsveien vurderer den.

Når alternativet for intern videresending er slått på, matcher serverprosessen pakken mot en tilkoblet klient og skriver den tilbake til den klienten selv. Pakken håndteres inne i daemonen og kommer aldri tilbake i tunnelenheten, så vertens videresendingsvei hoppes helt over. OpenVPN 2.6-håndboken beskriver dette alternativet som intern klient-til-klient-videresending, og det er nettopp derfor en brannmurregel på verten ikke kan se den.

Det finnes en tredje variant i installasjoner som flytter datakanalen til en kjernemodul. Videresendingsbeslutningen og krypteringen flytter ut av brukerrommet, og om netfilter ser strømmen avhenger av hvordan overføringsveien er bygget. Anta aldri at et gammelt regelsett oppfører seg på en overført server som på en i brukerrommet. Bekreft modusen fra den kjørende konfigurasjonen, ikke fra pakkeversjonen.

Når telleren aldri beveger seg

En nullteller betyr at pakken ikke matchet den regelen på det punktet, og det er flere grunner. Den første er omveien ovenfor: trafikken nådde aldri kjeden. Den andre er en mismatch i grensesnitt, retning, kilde eller destinasjon, noe som er vanlig når utvalget er omnummerert og regelen fortsatt nevner det gamle prefikset.

Den tredje er plassering. En regel tidligere i kjeden kan godta strømmen før din DROP blir vurdert, og en regel senere kan være den som faktisk avgjør resultatet. Les kjeden i rekkefølge med tellerne synlige, og sjekk deretter hvilken regels teller som øker når du gjentar testen.

Kjør én kontrollert utveksling mellom to klienter hvis ekte adresser du har bekreftet fra serverens egen tilstand, ikke fra en lease du husker. Hvis den aktuelle telleren fortsatt ikke beveger seg, mistenk veien før du skriver om matchingen. Hvis den beveger seg men tilkoblingen fortsatt lykkes, blir droppet overstyrt senere og rekkefølgen er problemet. Det svaret avgjør om reparasjonen er en regelendring eller en topologiendring, så skaff det før du redigerer noe.

Å velge en grense som kan filtrere

Hvis policyen må bo i brannmuren på verten, sett trafikken der brannmuren kan se den. Å slå av intern videresending er den støttede måten å få peer-trafikk til å gå gjennom tunnelgrensesnittet og videresendingsveien, mot at hver peer-pakke går gjennom vertens stack.

Match deretter strømmen presist. Trafikk kommer inn på tunnelgrensesnittet og går ut på tunnelgrensesnittet, i begge retninger, så regler som bare ser på det fysiske grensesnittet vil ikke matche. Adressebaserte regler trenger det gjeldende utvalget, og de må ta høyde for returretningen like mye som den fremre.

Mange installasjoner tjener bedre på filtrering på klient- eller gruppenivå, der identiteten er kjent og policyen følger brukeren i stedet for en adresse som endres ved gjenoppkobling. Det er en annen mekanisme enn en vertskjede, og de to bør ikke blandes uten en klar grunn.

Ikke flytt et regelsett fra en gammel topologi gjennom en migrering uendret. Adresseutvalg, grensesnittnavn og videresendingsmoduser påvirker alle om en regel matcher, og en kopiert regel som pleide å virke er den mest villedende typen bevis. Start med strømmen du vil tillate og skriv regelen som matcher den.

Å teste isolasjon i stedet for å stole på en regel

Test det forbudte tilfellet og det tillatte tilfellet i samme kjøring. Start en ny tilkobling fra den ene klienten til den andre og bekreft at den feiler, og bekreft deretter at en tilkobling som burde være tillatt fortsatt virker. Hvis bare det første testes, ser en brannmur som blokkerer alt ut som en suksess.

Gjenta etter å ha lastet serverkonfigurasjonen på nytt og etter at en klient kobler til igjen, fordi intern videresending og utvalgstildelinger er kjøretidstilstand. Sjekk tellere i begge retninger, siden en regel som matcher én retning og ikke svaret gir delvis isolasjon som er vanskelig å legge merke til i en rask test.

Isolasjon er det observerte resultatet ved grensen som faktisk bærer strømmen. En DROP-regel et sted på verten er ikke bevis; en mislykket tilkobling pluss en flyttet teller på regelen som forårsaket den er det.