OpenWrt VPN-zone, videresendelse og maskering: hvilken skal du bruge?

Tre ændringer blandes sammen, hver gang en VPN møder OpenWrt: at åbne en port, at tillade videresendelse og at slå maskering til. De besvarer forskellige spørgsmål, og normalt er kun én af dem det egentlige krav. At læse hver kontrol efter den trafikrolle, den styrer, gør et gæt til en beslutning og fortæller også, hvilket symptom du skal forvente, når ændringen er forkert. Begynd med at navngive den rolle, der fejlede, ikke det afkrydsningsfelt, du husker.

Navngiv trafikrollen, før du rører en kontrol

Zoneinput afgør, hvad der kan nå selve routeren. Zoneoutput dækker trafik, som routeren selv skaber, zonevideresendelse er standarden for trafik, der passerer en zone, og maskering afgør, om kildeadressen skrives om på vej ud. Det er fire forskellige spørgsmål, og en zonepolitik besvarer dem alle på én gang med samme værdi, hvorfor en ændring for hele zonen er et groft værktøj. En navngivet regel kan besvare et af dem uden at røre de øvrige.

Det nyttige kort er efter trafikrolle, fordi det er det, du kan observere, når noget fejler. Hver rolle nedenfor har én kontrol, der afgør den, og ét symptom, der peger på den:

En lytter på routeren har brug for én smal inputregel

En OpenVPN-server på routeren modtager trafik adresseret til routeren, så dens ydre forbindelse afhænger af inputpolitikken i den zone, der bærer den. Tillad den konfigurerede transport og port, og lad alt andet i zonen blive afvist. En enkelt portregel er en langt mindre ændring end en accept for hele zonen, og det er den, du stadig kan forklare om et år.

To ting gør den regel sikker at beholde: den navngiver den port, tjenesten faktisk bruger, og den står ved siden af zonedefinitionen, så den næste person kan se, hvorfor den findes. Linjerne nedenfor er formen, hvor porten repræsenterer det, serveren er konfigureret med. Skift den port begge steder, når tjenesten flytter, for en regel, der bliver på den gamle, er usynlig indtil 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'

Validér før du genindlæser, for en syntaksfejl i en firewall-fil kan efterlade routeren uden et fungerende regelsæt. I en udgivelse, der bruger fw4, er kontrollen en separat kommando, og den fejler højlydt i stedet for stiltiende at acceptere en brudt blok. Genindlæs først, når kontrollen er bestået, og gem den forrige fil, hvor du kan lægge den tilbage.

fw4 check
service firewall reload

En klientanmodning går gennem videresendelse, ikke input

Efter godkendelse skaber en tunnelklients anmodning om en LAN-tjeneste en videresendt strøm, så kontrollen, der afgør det, er videresendelsesforholdet mellem tunnelzonen og LAN-zonen. Tildel tunnelinterfacet til den tilsigtede zone, og erklær derefter retningen, kilderne og tjenesten. Zonetildelingen er det, der giver videresendelsesreglen mening, og de to giver kun mening læst sammen. Et videresendelsesforhold, der navngiver tunnelzonen som kilde og LAN-zonen som destination, læses som én bevidst beslutning, mens to accepter for hele zonen læses som et uheld.

At nå selve routeren bruger stadig inputstien, og derfor siger en ping til gatewayen intet om filsharedele bag den. De to fejl bor i forskellige blokke og rettes med forskellige ændringer. Skriv begge stier ned hver for sig, før du ændrer nogen af dem.

Maskering er en routingbeslutning, ikke en tilladelse

Maskering skriver kildeadressen om for udvalgt udgående trafik. Den kan redde et udgangsdesign, hvor den fjerne side ikke har nogen rute tilbage, og den skjuler også individuelle klientadresser for enhver tjeneste, der logger eller autoriserer efter adresse. At slå den fra er et routingvalg om returvejen, ikke en sikkerhedskontakt, der lukker et indgående hul. En tunnel, der virker med oversættelse slået til og fejler i det øjeblik, den slås fra, mangler normalt en returrute, ikke en firewallregel.

Et routet alternativ kræver en returrute på den fjerne side i stedet for oversættelse. Ingen af mulighederne leverer firewalltilladelsen eller applikationskontoen, og derfor løser det næsten aldrig en tunnelklient, der ikke kan nå noget, at slå maskering fra. Behandl også IPv4- og IPv6-politik hver for sig, da én oversættelsesindstilling ikke beskriver begge familier.

Bevis beslutningen med en tilladt og en afvist anmodning

Send én anmodning, der bør tillades, og én, der bør afvises, og identificér derefter den kontrol, der traf hver beslutning. En side, der tilfældigt indlæses, er ikke bevis; beviset er den regel, der matchede, i den kæde, hvor den matchede. Afvisningen betyder lige så meget som succesen, fordi den viser, at politikken gør noget, i stedet for at alt er tilladt.

To kommandoer giver dig det bevis på en aktuel udgivelse. Tælleren på den matchende regel flytter sig, når anmodningen accepteres, og loggen viser droppet, hvis du har aktiveret logning for reglen:

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

Behold en administrationsvej, du stadig kan bruge, før du ændrer nogen firewallpolitik, og følg konfigurationsejerens validerings- og tilbagerulningsproces. En ændring, der låser dig ude af routeren, er ikke et testresultat, det er en anden hændelse. Notér zonen og trafikrollen ved hver observation, så resultatparret forklarer politikken i stedet for at beskrive en heldig sideindlæsning.