OpenWrt VPN-sone, videresending og maskering: kva treng du?

Tre endringar blir blanda saman kvar gong ein VPN møter OpenWrt: å opne ein port, tillate videresending og slå på maskering. Dei svarar på ulike spørsmål, og vanlegvis er berre éin av dei det eigentlege kravet. Å lese kvar kontroll etter trafikkrolla han styrer gjer ei gissing til ei avgjerd, og fortel også kva symptom du skal vente når endringa er feil. Byrja med å namngje rolla som svikta, ikkje avkryssingsboksen du hugsar.

Namngje trafikkrolla før du rører ein kontroll

Soneinngang avgjer kva som kan nå sjølve rutaren. Soneutgang dekkjer trafikk rutaren sjølv lagar, sonevideresending er standarden for trafikk som passerer ei sone, og maskering avgjer om kjeldadressa blir skriven om på veg ut. Det er fire ulike spørsmål, og ein sonepolicy svarar på alle på ein gong med same verdi, difor er ei endring for heile sona eit grovt verktøy. Ein namngjeven regel kan svare på eitt av dei utan å røre dei andre.

Det nyttige kartet er etter trafikkrolle, fordi det er det du kan observere når noko sviktar. Kvar rolle nedanfor har éin kontroll som avgjer henne og eitt symptom som peikar på henne:

Ein lyttar på rutaren treng éin smal inngangsregel

Ein OpenVPN-tenar på rutaren tek imot trafikk adressert til rutaren, så den ytre sambindinga hennar avheng av inngangspolicyen til sona som ber henne. Tillat den konfigurerte transporten og porten, og la alt anna i sona bli avvist. Éin portregel er ei langt mindre endring enn ei tillating for heile sona, og det er den du framleis kan forklare om eit år.

To ting gjer den regelen trygg å halde på: han namngjev porten tenesta faktisk brukar, og han står ved sida av sonedefinisjonen slik at neste person ser kvifor han finst. Linjene nedanfor er forma, der porten står for det som er konfigurert på tenaren. Endre den porten begge stader når tenesta flyttar, for ein regel som blir igjen på den gamle er usynleg til ein 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 lastar inn på nytt, for ein syntaksfeil i ei brannmurfil kan etterlate rutaren utan eit fungerande regelsett. I ei utgåve som brukar fw4 er kontrollen ein eigen kommando, og han sviktar høgt i staden for å godta ein øydelagd blokk i det stille. Last inn på nytt først når kontrollen er bestått, og ta vare på den førre fila der du kan leggje henne tilbake.

fw4 check
service firewall reload

Ein klientførespurnad går gjennom videresending, ikkje inngang

Etter autentisering skapar ein førespurnad frå ein tunnelklient om ei LAN-teneste ein videresendt straum, så kontrollen som avgjer det er videresendingsforholdet mellom tunnelsona og LAN-sona. Tildel tunnelgrensesnittet til den tiltenkte sona, og erklær deretter retninga, kjeldene og tenesta. Sonetildelinga er det som gjev videresendingsregelen meining, og dei to gjev berre meining lesne saman. Eit videresendingsforhold som namngjev tunnelsona som kjelde og LAN-sona som mål blir lese som éi medviten avgjerd, medan to tillatingar for heile sona blir lese som eit uhell.

Å nå sjølve rutaren brukar framleis inngangsvegen, difor seier ein ping til gatewayen ingenting om filutdelinga bak han. Dei to feila bur i ulike blokker og blir retta med ulike endringar. Skriv ned begge vegane kvar for seg før du endrar nokon av dei.

Maskering er ei rutingavgjerd, ikkje ei tillating

Maskering skriv om kjeldadressa til utvald utgåande trafikk. Ho kan redde eit utgangsdesign der den fjerne sida ikkje har nokon returveg, og ho skjuler også adressene til individuelle klientar for kvar teneste som loggar eller autoriserer etter adresse. Å slå henne av er eit rutingval om returvegen, ikkje ein tryggleiksbrytar som lukkar eit inngangshol. Ein tunnel som verkar med omsetjing på og sviktar i det augneblunken ho blir slått av, manglar vanlegvis ein returveg, ikkje ein brannmurregel.

Det ruta alternativet krev ein returveg på den fjerne sida i staden for omsetjing. Ingen av alternativa gjev brannmurtillatinga eller applikasjonskontoen, difor løyser det nesten aldri ein tunnelklient som ikkje når noko, å slå av maskering. Handsame også IPv4- og IPv6-policyen kvar for seg, sidan éi omsetjingsinnstilling ikkje skildrar begge familiane.

Prov avgjerda med ein tillaten og ein avvist førespurnad

Send éin førespurnad som bør tillatast og éin som bør avvisast, og identifiser deretter kontrollen som tok kvar avgjerd. Ei side som tilfeldigvis lastar er ikkje prov; provet er regelen som traff, i kjeda der han traff. Avvisinga tel like mykje som suksessen, fordi ho viser at policyen gjer noko i staden for at alt er tillate.

To kommandoar gjev deg det provet på ei gjeldande utgåve. Teljaren på den samsvarande regelen flyttar seg når førespurnaden blir godteken, og loggen viser slettinga om du har slått på logging for regelen:

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

Hald på ein administrasjonsveg du framleis kan bruke før du endrar nokon brannmurpolicy, og følg validerings- og tilbakerullingsprosessen til eigaren av konfigurasjonen. Ei endring som låser deg ute av rutaren er ikkje eit testresultat, det er ein andre hending. Noter sona og trafikkrolla ved kvar observasjon, slik at resultatparet forklarer policyen i staden for å skildre ei heldig sideinnlasting.