Hvorfor en OpenVPN-klientblokeringsregel aldrig rammer FORWARD

To klienter på samme OpenVPN-server kan nå hinanden, selvom du har tilføjet en DROP-regel for deres pool. Reglen sidder i FORWARD-kæden, trafikken flyder tydeligt, og tælleren for den regel bliver på nul. Den naturlige konklusion er, at firewallen er i stykker. Oftere er pakken slet ikke kommet ind i kæden.

Der er to veje, en peer-pakke kan tage gennem en OpenVPN-server, og de bestemmes af konfigurationen, ikke af firewallen. At vide, hvilken vej der bruges, fortæller dig, om en værtsregel overhovedet er det rigtige sted.

To veje en peer-pakke kan tage

Når indstillingen til intern videresendelse er slået fra, ankommer en pakke fra klient A på tunnelinterfacet med en destination inden for klient B's tildelte adresse. Serverens rutetabel sender den ud igen gennem det samme tunnelinterface, fordi serveren ejer ruten til B's adresse. Det er en ind-og-ud-strøm gennem værten, og IPv4-videresendelsesvejen evaluerer den.

Når indstillingen til intern videresendelse er slået til, matcher serverprocessen pakken med en tilsluttet klient og skriver den tilbage til den klient selv. Pakken håndteres inde i daemonen og kommer aldrig tilbage i tunnel-enheden, så værtens videresendelsesvej springes helt over. OpenVPN 2.6-manualen beskriver denne indstilling som intern klient-til-klient-videresendelse, og det er netop derfor, en firewallregel på værten ikke kan se den.

Der findes en tredje variant i installationer, der flytter datakanalen til et kernel-modul. Videresendelsesbeslutningen og krypteringen flytter ud af brugerrummet, og om netfilter ser strømmen, afhænger af, hvordan offload-vejen er bygget. Antag aldrig, at et gammelt regelsæt opfører sig på en server med offload som på en i brugerrummet. Bekræft tilstanden ud fra den kørende konfiguration, ikke ud fra pakkeversionen.

Når tælleren aldrig flytter sig

En nul-tæller betyder, at pakken ikke matchede den regel på det punkt, og der er flere grunde. Den første er omvejen ovenfor: trafikken nåede aldrig kæden. Den anden er uoverensstemmelse i interface, retning, kilde eller destination, hvilket er almindeligt, når poolen er omnummereret, og reglen stadig nævner det gamle præfiks.

Den tredje er placering. En regel tidligere i kæden kan acceptere strømmen, før din DROP bliver evalueret, og en regel senere kan være den, der faktisk afgør resultatet. Læs kæden i rækkefølge med synlige tællere, og tjek derefter, hvilken regels tælling der stiger, når du gentager testen.

Kør én kontrolleret udveksling mellem to klienter, hvis rigtige adresser du har bekræftet ud fra serverens egen tilstand, ikke ud fra en lease, du husker. Hvis den relevante tæller stadig ikke flytter sig, så mistænk vejen, før du omskriver matchningen. Hvis den flytter sig, men forbindelsen stadig lykkes, bliver drop'et overtrumfet senere, og rækkefølgen er problemet. Det svar afgør, om reparationen er en regelændring eller en topologiændring, så få det, før du redigerer noget.

At vælge en grænse, der kan filtrere

Hvis politikken skal bo i værtens firewall, sæt trafikken der, hvor firewallen kan se den. At slå intern videresendelse fra er den understøttede måde at få peer-trafik til at passere tunnelinterfacet og videresendelsesvejen, på bekostning af at sende hver peer-pakke gennem værtens stak.

Match derefter strømmen præcist. Trafik ankommer på tunnelinterfacet og forlader tunnelinterfacet i begge retninger, så regler, der kun ser på det fysiske interface, matcher ikke. Adressebaserede regler har brug for den aktuelle pool, og de skal tage højde for returretningen såvel som den fremadgående.

Mange installationer er bedre tjent med at filtrere på klient- eller gruppeniveau, hvor identiteten er kendt, og politikken følger brugeren i stedet for en adresse, der ændrer sig ved genopkobling. Det er en anden mekanisme end en værtskæde, og de to bør ikke blandes uden en klar grund.

Flyt ikke et gammelt topologis regelsæt uændret gennem en migrering. Adressepuljer, interfacenavne og videresendelsestilstande påvirker alle, om en regel matcher, og en kopieret regel, der plejede at virke, er den mest vildledende form for bevis. Start med den strøm, du vil tillade, og skriv den regel, der matcher den.

At teste isolering i stedet for at stole på en regel

Test det forbudte tilfælde og det tilladte tilfælde i samme kørsel. Start en ny forbindelse fra den ene klient til den anden, og bekræft, at den fejler, og bekræft derefter, at en forbindelse, der burde være tilladt, stadig virker. Hvis kun det første testes, ser en firewall, der blokerer alt, ud som en succes.

Gentag efter genindlæsning af serverkonfigurationen og efter en klient genopkobler, fordi intern videresendelse og puljetildelinger er runtime-tilstand. Kontrollér tællere i begge retninger, da en regel, der matcher én retning og ikke svaret, giver delvis isolering, som er svær at bemærke i en hurtig test.

Isolering er det observerede resultat ved den grænse, der faktisk bærer strømmen. En DROP-regel et sted på værten er ikke bevis; en fejlet forbindelse plus en flyttet tæller på den regel, der forårsagede den, er.