En VPN, der opretter forbindelse, men ikke når noget, beskrives normalt som et firewallproblem, og den løsning, folk griber til, er at sætte tunnelens interface i en betroet zone. Det virker i den forstand, at trafikken begynder at flyde, men det tillader også langt mere end den tilsigtede tjeneste. De to involverede politikker er forskellige: den ene tillader den ydre transport til en lyttende socket, og den anden autoriserer dekrypteret trafik til at nå en bestemt ressource. Det er behandlingen af dem som én indstilling, der gør en snæver tilladelse til en bred. De to afgøres forskellige steder, og derfor er fejlen så nem at lave.

To politikker, én tunnel

Den ydre politik besvarer et enkelt spørgsmål: må en pakke fra denne kilde nå UDP 1194 på denne vært? Den indre politik besvarer et andet: må den godkendte klient bag den tunnel nå denne destination, med denne protokol, på denne port? Det første handler om en socket, det andet om en sti, og firewalld modellerer dem med forskellige objekter, fordi de afgøres forskellige steder. Den ene er en egenskab ved en socket på denne vært, den anden ved en sti gennem den.

Den praktiske konsekvens er, at en fungerende tunnel ikke siger noget om den anden politik, og en korrekt anden politik gør ikke den første overflødig.

Tillad den faktiske ydre lytter

Begynd med at undersøge, hvad der allerede er tildelt, i stedet for at antage. Læs de aktive zoner, list den zone, der faktisk bærer indgående trafik, og kontroller den installerede tjenestedefinition, fordi et tjenestenavn beskriver et sæt porte og intet siger om, hvorvidt denne servers lytter matcher den.

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

Hvis lytteren faktisk er UDP 1194 i den zone, skal du åbne netop den port og transport og derefter gøre den samme specifikke regel permanent, når du har testet den. Kontroller også kildebaserede tildelinger, fordi en zone bundet til et kildeområde kan opfange trafikken, før interfacezonen overhovedet ser den.

Autoriser den dekrypterede destination separat

En forbindelse til en tjeneste, der kører på VPN-serveren selv, er lokal-input-politik. En forbindelse, der videresendes til en anden vært på LAN'et, kræver videresendelsespolitik, videresendelse aktiveret i kernen og en svarroute — det er tre separate krav, som folk ofte smelter sammen til ét. Moderne firewalld-politikobjekter beskriver dirigeret trafik mellem en indgående zone og en udgående zone, og det er det rigtige sted at udtrykke, hvilke VPN-kilder der må nå hvilke private tjenester.

Definer de tilladte kilder eksplicit, og lad alt andet falde igennem til en afvisning. En tilladelse til den ydre tjeneste er ikke den politik, uanset hvordan zoneopstillingen ser ud.

Hvorfor tillid til interfacet er den forkerte genvej

At sætte tunnelens interface i en zone, hvis mål accepterer alt, tillader al dekrypteret trafik til enhver tjeneste, som værten eksponerer, inklusive dem, du ikke har gennemgået. At omdirigere den betroede zone til at være restriktiv på en kørende maskine er værre, fordi andre interface og kildeområder måske allerede afhænger af dens betydning og vil ændre adfærd, når du redigerer den. Hvis du har brug for en snæver politik, så opret en; genbrug ikke en delt zone.

Hold også tunnelens zonetildeling stabil gennem den komponent, der ejer den konfiguration. Mister du tildelingen ved genstart, giver det en fejl, der ligner et firewallregelproblem og i virkeligheden er et persistensproblem.

Bekræft tre ting, herunder én afvisning

Test den ydre forbindelse udefra, test én autoriseret indre tjeneste fra en tilsluttet klient, og test én tjeneste, der bør forblive utilgængelig. Den tredje test er den, der skelner en politik fra en bivirkning, og det er den, folk springer over, fordi alt ser ud til at virke. Hvis den afviste tjeneste svarer, har du tilladt en zone i stedet for en tjeneste.

Notér zone, port, transport og politikobjekt i serverens noter. Ellers begynder den næste ændring på denne vært ud fra den samme antagelse.

Relaterede artikler