OpenWrt VPN-zon, vidarebefordran och maskering: vilken behöver du?

Tre ändringar blandas ihop varje gång en VPN möter OpenWrt: att öppna en port, tillåta vidarebefordran och slå på maskering. De svarar på olika frågor, och oftast är bara en av dem det egentliga kravet. Att läsa varje regel efter den trafikroll den styr gör en gissning till ett beslut, och säger också vilket symptom du ska förvänta dig när ändringen är fel. Börja med att namnge rollen som misslyckades, inte kryssrutan du minns.

Namnge trafikrollen innan du rör en regel

Zonens indata avgör vad som kan nå själva routern. Zonens utdata omfattar trafik som routern själv skapar, zonens vidarebefordran är standard för trafik som passerar en zon, och maskeringen avgör om källadressen skrivs om på vägen ut. Det är fyra olika frågor, och en zonpolicy besvarar alla på en gång med samma värde, därför är en ändring för hela zonen ett grovt verktyg. En namngiven regel kan besvara en av dem utan att röra de andra.

Den användbara kartan är efter trafikroll, eftersom det är vad du kan observera när något misslyckas. Varje roll nedan har en regel som avgör den och ett symptom som pekar på den:

En lyssnare på routern behöver en enda smal indataregel

En OpenVPN-server på routern tar emot trafik adresserad till routern, så dess yttre anslutning beror på indatapolicyn för zonen som bär den. Tillåt den konfigurerade transporten och porten och låt allt annat i zonen vara avvisat. En enda portregel är en mycket mindre ändring än ett tillstånd för hela zonen, och det är den du fortfarande kan förklara om ett år.

Två saker gör den regeln säker att behålla: den namnger porten som tjänsten faktiskt använder, och den står bredvid zonens definition så att nästa person ser varför den finns. Raderna nedan är formen, där porten står för det som är konfigurerat på servern. Ändra den porten på båda ställena när tjänsten flyttar, för en regel som blir kvar på den gamla är osynlig till en revision.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Validera innan du läser in på nytt, för ett syntaxfel i en brandväggsfil kan lämna routern utan en fungerande regeluppsättning. I en version med fw4 är kontrollen ett eget kommando, och det misslyckas högljutt i stället för att tyst acceptera ett trasigt block. Läs in på nytt först när kontrollen har gått igenom, och spara den förra filen där du kan lägga tillbaka den.

fw4 check
service firewall reload

En klientbegäran går genom vidarebefordran, inte genom indata

Efter autentisering skapar en tunnelklients begäran om en LAN-tjänst ett vidarebefordrat flöde, så regeln som avgör det är vidarebefordringsrelationen mellan tunnelzonen och LAN-zonen. Tilldela tunnelgränssnittet till den avsedda zonen och deklarera sedan riktningen, källorna och tjänsten. Zontilldelningen är det som ger vidarebefordringsregeln mening, och de två är bara begripliga lästa tillsammans. En vidarebefordringsrelation som namnger tunnelzonen som källa och LAN-zonen som mål läses som ett medvetet beslut, medan två tillstånd för hela zonen läses som en olycka.

Att nå själva routern använder fortfarande indatavägen, därför säger en ping till gatewayen ingenting om filutdelningen bakom den. De två felen bor i olika block och åtgärdas med olika ändringar. Skriv ner båda vägarna var för sig innan du ändrar någon av dem.

Maskering är ett routingbeslut, inte ett tillstånd

Maskering skriver om källadressen för utvald utgående trafik. Den kan rädda en utgångsdesign där den bortre sidan inte har någon returväg, och den döljer också enskilda klienters adresser för varje tjänst som loggar eller auktoriserar efter adress. Att stänga av den är ett routingval om returvägen, inte en säkerhetsbrytare som stänger ett ingångshål. En tunnel som fungerar med översättning på och misslyckas i samma ögonblick som den stängs av saknar oftast en returväg, inte en brandväggsregel.

Det routade alternativet kräver en returväg på den bortre sidan i stället för översättning. Ingen av möjligheterna ger brandväggstillståndet eller applikationskontot, därför löser det nästan aldrig en tunnelklient som inte når något att stänga av maskeringen. Behandla också IPv4- och IPv6-policyn separat, eftersom en enda översättningsinställning inte beskriver båda familjerna.

Bevisa beslutet med en tillåten och en avvisad begäran

Skicka en begäran som borde tillåtas och en som borde avvisas, och identifiera sedan regeln som tog varje beslut. En sida som laddas av en slump är inte bevis; beviset är regeln som matchade, i den kedja där den matchade. Avvisningen betyder lika mycket som framgången, eftersom den visar att policyn gör något i stället för att allt är tillåtet.

Två kommandon ger dig det beviset på en aktuell version. Räknaren på den matchande regeln flyttar sig när begäran accepteras, och loggen visar avvisningen om du har slagit på loggning för regeln:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Behåll en administrationsväg som du fortfarande kan använda innan du ändrar någon brandväggspolicy, och följ validerings- och återställningsprocessen från ägaren av konfigurationen. En ändring som låser dig ute från routern är inte ett testresultat, det är en andra incident. Anteckna zonen och trafikrollen vid varje observation, så att resultatparet förklarar policyn i stället för att beskriva en lyckad sidladdning.