Sette opp gatewayen

Vi forutsetter at du nå har skrudd inn et nettverkskort til, eller i alle fall sørget for nettverksforbindelse ut fra lokalnettet, for eksempel via PPP. Vi kommer ikke inn på konfigurering av grensesnittene.

I det som følger vil det bare være selve grensesnittnavnet som vil variere mellom Ethernet og PPP, og de konkrete grensesnittnavnene kvitter vi oss med så fort det lar seg gjøre.

For det første må vi slå på gateway-funksjonen, slik at maskinen kan overføre trafikk den mottar på ett nettverksgrensesnitt videre til andre maskiner via et annet grensesnitt. Det kan vi gjøre fra kommandolinjen med sysctl, for tradisjonell IP versjon fire med

# sysctl net.inet.ip.forwarding=1

og hvis vi trenger å sende videre IP versjon seks-trafikk, er kommandoen

# sysctl net.inet6.ip6.forwarding=1

For at dette skal fortsette å virke når du en gang i fremtiden starter maskinen på nytt, må du legge disse verdiene inn i konfigurasjonsfilene.

På OpenBSD og NetBSD gjør du dette ved å redigere /etc/sysctl.conf, der du endrer de linjene du trenger, slik

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1

På FreeBSD gjør du det tilsvarende med disse linjene i /etc/rc.conf

gateway_enable="YES" #for ipv4
ipv6_gateway_enable="YES" #for ipv6

Nettoeffekten er den samme, rc-scriptet på FreeBSD setter de to verdiene via sysctl-kommandoen, men på FreeBSD er altså større deler av konfigurasjonen sentralisert i rc.conf.

Er begge de grensesnittene du har tenkt å bruke, oppe og kjører? Bruk ifconfig -a, eventuelt ifconfig grensesnittnavn til å finne det ut.

Hvis du fortsatt tenker at du vil tillate all trafikk som maskinene på innsiden tar initiativ til, kan din /etc/pf.conf se slik ut[1]:

localnet = $int_if:network
ytre = "xl0" # makro for ytre gr.snitt - bruk tun0 for PPPoE
indre = "xl1"  # makro for indre gr.snitt
# dynamisk ekstern IP-adresse, angis med ($grensesnitt)
nat on $ytre from $localnet to any -> ($ytre) 
block all
pass from { lo0, $localnet } to any keep state

Legg merke til at vi bruker makroer for å gi nettverksgrensesnittene logiske navn. Her dreier det seg altså om 3Com-kort, men dette er siste gangen i dette foredraget at det er interessant overhodet. I så enkle oppsett som dette er nok ikke gevinsten av å bruke disse makroene så veldig stor, men når regelsettene blir litt større, vil du sette stor pris på lesbarheten.

Legg også merke til nat-regelen. Her sørger vi for nettverksadresseoversettingen fra de ikke-rutbare adressene på innsiden til den ene offisielle adressen vi forutsetter at du disponerer.

Parentesene rundt det siste leddet ($ytre) er der for å kompensere for at IP-adressen på det ytre grensesnittet kan være dynamisk tildelt, og sørger for at trafikken din vil gå som den skal selv om du plutselig blir tildelt ny ytre adresse.

En annen ting er at dette regelsettet sannsynligvis tillater mer trafikk ut enn det du egentlig har lyst til. Der jeg jobber, er den tilsvarende makroen

klient_ut = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \
               https, 446, cvspserver, 2628, 5999, 8000, 8080 }"

og regelen

pass inet proto tcp from $localnet to any port $klient_ut \
          flags S/SA keep state

Det er mulig at dette er et sært utvalg, men det er det utvalget akkurat jeg og mine kolleger trenger. Noen av de odde portene er for systemer som jeg ikke får lov til å si mer om. Dine behov er sannsynligvis annerledes igjen, men en del av de mer nyttige tjenestene er nok dekket her.

Vi har noen andre pass-regler, og de fleste av de som kan være interessante kommer vi tilbake til senere. En regel som er relativt nyttig for oss som liker å kunne administrere maskiner fra andre steder i verden er

pass in inet proto tcp from any to any port ssh

eller forsåvidt

pass in inet proto tcp from any to $ytre port ssh

alt ettersom. Endelig trenger vi, for at navnetjenesten skal fungere også fra innsiden

udp_tjenester = "{ domain, ntp }"

pluss en regel som slipper det vi ønsker gjennom brannmuren:

pass quick inet proto { tcp, udp } to any port $udp_tjenester keep state

Legg merke til her at vi bruker nøkkelordet quick. Når vi lager regelsett som består av flere regler, er det på tide å se på hvordan forholdet mellom reglene i et regelsett fungerer. Regelsett blir tolket i rekkefølge 'ovenfra og ned'. Det betyr at reglene blir tolket i den rekkefølgen de er skrevet i konfigurasjonsfilen, og siste regel som passer for en gitt pakke eller forbindelse, er den som blir brukt. quick er veien ut av den vanlige sekvensen. Når en pakke passer til en quick-regel, vil pakken bli behandlet etter den regelen, uten at pakken blir vurdert mot resten av regelsettet. Fint når du har behov noen isolerte unntak fra generelle regler.

Da har vi tatt med ntp også, som bgrukes til tidssynkronisering. En av de tingene som disse protokollene har til felles, er at de under visse forutsetninger kan komme til å kommunisere over både TCP og UDP.