firewalld-lyssnarregel kontra vidarebefordringspolicy: vad var och en gör

Ett VPN som ansluter men inte når något beskrivs vanligtvis som ett brandväggsproblem, och lösningen folk griper efter är att sätta tunnelns gränssnitt i en betrodd zon. Det fungerar i den meningen att trafiken börjar flöda, men det släpper också igenom långt mer än den avsedda tjänsten. De två policyerna som är inblandade är olika: den ena släpper igenom den yttre transporten till en lyssnande socket, och den andra auktoriserar dekrypterad trafik att nå en specifik resurs. Att behandla dem som en enda inställning är det som förvandlar ett snävt tillstånd till ett brett. De två avgörs på olika ställen, och därför är misstaget så lätt att göra.

Två policyer, en tunnel

Den yttre policyn svarar på en enkel fråga: får ett paket från denna källa nå UDP 1194 på den här värden? Den inre policyn svarar på en annan: får den autentiserade klienten bakom den tunneln nå denna destination, med detta protokoll, på denna port? Den första handlar om en socket, den andra om en väg, och firewalld modellerar dem med olika objekt eftersom de avgörs på olika punkter. Den ena är en egenskap hos en socket på den här värden, den andra hos en väg genom den.

Den praktiska konsekvensen är att en fungerande tunnel inte säger något om den andra policyn, och en korrekt andra policy gör inte den första överflödig.

Släpp igenom den faktiska yttre lyssnaren

Börja med att undersöka vad som redan är tilldelat i stället för att anta. Läs de aktiva zonerna, lista zonen som faktiskt bär ingående trafik och kontrollera den installerade tjänstedefinitionen, eftersom ett tjänstenamn beskriver en uppsättning portar och inte säger något om huruvida den här serverns lyssnare matchar den.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Om lyssnaren verkligen är UDP 1194 i den zonen, öppna just den porten och transporten och gör sedan samma specifika regel permanent efter att du testat den. Kontrollera också källbaserade tilldelningar, eftersom en zon bunden till ett källområde kan fånga trafiken innan gränssnittszonen ens ser den.

Auktorisera den dekrypterade destinationen separat

En anslutning till en tjänst som körs på VPN-servern själv är lokal indata-policy. En anslutning som vidarebefordras till en annan värd i LAN kräver vidarebefordringspolicy, vidarebefordran aktiverad i kärnan och en svarsväg — tre separata krav som folk ofta slår ihop till ett. Moderna firewalld-policyobjekt beskriver riktad trafik mellan en ingående och en utgående zon, och det är rätt plats att uttrycka vilka VPN-källor som får nå vilka privata tjänster.

Definiera de tillåtna källorna uttryckligen och låt allt annat falla i en avvisning. Ett tillstånd för den yttre tjänsten är inte den policyn, hur zonindelningen än ser ut.

Varför förtroende för gränssnittet är den fel genvägen

Att sätta tunnelns gränssnitt i en zon vars mål accepterar allt släpper igenom all dekrypterad trafik till varje tjänst som värden exponerar, inklusive dem du inte har granskat. Att rikta om den betrodda zonen till att vara restriktiv på en maskin som kör är värre, eftersom andra gränssnitt och källområden kanske redan beror på dess betydelse och kommer att ändra beteende när du redigerar den. Om du behöver en snäv policy, skapa en; återanvänd inte en delad zon.

Håll också tunnelns zontilldelning stabil genom vilken komponent som helst som äger den konfigurationen. Att förlora tilldelningen vid omstart ger ett fel som ser ut som ett brandväggsregelproblem och egentligen är ett persistensproblem.

Verifiera tre saker, inklusive en avvisning

Testa den yttre anslutningen utifrån, testa en auktoriserad inre tjänst från en ansluten klient och testa en tjänst som ska förbli oåtkomlig. Det tredje testet är det som skiljer en policy från en bieffekt, och det är det folk hoppar över eftersom allt verkar fungera. Om den avvisade tjänsten svarar har du släppt igenom en zon i stället för en tjänst.

Anteckna zon, port, transport och policyobjekt i serverns anteckningar. Annars börjar nästa ändring på den här värden från samma antagande.