Varför en OpenVPN-klientblockeringsregel aldrig träffar FORWARD

Två klienter på samma OpenVPN-server kan nå varandra även efter att du lagt till en DROP-regel för deras pool. Regeln sitter i FORWARD-kedjan, trafiken flödar tydligt, och räknaren för den regeln står kvar på noll. Den naturliga slutsatsen är att brandväggen är trasig. Oftare har paketet aldrig ens kommit in i kedjan.

Det finns två vägar ett peer-paket kan ta genom en OpenVPN-server, och de bestäms av konfigurationen, inte av brandväggen. Att veta vilken väg som används säger dig om en värdregel ens står på rätt plats.

Två vägar ett peer-paket kan ta

När alternativet för intern vidarebefordran är avstängt kommer ett paket från klient A in på tunnelgränssnittet med en destination inom klient Bs tilldelade adress. Serverns routingtabell skickar ut det igen genom samma tunnelgränssnitt, eftersom servern äger vägen till Bs adress. Det är ett in-och-ut-flöde genom värden, och IPv4-vidarebefordringsvägen utvärderar det.

När alternativet för intern vidarebefordran är påslaget matchar serverprocessen paketet mot en ansluten klient och skriver tillbaka det till den klienten själv. Paketet hanteras inne i daemonen och kommer aldrig tillbaka in i tunnelenheten, så värdens vidarebefordringsväg hoppas över helt. Handboken för OpenVPN 2.6 beskriver alternativet som intern klient-till-klient-vidarebefordran, och det är just därför en brandväggsregel på värden inte kan se den.

Det finns en tredje variant i installationer som flyttar datakanalen till en kärnmodul. Vidarebefordringsbeslutet och krypteringen flyttar ut ur användarutrymmet, och om netfilter ser flödet beror på hur överföringsvägen är byggd. Anta aldrig att en gammal regeluppsättning beter sig på en överförd server som på en i användarutrymmet. Bekräfta läget från den körande konfigurationen, inte från paketversionen.

När räknaren aldrig rör sig

En nollräknare betyder att paketet inte matchade den regeln vid den punkten, och det finns flera skäl. Det första är omvägen ovan: trafiken nådde aldrig kedjan. Det andra är en missmatchning i gränssnitt, riktning, källa eller destination, vilket är vanligt när poolen numrerats om och regeln fortfarande anger det gamla prefixet.

Det tredje är position. En regel tidigare i kedjan kan acceptera flödet innan din DROP utvärderas, och en regel senare kan vara den som faktiskt avgör resultatet. Läs kedjan i ordning med räknarna synliga och kontrollera sedan vilken regels räknare som ökar när du upprepar testet.

Gör ett kontrollerat utbyte mellan två klienter vars verkliga adresser du bekräftat från serverns eget tillstånd, inte från en lease du minns. Om den aktuella räknaren fortfarande inte rör sig, misstänk vägen innan du skriver om matchningen. Om den rör sig men anslutningen ändå lyckas blir droppen överkörd senare och ordningen är problemet. Det svaret avgör om reparationen är en regeländring eller en topologiändring, så skaffa det innan du redigerar något.

Att välja en gräns som kan filtrera

Om policyn måste bo i värdens brandvägg, sätt trafiken där brandväggen kan se den. Att stänga av intern vidarebefordran är det stödda sättet att få peer-trafik att passera tunnelgränssnittet och vidarebefordringsvägen, till priset att varje peer-paket går genom värdens stack.

Matcha sedan flödet exakt. Trafik kommer in på tunnelgränssnittet och går ut på tunnelgränssnittet, i båda riktningarna, så regler som bara tittar på det fysiska gränssnittet kommer inte att matcha. Adressbaserade regler behöver den aktuella poolen, och de måste ta hänsyn till returriktningen lika mycket som den framåtriktade.

Många installationer tjänar bättre på att filtrera på klient- eller gruppnivå, där identiteten är känd och policyn följer användaren i stället för en adress som ändras vid återanslutning. Det är en annan mekanism än en kedja på värden, och de två bör inte blandas utan ett tydligt skäl.

Flytta inte en gammal topologis regeluppsättning genom en migrering oförändrad. Adresspooler, gränssnittsnamn och vidarebefordringslägen påverkar alla om en regel matchar, och en kopierad regel som en gång fungerade är den mest vilseledande typen av bevis. Börja med det flöde du vill tillåta och skriv regeln som matchar det.

Att testa isolering i stället för att lita på en regel

Testa det förbjudna fallet och det tillåtna fallet i samma körning. Starta en ny anslutning från den ena klienten till den andra och bekräfta att den misslyckas, bekräfta sedan att en anslutning som borde vara tillåten fortfarande fungerar. Om bara det första testas ser en brandvägg som blockerar allt ut som en framgång.

Upprepa efter att serverkonfigurationen laddats om och efter att en klient återanslutit, eftersom intern vidarebefordran och poolfördelning är körtidstillstånd. Kontrollera räknare i båda riktningarna, eftersom en regel som matchar en riktning men inte svaret ger delvis isolering som är svår att lägga märke till i ett snabbt test.

Isolering är det observerade resultatet vid den gräns som faktiskt bär flödet. En DROP-regel någonstans på värden är inget bevis; en misslyckad anslutning plus en flyttad räknare på regeln som orsakade den är det.