![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Vorige: Ankers] [Inhoud] [Volgende: Adres Pools en Load Balancing]
Iets in een wachtrij zetten is het in volgorde bewaren, terwijl het wacht op verwerking. Wanneer gegevenspakketten in een computernetwerk vanaf een host verzonden worden, komen ze in een wachtrij binnen, waar ze op verwerking door het besturingssyteem wachten. Het besturingssysteem beslist vervolgens welke wachtrij en welk(e) pakket(ten) van die wachtrij verwerkt moeten worden. De volgorde waarin het besturingssysteem de pakketten selecteert om ze te verwerken, kan de netwerkprestatie beïnvloeden. Stel bijvoorbeeld een gebruiker die twee netwerktoepassingen uitvoert: SSH en FTP. Ideaal zouden de SSH pakketten vóór de FTP pakketten moeten verwerkt worden omwille van de tijdsgevoelige aard van SSH; wanneer een toets ingetypt wordt in de SSH client, verwacht men onmiddellijke reactie, terwijl een FTP transfer die met enkele extra seconden vertraagd wordt, nauwelijks opgemerkt wordt. Maar wat gebeurt er als de router die deze verbindingen behandelt, een grote brok pakketten van de FTP verbinding verwerkt alvorens de SSH verbinding te verwerken? Pakketten van de SSH verbinding zullen in de wachtrij blijven (of mogelijk laat de router ze vallen als de wachtrij niet groot genoeg is om alle pakketten te bevatten) en de SSH sessie kan lijken te haperen of te vertragen. Door de gebruikte wachtrijstrategie te wijzigen, kan netwerkbandbreedte eerlijk gedeeld worden tussen verschillende toepassingen, gebruikers en computers.
Merk op dat queueing alleen nuttig is voor pakketten in de uitgaande richting. Zodra een pakket aankomt op een interface in de binnengaande richting, is het al te laat om het in een wachtrij te zetten -- het heeft al netwerkbandbreedte verbruikt om de interface te bereiken waarop het zonet ontvangen werd. De enige oplossing is om queueing in te schakelen op de nabijgelegen router of, als de host die het pakket ontving als router fungeert, queueing in te schakelen op de interne interface waar pakketten de router verlaten.
OpenBSD ondersteunt twee bijkomende schedulers:
CBQ wachtrijen worden op een hiërachische manier gerangschikt. Aan het hoofd van de hiërarchie staat de root-wachtrij die de totale hoeveelheid beschikbare bandbreedte definieert. Kind-wachtrijen worden aangemaakt onder de root-wachtrij, en aan elk daarvan kan een bepaald deel van de bandbreedte van de root-wachtrij toegekend worden. Wachtrijen zouden bijvoorbeeld als volgt kunnen gedefinieerd worden:
In dit geval is de totale beschikbare bandbreedte op 2 megabits per seconde (Mbps) ingesteld. Deze bandbreedte wordt vervolgens gesplitst over drie kind-wachtrijen.
De hiërarchie kan verder ontvouwen worden door wachtrijen te definiëren binnen wachtrijen. Om bandbreedte gelijk te verdelen onder verschillende gebruikers en ook hun verkeer in te delen zodat bepaalde protocols andere niet verhongeren qua bandbreedte, zou een wachtrijstructuur als deze gedefinieerd kunnen worden:
Merk op dat op elk niveau de som van de bandbreedte toegekend aan elk van de wachtrijen niet meer bedraagt dan de bandbreedte toegekend aan de ouder-wachtrij.
Een wachtrij kan geconfigureerd worden om bandbreedte te lenen van zijn ouder indien de ouder een overschot aan bandbreedte beschikbaar heeft doordat deze niet gebruikt wordt door de andere kind-wachtrijen. Beschouw een wachtrij-setup als deze:
Indien het verkeer in de ftp wachtrij 900Kbps overschrijdt en verkeer in de UserA wachtrij minder is dan 1Mbps (omdat de ssh wachtrij minder gebruikt dan de haar toegekende 100Kbps), dan zal de ftp wachtrij de overschot-bandbreedte lenen van UserA. Op deze manier kan de ftp wachtrij meer gebruiken dan de haar toegekende bandbreedte wanneer ze met overbelasting te maken krijgt. Wanneer de ssh wachtrij haar belasting verhoogt, zal de geleende bandbreedte teruggegeven worden.
CBQ kent aan elke wachtrij een prioriteitsniveau toe. Wachtrijen met een hogere prioriteit genieten bij verstopping de voorkeur boven wachtrijen met een lagere prioriteit zolang beide wachtrijen dezelfde ouder gemeenschappelijk hebben (met andere woorden: zolang beide wachtrijen tot dezelfde vertakking behoren in de hiërarchie). Wachtrijen met dezelfde prioriteit worden verwerkt op een "round-robin" manier. Bijvoorbeeld:
CBQ zal de UserA en UserB wachtrijen verwerken op een "round-robin" manier -- geen van de wachtrijen zal boven de andere verkozen worden. Gedurende de tijd wanneer de UserA wachtrij verwerkt wordt, zal CBQ ook haar kind-wachtrijen verwerken. In dit geval heeft de ssh wachtrij een hogere prioriteit en zal een voorkeursbehandeling krijgen boven de ftp wachtrij als het netwerk verstopt zit. Merk op hoe de prioriteiten van de ssh en ftp wachtrijen niet vergeleken worden met de UserA en UserB wachtrijen omdat ze niet allemaal tot dezelfde vertakking in de hiërarchie behoren.
Bekijk voor een meer gedetailleerde kijk op de theorie achter CBQ alstublieft Referenties over CBQ.
De wachtrijstructuur in PRIQ is vlak -- u kan geen wachtrijen definiëren binnen wachtrijen. De root-wachtrij wordt gedefinieerd, die de totale hoeveelheid beschikbare bandbreedte instelt, en vervolgens worden sub-wachtrijen gedefinieerd onder de root. Beschouw het volgende voorbeeld:
De root-wachtrij is gedefinieerd met 2Mbps bandbreedte ter beschikking en er zijn drie sub-wachtrijen gedefinieerd. De wachtrij met de hoogste prioriteit (het hoogste prioriteitsgetal) wordt eerst bediend. Zodra alle pakketten in die wachtrij verwerkt zijn, of als vastgesteld wordt dat de wachtrij leeg is, gaat PRIQ verder met de wachtrij met de volgende hoogste prioriteit. Binnen een gegeven wachtrij worden pakketten op een First In First Out (FIFO) manier verwerkt.
Het is belangrijk op te merken dat u bij gebruik van PRIQ uw wachtrijen heel zorgvuldig moet plannen. Omdat PRIQ altijd een wachtrij met hogere prioriteit verwerkt vóór één met lagere prioriteit, is het mogelijk dat een wachtrij met hogere prioriteit ervoor zorgt dat pakketten in een wachtrij met lagere prioriteit vertraagd of gedropt worden als de wachtrij met hoge prioriteit een constante stroom van pakketten ontvangt.
RED is nuttig omdat het een situatie vermijdt gekend als globale synchronisatie en kan pieken van verkeer onderbrengen. Globale synchronisatie verwijst naar een verlies van totale doorvoer doordat pakketten van verscheidene verbindingen terzelfdertijd gedropt worden. Als verstopping zich bijvoorbeeld voordoet op een router die verkeer vervoert voor 10 FTP verbindingen en pakketten van al (of de meeste van) deze verbindingen worden gedropt (zoals het geval is met FIFO queueing), dan zal de totale doorvoer steil dalen. Dit is geen ideale situatie omdat het ervoor zorgt dat alle FTP verbindingen hun doorvoer verminderen en het betekent ook dat het netwerk niet meer op zijn maximale potentieel gebruikt wordt. RED vermijdt dit door willekeurig te kiezen van welke verbindingen het pakketten laat vallen in plaats van ze allemaal te kiezen. Verbindingen die grote hoeveelheden bandbreedte gebruiken hebben een grotere kans om hun pakketten gedropt te zien. Op deze manier zullen hoge bandbreedte verbindingen afgeremd worden, verstopping zal vermeden worden, en er zullen zich geen steile dalingen voordoen in de totale doorvoer. Bovendien kan RED pieken van verkeer aan omdat het begint met pakketten te laten vallen vóórdat de wachtrij vol komt te zitten. Wanneer er een piek van verkeer doorkomt zal er genoeg ruimte zijn in de wachtrij om de nieuwe pakketten te bevatten.
RED wordt best alleen gebruikt wanneer het transportprotocol op verstoppingsindicators van het netwerk kan antwoorden. In de meeste gevallen betekent dit dat RED gebruikt moet worden om TCP verkeer te queue'en en niet voor UDP of ICMP verkeer.
Bekijk voor een meer gedetailleerde kijk op de theorie achter RED alstublieft Referenties over RED.
Refereer voor meer informatie over ECN alstublieft naar RFC 3168.
Omdat ALTQ samengevoegd is met PF, moet PF ingeschakeld worden opdat queueing zou werken. Instructies over hoe PF in te schakelen, vindt u terug in Van Start Gaan.
Queueing wordt geconfigureerd in pf.conf. Er zijn twee types van opdrachten die gebruikt worden om queueing te configureren:
De syntaxis voor de altq on opdracht is:
altq on interface scheduler bandwidth bw qlimit qlim \
tbrsize size queue { queue_list }
Bijvoorbeeld:
altq on fxp0 cbq bandwidth 2Mb queue { std, ssh, ftp }Dit schakelt CBQ in op de fxp0 interface. De totale beschikbare bandbreedte is ingesteld op 2Mbps. Er zijn drie kind-wachtrijen gedefinieerd: std, ssh en ftp.
De syntaxis voor de queue opdracht is:
queue name [on interface] bandwidth bw [priority pri] [qlimit qlim] \
scheduler ( sched_options ) { queue_list }
Verdergaand met het voorbeeld hierboven:
queue std bandwidth 50% cbq(default)
queue ssh bandwidth 25% { ssh_login, ssh_bulk }
queue ssh_login bandwidth 25% priority 4 cbq(ecn)
queue ssh_bulk bandwidth 75% cbq(ecn)
queue ftp bandwidth 500Kb priority 3 cbq(borrow red)
Hier worden de parameters van de voorheen gedefinieerde wachtrijen ingesteld. Aan de std wachtrij wordt een bandbreedte van 50% van de root-wachtrij (of 1Mbps) toegekend en deze wachtrij wordt als de standaardwachtrij ingesteld. De ssh wachtrij wordt 25% van de bandbreedte van de root-wachtrij (500kb) toegekend en deze bevat ook twee kind-wachtrijen, ssh_login en ssh_bulk. De ssh_login wachtrij wordt een hogere prioriteit gegeven dan ssh_bulk en beide hebben ECN ingeschakeld. De ftp wordt een bandbreedte van 500Kbps toegekend en een prioriteit van 3 gegeven. Deze kan ook bandbreedte lenen wanneer overschot beschikbaar is en heeft RED ingeschakeld.
OPMERKING: Voor elke kind-wachtrij definitie wordt de bandbreedte gespecificeerd. Zonder de bandbreedte te specificeren, zal PF de wachtrij 100% van de bandbreedte van de ouder-wachtrij geven. In deze situatie zou dat een fout veroorzaken wanneer de regels ingeladen worden want als er een wachtrij is met 100% van de bandbreedte, kan er geen andere wachtrij op dat niveau gedefinieerd worden aangezien er geen bandbreedte meer vrij is om er aan toe te kennen.
Om verkeer toe te kennen aan een wachtrij wordt het queue sleutelwoord gebruikt in samenwerking met PF's filterregels. Beschouw bijvoorbeeld een set filterregels die een lijn als deze bevat:
pass out on fxp0 from any to any port 22
Pakketten die overeenstemmen met die regel kunnen toegekend worden aan een specifieke wachtrij door het queue sleutelwoord te gebruiken:
pass out on fxp0 from any to any port 22 queue ssh
Bij gebruik van het queue sleutelwoord met block opdrachten worden resulterende TCP RST of ICMP Unreachable pakketten toegekend aan de gespecificeerde wachtrij.
Merk op dat wachtrijtoewijzing kan gebeuren op een interface verschillend van degene die in de altq on opdracht werd gedefinieerd:
altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
queue std bandwidth 500Kb cbq(default)
queue ftp bandwidth 1.5Mb
pass in on dc0 from any to any port 21 queue ftp
Queueing wordt ingeschakeld op fxp0 maar de toewijzing gebeurt op dc0. Indien pakketten die overeenstemmen met de pass regel de interface fxp0 verlaten, zullen ze in de ftp wachtrij geplaatst worden. Dit type van queueing kan heel nuttig zijn op routers.
Normaal wordt slechts één wachtrijnaam gegeven met het queue sleutelwoord, maar als een tweede naam wordt gespecificeerd, zal die wachtrij gebruikt worden voor pakketten met een Type of Service (ToS) van low-delay en voor TCP ACK pakketten zonder netto gegevenslading. Een goed voorbeeld hiervan wordt gevonden bij het gebruik van SSH. SSH login sessies zullen de ToS op low-delay instellen terwijl SCP en SFTP sessies dit niet zullen doen. PF kan deze informatie gebruiken om pakketten die horen bij een loginverbinding in een verschillende wachtrij te queue'en dan die van niet-login verbindingen. Dit kan nuttig zijn om loginverbindingspakketten te prioritiseren boven bestandstransfer-pakketten.
pass out on fxp0 from any to any port 22 queue(ssh_bulk, ssh_login)
Dit kent pakketten die horen bij SSH loginverbindingen toe aan de ssh_login wachtrij en pakketten die horen bij SCP en SFTP verbindingen aan de ssh_bulk wachtrij. SSH loginverbindingen zullen dan hun pakketten verwerkt zien vóór SCP en SFTP verbindingen omdat de ssh_login wachtrij een hogere prioriteit heeft.
TCP ACK pakketten toekennen aan een wachtrij met hogere prioriteit is nuttig op asymmetrische verbindingen, d.w.z. verbindingen die verschillende upload- en downloadbandbreedtes hebben zoals ADSL lijnen. Bij een ADSL lijn, als het uploadkanaal maximaal benut wordt en er wordt een download gestart, dan zal de download nadeel ondervinden omdat de TCP ACK pakketten die hij moet verzenden in verstopping terechtkomen wanneer ze doorheen het uploadkanaal proberen te passeren. Tests hebben getoond dat om de beste resultaten te bekomen, de bandbreedte op de uploadwachtrij best ingesteld wordt op een waarde kleiner dan wat de verbinding aankan. Als een ADSL lijn bijvoorbeeld een maximale upload van 640Kbps heeft, zou het instellen van de bandwidth van de root-wachtrij op een waarde als 600Kb moeten leiden tot betere prestatie. Trial and error zal de beste bandwidth instelling opleveren.
Bij gebruik van het queue sleutelwoord met regels die keep state doen zoals:
pass in on fxp0 proto tcp from any to any port 22 flags S/SA \
keep state queue ssh
zal PF de wachtrij registreren in de toestandstabel-entry zodat pakketten die terug naar buiten keren uit fxp0 en overeenstemmen met de "stateful" verbinding, in de ssh wachtrij zullen belanden. Merk op dat zelfs al wordt het queue sleutelwoord gebruikt op een regel die binnenkomend verkeer filtert, het doel is om een wachtrij te specificeren voor het overeenkomstige buitengaande verkeer; de bovenstaande regel queue't geen binnenkomende pakketten.
[ Alice ] [ Charlie ]
| | ADSL
---+-----+-------+------ dc0 [ OpenBSD ] fxp0 -------- ( Internet )
|
[ Bob ]
In dit voorbeeld wordt OpenBSD gebruikt op een Internet gateway voor een klein thuisnetwerk met drie werkstations. De gateway voert pakketfiltering en NAT taken uit. De Internetverbinding is via een ADSL lijn aan 2Mbps neerwaarts en 640Kbps opwaarts.
Het queueing beleid voor dit netwerk:
Hieronder staat de regelset die aan dit netwerkbeleid tegemoetkomt. Merk op dat alleen de pf.conf opdrachten aanwezig zijn die rechtstreeks op het bovenstaande beleid van toepassing zijn; nat, rdr, opties, enz. zijn niet getoond.
# schakel queueing in op de externe interface om het verkeer te regelen
# dat naar het Internet gaat. gebruik de priq scheduler om alleen
# prioriteiten te regelen. stel de bandbreedte in op 610Kbps om de
# beste prestatie te halen uit de TCP ACK wachtrij.
altq on fxp0 priq bandwidth 610Kb queue { std_out, ssh_im_out, dns_out, \
tcp_ack_out }
# definieer de parameters voor de kind-wachtrijen.
# std_out - de standaard wachtrij. filterregels hieronder die niet
# expliciet een wachtrij specificeren, zullen hun verkeer
# aan deze wachtrij toegevoegd zien worden.
# ssh_im_out - interactief SSH en allerlei instant message verkeer.
# dns_out - DNS opzoekingen.
# tcp_ack_out - TCP ACK pakketten zonder nuttige gegevenslading.
queue std_out priq(default)
queue ssh_im_out priority 4 priq(red)
queue dns_out priority 5
queue tcp_ack_out priority 6
# schakel queueing in op de interne interface om verkeer te regelen dat
# van het Internet komt. gebruik de cbq scheduler om bandbreedte te
# regelen. max bandbreedte is 2Mbps.
altq on dc0 cbq bandwidth 2Mb queue { std_in, ssh_im_in, dns_in, bob_in }
# definieer de parameters voor de kind-wachtrijen.
# std_in - de standaard wachtrij. filterregels hieronder die niet
# expliciet een wachtrij specificeren, zullen hun verkeer
# aan deze wachtrij toegevoegd zien worden.
# ssh_im_in - interactief SSH en allerlei instant message verkeer.
# dns_in - DNS antwoorden.
# bob_in - bandbreedte gereserveerd voor Bobs werkstation. laat
# hem toe te lenen.
queue std_in bandwidth 1.6Mb cbq(default)
queue ssh_im_in bandwidth 200Kb priority 4
queue dns_in bandwidth 200Kb priority 5
queue bob_in bandwidth 80Kb cbq(borrow)
# ... in de filtering sectie van pf.conf ...
alice = "192.168.0.2"
bob = "192.168.0.3"
charlie = "192.168.0.4"
local_net = "192.168.0.0/24"
ssh_ports = "{ 22 2022 }"
im_ports = "{ 1863 5190 5222 }"
# filterregels voor fxp0 inwaarts
block in on fxp0 all
# filterregels voor fxp0 uitwaarts
block out on fxp0 all
pass out on fxp0 inet proto tcp from (fxp0) to any flags S/SA \
keep state queue(std_out, tcp_ack_out)
pass out on fxp0 inet proto { udp icmp } from (fxp0) to any keep state
pass out on fxp0 inet proto { tcp udp } from (fxp0) to any port domain \
keep state queue dns_out
pass out on fxp0 inet proto tcp from (fxp0) to any port $ssh_ports \
flags S/SA keep state queue(std_out, ssh_im_out)
pass out on fxp0 inet proto tcp from (fxp0) to any port $im_ports \
flags S/SA keep state queue(ssh_im_out, tcp_ack_out)
# filterregels voor dc0 inwaarts
block in on dc0 all
pass in on dc0 from $local_net
# filterregels voor dc0 uitwaarts
block out on dc0 all
pass out on dc0 from any to $local_net
pass out on dc0 proto { tcp udp } from any port domain to $local_net \
queue dns_in
pass out on dc0 proto tcp from any port $ssh_ports to $local_net \
queue(std_in, ssh_im_in)
pass out on dc0 proto tcp from any port $im_ports to $local_net \
queue ssh_im_in
pass out on dc0 from any to $bob queue bob_in
|
( IT Dept ) [ Baas z'n PC ]
| | T1
--+----+-----+---------- dc0 [ OpenBSD ] fxp0 -------- ( Internet )
| fxp1
[ COMP1 ] [ WWW ] /
| /
--+----------'
In dit voorbeeld fungeert de OpenBSD host als een firewall voor een bedrijfsnetwerk. Het bedrijf draait een WWW server in het DMZ gedeelte van hun netwerk waar klanten hun websites uploaden via FTP. Het IT departement heeft zijn eigen subnet verbonden met het hoofdnetwerk, en de baas heeft een PC op zijn bureau die gebruikt wordt voor e-mail en om op het web te surfen. De verbinding naar het Internet is via een T1 lijn tegen 1.5Mbps in beide richtingen. Alle andere netwerksegmenten gebruiken Fast Ethernet (100Mbps).
De netwerkbeheerder heeft over het volgende beleid beslist:
Hieronder staat de regelset die aan dit netwerkbeleid tegemoetkomt. Merk op dat alleen de pf.conf opdrachten aanwezig zijn die rechtstreeks op het bovenstaande beleid van toepassing zijn; nat, rdr, opties, enz. zijn niet getoond.
# schakel queueing in op de externe interface om pakketten te queue'en
# die naar het Internet gaan. gebruik de cbq scheduler zodat het
# bandbreedtegebruik van elke wachtrij geregeld kan worden. de max
# uitgaande bandbreedte is 1.5Mbps.
altq on fxp0 cbq bandwidth 1.5Mb queue { std_ext, www_ext, boss_ext }
# definieer de parameters voor de kind-wachtrijen.
# std_ext - de standaard wachtrij. ook de standaard wachtrij voor
# buitengaand verkeer op fxp0.
# www_ext - container-wachtrij voor WWW server wachtrijen. beperk
# tot 500Kbps.
# www_ext_http - http verkeer van de WWW server; hogere prioriteit.
# www_ext_misc - alle niet-http verkeer van de WWW server.
# boss_ext - verkeer afkomstig van de computer van de baas.
queue std_ext bandwidth 500Kb cbq(default borrow)
queue www_ext bandwidth 500Kb { www_ext_http, www_ext_misc }
queue www_ext_http bandwidth 50% priority 3 cbq(red borrow)
queue www_ext_misc bandwidth 50% priority 1 cbq(borrow)
queue boss_ext bandwidth 500Kb priority 3 cbq(borrow)
# schakel queueing in op de interne interface om het verkeer te regelen
# dat van het Internet of de DMZ komt. gebruik de cbq scheduler om de
# bandbreedte van elke wachtrij te regelen. bandbreedte is op deze
# interface ingesteld op het maximum. verkeer afkomstig van de DMZ zal
# al deze bandbreedte kunnen gebruiken terwijl verkeer afkomstig van
# het Internet beperkt zal worden tot 1.0Mbps (omdat 0.5Mbps (500Kbps)
# toegekend wordt aan fxp1).
altq on dc0 cbq bandwidth 100% queue { net_int, www_int }
# definieer de parameters voor de kind-wachtrijen.
# net_int - container-wachtrij voor verkeer vanaf het Internet.
# bandbreedte is 1.0Mbps.
# std_int - de standaardwachtrij. ook de standaardwachtrij voor uitgaand
# verkeer op dc0.
# it_int - verkeer naar het IT Dept netwerk; reserveer 500Kbps voor hen.
# boss_int - verkeer naar de PC van de baas; ken een hogere priorieit toe.
# www_int - verkeer vanaf de WWW server in de DMZ; volle snelheid.
queue net_int bandwidth 1.0Mb { std_int, it_int, boss_int }
queue std_int bandwidth 250Kb cbq(default borrow)
queue it_int bandwidth 500Kb cbq(borrow)
queue boss_int bandwidth 250Kb priority 3 cbq(borrow)
queue www_int bandwidth 99Mb cbq(red borrow)
# schakel queueing in op de DMZ interface om het verkeer te regelen dat
# bestemd is voor de WWW server. cbq zal gebruikt worden op deze
# interface aangezien gedetailleerde regeling van bandbreedte noodzakelijk
# is. bandbreedte op deze interface is ingesteld op het maximum.
# verkeer vanaf het interne netwerk zal al deze bandbreedte kunnen
# gebruiken terwijl verkeer vanaf het Internet beperkt zal worden tot
# 500Kbps.
altq on fxp1 cbq bandwidth 100% queue { internal_dmz, net_dmz }
# definieer de parameters voor de kind-wachtrijen.
# internal_dmz - verkeer vanaf het interne netwerk.
# net_dmz - container-wachtrij voor verkeer vanaf het Internet.
# net_dmz_http - http verkeer; hogere prioriteit.
# net_dmz_misc - alle niet-http verkeer. dit is ook de standaardwachtrij.
queue internal_dmz bandwidth 99Mb cbq(borrow)
queue net_dmz bandwidth 500Kb { net_dmz_http, net_dmz_misc }
queue net_dmz_http bandwidth 50% priority 3 cbq(red borrow)
queue net_dmz_misc bandwidth 50% priority 1 cbq(default borrow)
# ... in de filtering sectie van pf.conf ...
main_net = "192.168.0.0/24"
it_net = "192.168.1.0/24"
int_nets = "{ 192.168.0.0/24, 192.168.1.0/24 }"
dmz_net = "10.0.0.0/24"
boss = "192.168.0.200"
wwwserv = "10.0.0.100"
# standaard weigeren ("default deny")
block on { fxp0, fxp1, dc0 } all
# filterregels voor fxp0 inwaarts
pass in on fxp0 proto tcp from any to $wwwserv port { 21, \
> 49151 } flags S/SA keep state queue www_ext_misc
pass in on fxp0 proto tcp from any to $wwwserv port 80 \
flags S/SA keep state queue www_ext_http
# filterregels voor fxp0 uitwaarts
pass out on fxp0 from $int_nets to any keep state
pass out on fxp0 from $boss to any keep state queue boss_ext
# filterregels voor dc0 inwaarts
pass in on dc0 from $int_nets to any keep state
pass in on dc0 from $it_net to any queue it_int
pass in on dc0 from $boss to any queue boss_int
pass in on dc0 proto tcp from $int_nets to $wwwserv port { 21, 80, \
> 49151 } flags S/SA keep state queue www_int
# filterregels voor dc0 uitwaarts
pass out on dc0 from dc0 to $int_nets
# filterregels voor fxp1 inwaarts
pass in on fxp1 proto { tcp, udp } from $wwwserv to any port 53 \
keep state
# filterregels voor fxp1 uitwaarts
pass out on fxp1 proto tcp from any to $wwwserv port { 21, \
> 49151 } flags S/SA keep state queue net_dmz_misc
pass out on fxp1 proto tcp from any to $wwwserv port 80 \
flags S/SA keep state queue net_dmz_http
pass out on fxp1 proto tcp from $int_nets to $wwwserv port { 80, \
21, > 49151 } flags S/SA keep state queue internal_dmz
|
[Vorige: Ankers] [Inhoud] [Volgende: Adres Pools en Load Balancing]
![[terug]](../../../images/back.gif){kind=small}
www@openbsd.org