firewalld-listenerregel versus doorstuurbeleid: wat elk doet
Een firewalld-toestaan voor het buitenste transport en toestemming om een privébron te bereiken zijn aparte beleidsregels. Open de listener en autoriseer daarna het pad.
Een VPN die verbindt maar niets bereikt, wordt meestal als een firewallprobleem beschreven, en de oplossing waarnaar mensen grijpen is de tunnelinterface in een vertrouwde zone zetten. Dat werkt in de zin dat verkeer begint te stromen, maar het laat ook veel meer door dan de bedoelde dienst. De twee beleidsregels die hierbij betrokken zijn, verschillen: de ene laat het buitenste transport toe naar een luisterende socket, en de andere autoriseert ontsleuteld verkeer om een specifieke bron te bereiken. Ze als één instelling behandelen is wat een smalle toestemming in een brede verandert. De twee worden op verschillende plaatsen beslist, en daarom is de fout zo makkelijk.
Twee beleidsregels, één tunnel
Het buitenste beleid beantwoordt een eenvoudige vraag: mag een pakket van deze bron UDP 1194 op deze host bereiken? Het binnenste beleid beantwoordt een andere: mag de geauthenticeerde client achter die tunnel deze bestemming bereiken, met dit protocol, op deze poort? Het eerste gaat over een socket, het tweede over een pad, en firewalld modelleert ze met verschillende objecten omdat ze op verschillende punten worden beslist. Het ene is een eigenschap van een socket op deze host, het andere van een pad erdoorheen.
Het praktische gevolg is dat een werkende tunnel niets zegt over het tweede beleid, en een correct tweede beleid maakt het eerste niet overbodig.
Laat de werkelijke buitenste listener toe
Begin met te onderzoeken wat al is toegewezen in plaats van het aan te nemen. Lees de actieve zones, lijst de zone op die daadwerkelijk inkomend verkeer draagt, en controleer de geïnstalleerde servicedefinitie, want een servicenaam beschrijft een reeks poorten en zegt niets over of de listener van deze server daarmee overeenkomt.
firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpnAls de listener echt UDP 1194 in die zone is, open dan precies die poort en dat transport, en maak daarna dezelfde specifieke regel permanent nadat je hem hebt getest. Controleer ook toewijzingen op basis van bron, want een zone die aan een bronbereik is gebonden, kan het verkeer onderscheppen voordat de interfacezone het ooit ziet.
Autoriseer de ontsleutelde bestemming afzonderlijk
Een verbinding naar een dienst die op de VPN-server zelf draait, is lokaal-invoerbeleid. Een verbinding die naar een andere host op de LAN wordt doorgestuurd, vereist doorstuurbeleid, doorgifte ingeschakeld in de kernel en een antwoordroute — drie afzonderlijke vereisten die mensen vaak tot één samenvatten. Moderne firewalld-beleidsobjecten beschrijven gericht verkeer tussen een inkomende en een uitgaande zone, en dat is de juiste plaats om uit te drukken welke VPN-bronnen welke privédiensten mogen bereiken.
Definieer de toegestane bronnen expliciet en laat al het overige in een weigering vallen. Een toestaan voor de buitenste dienst is dat beleid niet, hoe de zone-indeling er ook uitziet.
Waarom vertrouwen op de interface de verkeerde kortere weg is
De tunnelinterface in een zone zetten waarvan het doel alles accepteert, laat al het ontsleutelde verkeer door naar elke dienst die de host aanbiedt, ook naar diensten die je niet hebt beoordeeld. De vertrouwde zone op een draaiende machine achteraf beperkend maken is erger, omdat andere interfaces en bronbereiken al van de betekenis kunnen afhangen en gedrag veranderen wanneer je die bewerkt. Heb je een smal beleid nodig, maak er dan een; hergebruik geen gedeelde zone.
Houd ook de zonetoewijzing van de tunnel stabiel via welke component dat configuratiebestand dan ook bezit. De toewijzing bij een herstart verliezen levert een storing op die op een firewallregelprobleem lijkt en in werkelijkheid een persistentieprobleem is.
Controleer drie dingen, waaronder één weigering
Test de buitenste verbinding van buitenaf, test één geautoriseerde binnenste dienst vanaf een verbonden client, en test één dienst die onbereikbaar zou moeten blijven. De derde test is degene die beleid van een neveneffect onderscheidt, en het is degene die mensen overslaan omdat alles te werken lijkt. Als de geweigerde dienst antwoordt, heb je een zone toegestaan in plaats van een dienst.
Noteer de zone, poort, transport en het beleidsobject in de notities van de server. Anders begint de volgende wijziging op deze host bij dezelfde aanname.