OpenWrt VPN-sone, videresending og maskering: hvilken trenger du?

Tre endringer blandes sammen hver gang en VPN møter OpenWrt: å åpne en port, tillate videresending og slå på maskering. De svarer på forskjellige spørsmål, og vanligvis er bare én av dem det egentlige kravet. Å lese hver kontroll etter trafikkrollen den styrer gjør en gjetning til en beslutning, og forteller også hvilket symptom du skal forvente når endringen er feil. Begynn med å navngi rollen som feilet, ikke avkrysningsboksen du husker.

Navngi trafikkrollen før du rører en kontroll

Soneinngang avgjør hva som kan nå selve ruteren. Soneutgang dekker trafikk ruteren selv skaper, sonevideresending er standarden for trafikk som passerer en sone, og maskering avgjør om kildeadressen skrives om på vei ut. Det er fire forskjellige spørsmål, og en sonepolicy svarer på alle på én gang med samme verdi, derfor er en endring for hele sonen et grovt verktøy. En navngitt regel kan svare på ett av dem uten å røre de andre.

Det nyttige kartet er etter trafikkrolle, fordi det er det du kan observere når noe feiler. Hver rolle nedenfor har én kontroll som avgjør den og ett symptom som peker på den:

En lytter på ruteren trenger én smal inngangsregel

En OpenVPN-server på ruteren mottar trafikk adressert til ruteren, så den ytre forbindelsen avhenger av inngangspolicyen til sonen som bærer den. Tillat den konfigurerte transporten og porten, og la alt annet i sonen bli avvist. Én portregel er en langt mindre endring enn en tillatelse for hele sonen, og det er den du fortsatt kan forklare om et år.

To ting gjør den regelen trygg å beholde: den navngir porten tjenesten faktisk bruker, og den står ved siden av sonedefinisjonen slik at neste person ser hvorfor den finnes. Linjene nedenfor er formen, der porten står for det som er konfigurert på serveren. Endre den porten begge steder når tjenesten flytter, for en regel som blir igjen på den gamle er usynlig til en revisjon.

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'

Valider før du laster inn på nytt, for en syntaksfeil i en brannmurfil kan etterlate ruteren uten et fungerende regelsett. I en utgivelse som bruker fw4 er kontrollen en egen kommando, og den feiler høyt i stedet for å godta en ødelagt blokk i stillhet. Last inn på nytt først når kontrollen er bestått, og ta vare på den forrige filen der du kan legge den tilbake.

fw4 check
service firewall reload

En klientforespørsel går gjennom videresending, ikke inngang

Etter autentisering skaper en tunnelklients forespørsel om en LAN-tjeneste en videresendt strøm, så kontrollen som avgjør det er videresendingsforholdet mellom tunnelsonen og LAN-sonen. Tildel tunnelgrensesnittet til den tiltenkte sonen, og erklær deretter retningen, kildene og tjenesten. Sonetildelingen er det som gir videresendingsregelen mening, og de to gir bare mening lest sammen. Et videresendingsforhold som navngir tunnelsonen som kilde og LAN-sonen som mål leses som én bevisst beslutning, mens to tillatelser for hele sonen leses som en ulykke.

Å nå selve ruteren bruker fortsatt inngangsveien, derfor sier en ping til gatewayen ingenting om filutdelingen bak den. De to feilene bor i forskjellige blokker og rettes med forskjellige endringer. Skriv ned begge veiene hver for seg før du endrer noen av dem.

Maskering er en rutingbeslutning, ikke en tillatelse

Maskering skriver om kildeadressen til utvalgt utgående trafikk. Den kan redde et utgangsdesign der den fjerne siden ikke har noen returrute, og den skjuler også individuelle klientadresser for enhver tjeneste som logger eller autoriserer etter adresse. Å slå den av er et rutingvalg om returveien, ikke en sikkerhetsbryter som lukker et inngangshull. En tunnel som virker med oversettelse på og feiler i det øyeblikket den slås av, mangler vanligvis en returrute, ikke en brannmurregel.

Det rutede alternativet krever en returrute på den fjerne siden i stedet for oversettelse. Ingen av alternativene gir brannmurtillatelsen eller applikasjonskontoen, derfor løser det nesten aldri en tunnelklient som ikke når noe, å slå av maskering. Behandle også IPv4- og IPv6-policyen hver for seg, siden én oversettelsesinnstilling ikke beskriver begge familiene.

Bevis beslutningen med en tillatt og en avvist forespørsel

Send én forespørsel som bør tillates og én som bør avvises, og identifiser deretter kontrollen som tok hver beslutning. En side som tilfeldigvis lastes er ikke bevis; beviset er regelen som traff, i kjeden der den traff. Avvisningen betyr like mye som suksessen, fordi den viser at policyen gjør noe i stedet for at alt er tillatt.

To kommandoer gir deg det beviset på en gjeldende utgivelse. Telleren på den samsvarende regelen flytter seg når forespørselen godtas, og loggen viser slettingen hvis du har slått på logging for regelen:

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

Behold en administrasjonsvei du fortsatt kan bruke før du endrer noen brannmurpolicy, og følg validerings- og tilbakerullingsprosessen til eieren av konfigurasjonen. En endring som låser deg ute av ruteren er ikke et testresultat, det er en andre hendelse. Noter sonen og trafikkrollen ved hver observasjon, slik at resultatparet forklarer policyen i stedet for å beskrive en heldig sideinnlasting.