Tiden går, og behovene endrer seg. Et behov som ofte oppstår, er å kunne kjøre tjenester som er tilgjengelige utenfra. Dette blir ofte vanskelig fordi ekstra eksternt synlige adresser enten ikke er tilgjengelig eller dyrt, og det er ofte ikke ønskelig å kjøre mange tjenester på samme maskin som fungerer som brannmur.
Omdirigeringsmekanismene i PF gjør det relativt enkelt å ha servere på innsiden. Hvis vi tenker oss at behovet er å ha en webserver som tilbyr tjenester i klartekst (http) og kryptert (https), og du ønsker å ha en epostserver som sender og mottar epost, samtidig som den lar klienter innenfor og utenfor eget nett bruke en del kjente protokoller for henting og sending, kan disse linjene være alt du trenger å føye til regelsettet fra tidligere:
webserver = "192.168.2.7"
webporter = "{ http, https }"
epostserver = "192.168.2.5"
epost = "{ smtp, pop3, imap, imap3, imaps, pop3s }"
rdr on $ytre proto tcp from any to $ytre port \
$webporter -> $webserver
rdr on $ytre proto tcp from any to $ytre port
$epost -> $epostserver
pass proto tcp from any to $webserver port $webporter \
flags S/SA synproxy state
pass proto tcp from any to $epostserver port $epost \
flags S/SA synproxy state
pass proto tcp from $epostserver to any port smtp \
flags S/SA synproxy stateHer er flagget 'synproxy' tatt med. Det betyr at det er PF, ikke din server eller forsåvidt klient, som håndterer opprettingen av forbindelsen (treveis-håndtrykket) før applikasjonen overtar selv. Dette gir en viss beskyttelse mot visse typer angrep.
Regelsett for konfigurasjoner med DMZ-nett som er isolert bak eget nettverksgrensesnitt og eventuelt tjenester på alternative porter vil ikke nødvendigvis skille seg særlig fra dette.
Alt jeg har sagt så langt stemmer veldig godt så lenge du bare tar hensyn til trafikk som kommer fra andre steder enn ditt eget nettverk.
Hvis du ønsker at maskiner på lokalnettet skal bruke tjenestene på de samme maskinene, oppdager du fort at trafikken fra lokalnettet sannsynligvis aldri kommer innom det ytre nettverksgrensesnittet, der all omdirigering og adresseoversetting foregår. Dette problemet er faktisk så vanlig at PF-dokumentasjonen nå inneholder fire separate løsninger på problemet.[1]
Alternativene som foreslås i PF-brukerhåndboken er
DNS med 'delt horisont', altså at navnetjenesten gir forskjellige svar avhengig av om forespørselen kommer fra lokalnettet eller andre steder
proxying med for eksempel nc (NetCat)
spesialbehandling av lokalenettet ved hjelp av omdirigering og NAT.
Vi skal se nærmere på dette alternativet nedenfor.
Eller helt enkelt flytte serverne til et separat nett, såkalt 'DMZ', med bare mindre endringer i PF-regler
Vi trenger å fange opp pakkene som kommer fra lokalnettet, og sørge for at forbindelsene blir håndtert riktig slik at returtrafikk kommer frem til den kommunikasjonspartneren som faktisk opprettet forbindelsen.
I vårt eksempel klarer vi dette ved å legge til disse reglene:
rdr on $indre proto tcp from $localnet to $ytre \
port $webporter -> $webserver
rdr on $indre proto tcp from $localnet to $ytre \
port $epost -> $epostserver
no nat on $inter proto tcp from $indre to $localnet
nat on $indre proto tcp from $localnet to $webserver \
port $webporter -> $indre
nat on $indre proto tcp from $localnet to $epostserver \
port $epost -> $indre | [1] | Se Redirection and Reflection i PF-brukerhåndboken. |