Tyblog

” Opbygning af min ideelle router til $50 ”

Efter min Asus N66U gik i vasken, overvejede jeg et par muligheder: en anden alt-i-en-router, opgradere til noget som en EdgeRouter eller brygge noget brugerdefineret.Da jeg læste Ars Technica-artiklen, der hylder fordelene ved at bygge sin egen router, var det så godt som afgjort: Jeg har lidt af et psykologisk kompleks, når det gælder om at rulle mine egne overkonstruerede løsninger, men jeg satte mig nogle generelle mål: slutresultatet skulle være billigt, strømbesparende, understøttet af Linux og udvideligt. ARM-boards opfylder i øvrigt mange af disse krav, og nogle som Raspberry Pi har vakt så meget opsigt i fællesskabet, at der er stor opbakning til ARM-platformen, selv om den kan føles fremmed i forhold til x86.

Det er lykkedes mig at stykke en enhed sammen, som ikke kun er skidebillig i forhold til hvad den gør, men som også er ekstremt dygtig i sig selv. Hvis du har interesse i at bygge din egen hjemme-router, vil jeg her demonstrere, at det ikke kun er muligt, men relativt nemt at gøre, og at det giver en enorm mængde nyttefunktioner – fra trafikformning, til netflow-overvågning, til dynamisk DNS.

Jeg byggede den ved hjælp af espressobin, Arch Linux Arm, og Shorewall.

Dette billede viser boardet indkapslet i et 3d-printet kabinet. espressobin er desværre ikke populær nok til at kunne prale af et stort udvalg af kabinetter, der kan købes, som Raspberry Pi har, men der findes nogle gode modeller til 3d-print.

Som en sidebemærkning er den følgende dokumentation ikke ment som en omfattende trin-for-trin guide til at gøre det samme selv.Selv om jeg ønsker at dække mange af de valg, der gik ind i byggeriet, bør konfigurering af noget så vigtigt som en router/firewall virkelig ikke være et copy/paste job og ville bedre være løst guidet af trinene her med en grundig forståelse af hvordan og hvorfor.

• Det hvorfor
• Første del: Hardware
  • Hvad med WiFi?
• Anden del: Software
  • Bedriftssystem
  • Firewall
• Tredje del: Den grundlæggende opbygning
  • OS-installation
  • OS-konfiguration
  • Firewall
  • DHCP
• Del fire: Intermezzo
• Femte del: Opgraderinger
  • Netflow Monitoring
  • Traffic Shaping
• Conclusion

The Why

Der er masser af solide routere derude, du kan købe, som ikke er ISP’s dækbrande på lager og som sandsynligvis ville være mere end velegnede (jeg kigger kærligt på dig, EdgeRouter Lite).Så hvorfor gider du alt dette?Der er nogle legitime fordele her:

• Det er faktisk meget overkommeligt. Min router har bestået mine benchmarks med bravur, og har alle de funktioner, jeg kunne trække i Linux (hvilket er en lang liste).
• Det er sikkert. Jeg har det som om der bliver annonceret en ny sårbarhed for en eller anden forbrugernetværkskant-enhed hver måned. Sammenlign det med en selvadministreret firewall, og jeg ved præcis, hvilke tjenester der er eksponeret (og hvis iptables er brudt, har verden større problemer). For eventuelle nej-sigere, i øvrigt, den eneste port lytter på min firewall er en tilfældig højt nummereret port for public-key only ssh-autentifikation. Så ja, jeg mener faktisk, at den er mere sikker end en eller anden Huawei forbrugerrouter.
• Den har gode funktioner. Sure, min espressobin kan route og fungere som en firewall, men jeg har droppet i nogle andre nyttige funktioner så godt.
• Det er performant. I de mindre benchmarks, jeg udførte, kan espressobin’en virkelig skubbe trafik uden at svede.
• Det var virkelig sjovt at bygge. Hvis du a) har brug for en ny router eller b) ønsker at sætte tænderne i et single-board ARM-projekt, kunne dette være et godt valg.

Del et: Hardware

Teknisk set kunne du sammensætte en router ved hjælp af en hvilken som helst computer med to NIC’er, men vi kan gøre det lige så godt med mindre strøm, en mindre formfaktor og til en billigere pris.ARM-boards rammer det søde punkt: De er superbillige, mere kraftfulde end man skulle tro, og de er godt understøttet med så mange varianter på markedet.

Den mest kendte konkurrent er Raspberry Pi, men uden to NIC’er eller gigabit-netværk er det ikke en god mulighed.Plus, du betaler for ting som en GPU, der ikke er nødvendige i en headless netværksenhed.

Den gode nyhed er, at sidste år blev espressobin udgivet, og den er superdygtig.Den føles specialbygget til denne type ting: gigabit-netværk, en indbygget switch og ingen dikkedarer, som du ellers ville have brug for til noget mere generelt (der er ikke engang en skærm ud, kun en seriel konsol).

Men selvom kortet er ret ungt, understøtter både Armbian og Arch Linux Arm hardwaren, og begge projekter gør et godt stykke arbejde med det.Hvis du ikke har udforsket Linux på ARM, er der ikke meget at frygte her.Armbian og Arch Linux Arm leverer alt, hvad du har brug for til aarch64 nativt i distributionens repos, så der er ikke meget, du vil løbe ind i, der føles fremmed på en 64-bit ARM-chip, og det føles bestemt det værd, når du tager højde for hardwarens overkommelighed og det lave strømfodaftryk.

Her er nogle af højdepunkterne for mig:

• Kortet indeholder en indbygget Topaz-netværksswitch. I min netværkstest er trafik, der kun krydser LAN-grænsefladerne, ikke til at skelne hastighedsmæssigt fra trafik, der passerer gennem en vanilla-switch. Hvis du streamer fra en NAS eller på anden måde har høje krav til kommunikation mellem enhederne, der krydser routeren, kan dette gøre en stor forskel.
• Den serielle konsol er en førsteklasses borger. På mine Raspberry Pis blev jeg nogle gange frustreret over at skulle række ud efter min HDMI-skærm, når jeg skulle debugge problemer, men espressobin har en mikro-USB seriel port for nem konsoladgang.
• Den aarch64-chip har været fantastisk. Ikke alene har den håndteret alt, hvad jeg har kastet på den, men vidste du, at den er upåvirket af meltdown? Cortex-A53-chippene er ikke påvirket af den spekulative eksekveringsfejl, så det er en ekstra bonus.

Hvad med WiFi?

Jeg vil her gøre en lille bemærkning om, at jeg også forsøgte at bruge espressobin som et trådløst adgangspunkt. kortet har et mini PCIe-slot velegnet til et trådløst kort, og selv om det burde have virket, kan jeg definitivt rapportere, at det ikke er en god idé.

Suden at gå ind i smertefulde detaljer, er der en masse problemer, der ikke gør det værd at anstrenge sig. Jeg kunne ikke få 5Ghz-båndene til at virke under noget scenarie, min 2,4Ghz hostapd-tjeneste blev uopmærksom hver tolvte time eller deromkring, og hastighederne var chokerende dårlige.

Generelt tror jeg, at dette er en fejl i espressobin-hardwaren. kort, der ellers burde være godt understøttet i Linux (nogle af de kort, jeg testede, var ath9k- eller ath10k-baserede), fungerer simpelthen ikke med kortets mPCIe-interface.Selv de officielt anbefalede kort havde problemer – RTL8191SE virkede med mellemrum, og selv det kort, der er produceret af Globalscale, virker ikke som annonceret. i øvrigt, hvis du finder et kort med god understøttelse på espressobin, så smid et svar på den relaterede forumtråd, jeg startede for at diskutere dette problem.

Med alt dette sagt, var det min hensigt fra starten af dette projekt at adskille mit AP fra min router, uanset om jeg endte med at bruge et espressobin eller ej.At holde opgaverne med firewalling/routing adskilt fra trådløs er en dejlig adskillelse af bekymringer, og du kan få meget gode dedikerede AP-enheder uden nogen funktion ud over at udsende et signal for at holde det enkelt og kraftfuldt.

For hvad det er værd, endte jeg med at købe en Ubiquity UniFi-enhed og har været helt tilfreds med den.

Del to: Software

Der er to store valgmuligheder her: OS og firewalling software.

Operating System

Det første valg du skal træffe er, om du vil håndrulle dette fra en distribution, der understøtter aarch64 eller bruge en forudbygget firmware-lignende løsning som OpenWRT.Personligt har jeg fundet ud af, at når jeg bruger en krympet løsning som Tomato/OpenWrt eller FreeNAS til et build, bliver jeg som regel frustreret uden at kunne komme rigtigt ind og finjustere tingene, så jeg vil bruge en alm. Linux-distribution til operativsystemet.

Som jeg tidligere har nævnt, understøtter Armbian og Arch Linux ARM boardet, og espressobin har officiel dokumentation for Ubuntu (samt Yocto, som jeg ikke var bekendt med før nu).Jeg vil ikke fortælle dig, hvad der er bedst til dit brugsscenarie, men her er hvorfor jeg foretrak Arch Linux Arm:

• Jeg er helt solgt til rolling release-distributioner.
• Jeg er også solgt til at køre på toppen af blødende cutting-edge-distributioner. I tilfælde af en router er det rart at være tæt på upstream, når potentielt sikkerhedsrelaterede opdateringer frigives.
• Arch vil give os en ren tavle at bygge på uden nogen fremmede tjenester. Det betyder, at vi med en minimal base kan vide præcis, hvad vi vil have installeret, eksponeret og kørende, når vi har sat brikkerne sammen.
• Jeg kender og kan lide Arch Linux ARM-folkene. Hej WarheadsSE!

Firewall

Nogle navne som PFSense kommer jeg straks til at tænke på, men jeg vil rigtig gerne køre noget på Linux, da jeg kender det meget bedre end en BSD (plus, de bedste OS-muligheder for espressobin er Linux-baserede).

Linux firewall landskabet er ret bredt. selvom vi næsten helt sikkert vil bruge noget iptables-baseret, er der masser af tjenester på højere niveau, der sidder ovenpå iptables (ufw, firewalld, osv.)Selv om du kan skrive dit eget enkle iptables-regelsæt og fortsætte med det, valgte jeg at bruge en firewalltjeneste, da det giver os en god stamviden, som Linux-fællesskabet har opbygget i løbet af de mange år, de har administreret iptables-firewalls.

Generelt bør en god firewall-dæmon:

• Passe ind i profilen “sundt OSS-projekt”. Det betyder, at den bør være aktivt vedligeholdt, have eksisteret i et stykke tid og have en anstændig udbredelse.
• Undergå kompleksitet. Enkle designs er nemmere at fejlfinde, udvide og betjene.
• Understøt nogle nice-to-have-funktioner, såsom understøttelse af traffic shaping og nem port forwarding-konfiguration.

Efter at have rodet rundt i et stykke tid, faldt jeg for Shorewall. her er nogle af de mere bemærkelsesværdige grunde til, at jeg valgte den:

• Konfigurationsflowet er compile-then-apply (kompilér derefter). Dette sikrer, at vores regelsæt er fornuftigt, før det anvendes, hvilket også betyder, at der ikke er nogen resident dæmon, der forbruger enhedens ressourcer, hvilket er relevant på en lille single-board computer.
• Det kommer med masser af dejlig historisk viden indbygget, så de iptables-regler, der bliver spyttet ud, håndterer masser af edge cases, som du normalt ikke ville tænke på.
• Jeg vil dække mere af dette senere, men pakkemarkering og native understøttelse af traffic shaping gør classful qdiscs let.

Del tre: Den grundlæggende opbygning

Dette indlæg er ikke beregnet til at være en omfattende vejledning, men jeg ønskede at medtage de overordnede punkter, så det er tydeligt, hvor let dette er at sammensætte.

OS-installation

Dette er nemt – følg blot Arch Linux Arm espressobin-siden.Det er især vigtigt at bemærke de tilføjede flag på mkfs.ext4-kommandoen og den yderligere U-Boot-konfiguration.

OS Config

Generelt er Arch Linux Arm-installationer ret godt indstillet fra starten af. Selvfølgelig skal du oprette en ikke-root-bruger til at administrere med, som ikke er standardkontoen, så husk at deaktivere alarm-brugeren, ændre alle adgangskoder og opdatere systemet.

Som en sidebemærkning vil jeg stærkt anbefale at installere pacmatic-pakken og bruge den i stedet for den almindelige pacman.Den vil automatisk registrere opdateringer til konfigurationsfiler og hjælpe med at flette dem, samt inline vigtige nyheder for breaking package changes.

Derudover vil jeg foreslå at opsætte etckeeper til at spore din firewallkonfiguration (Arch-wikien har en god introduktion) Jeg har sat min op til automatisk at skubbe til en privat hosted gitolite repo.For at være helt ærlig kan jeg ikke lide alle konfigurationshåndteringsløsninger derude, og næsten alle vores ændringer er begrænset til /etc, så dette er en god nok backup-løsning for mig i hvert fald.

Bemærk, at standardnetværkskonfigurationen for espressobin fungerer godt til routerens brugssituation:

• Både lan-interfaces, lan0 og lan1, er bridget til br0-grænsefladen. Dette giver os mulighed for at centralisere privat-netværksvendte ting som dnsmasq på en enkelt virtuel grænseflade.
• Den offentligtvendte grænseflade er wan. Det henter sin adresse fra den opstrøms ISP via DHCP.

De eneste ændringer, der er nødvendige for at få br0 og wan sat op til vores router, er to tilføjelser: For det første skal LAN-interfacet tildeles en statisk IP, da det bliver routeren, og IP forwarding og IP masquerading skal aktiveres i /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Og bekræft, at WAN-grænsefladen vil anmode om en adresse fra ISP’en i /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Jeg indstiller UseDNS=no her, da jeg foretrækker at bruge OpenNIC-servere i stedet for min opstrøms ISP’s – jeg nævner, hvor du skal indstille disse senere.

Firewall

Arch Linux ARM aarch64 repositories har fået den nyeste version af Shorewall, som er den jeg brugte. mine konfigurationer er ikke så fancy, og hvis du seriøst overvejer at implementere Shorewall med en forbindelse til det vilde internet, anbefaler jeg stærkt at læse hele Shorewalls introduktion til en firewall med to interfaces.Den dækker det grundlæggende i hvordan du skal sætte tingene op med en fin opsummering af routing og firewalling generelt.

Grundlæggende skal du sætte br0 og wan interface i de rigtige zoner og indstille eventuelle nødvendige regler i /etc/shorewall/rules.Husk at lade værter på dit LAN bruge din DNS-server:

DNS(ACCEPT) loc $FW

Du skal bekræfte, at DHCP er tilladt på LAN-grænsefladen i filen interfaces.

Jeg vil her bemærke, at jeg ramte en fejl med Shorewall under min firewall-opsætning, som jeg fandt ud af var patchet bogstaveligt talt dagen før – og Arch Linux ARM havde allerede den opdaterede pakke i upstream-repositorierne. 1 point for at bruge opdaterede distro’er.

DHCP

Ddnsmasq passer perfekt til en hjemme-router. den samler en DNS- og DHCP-server i en letvægts-dæmon, der håndterer alt, hvad du har brug for fra et lille netværk, og den er moden nok til, at der er masser af dokumentation, der bruger den til netop det brugsscenarie.

Note: Jeg forsøgte at bruge systemd’s indbyggede DHCP-server, som du kan indstille med DHCPServer= i .network-filer, da det virkede som en letvægtsmetode til at køre en DHCP-server uden ekstra software.Uden at være for udførlig, er det ikke det værd, en væsentlig grund er, at der ikke er nogen måde at finde aktuelle adresselejekontrakter på.

Der er masser af indstillinger, der bør indstilles her, men de vigtigste er:

# Listen for requests on this interfaceinterface=br0# Address range to draw fromdhcp-range=192.168.1.5,192.168.1.250,255.255.255.0,24h# Default route for clients (the address we used in /etc/systemd/network/br0.network)dhcp-option=option:router,192.168.1.1# Instead of doling out DNS servers from your upstream ISP who may do dumb# things for things like unresolvable names, you can rely on other DNS servers.# These are from OpenNIC.server=192.52.166.110server=66.70.211.246server=69.195.152.204server=158.69.239.167

Hvis du har brug for statiske tildelinger eller aliaser, er de også nemme at tilføje.

Del fire: Interlude

Med espressobin, der betjener DHCP- og DNS-anmodninger på br0, firewalling via Shorewall og routing af pakker mellem LAN og WAN, er det en fungerende router. på dette tidspunkt er det kun nødvendigt at forbinde WAN-porten til ISP’en opstrøms og de to lan0/lan1-porte til enheder eller en anden switch.

Det er dog kun en begyndelse. hvis vi virkelig vil betragte dette som en routererstatning, er der nogle virkelig fede ting, vi kan gøre for at forbedre dens muligheder yderligere, så den ikke føles som en nedgradering fra noget som min gamle Asus N66U.

Del fem: Opgraderinger

Jeg boltede følgende funktioner på min vanilla espressobin-router, som jeg vil dække hver for sig:

• Netflow-overvågning
• Trafikformning

Netflow-overvågning

Trafiksynlighed er noget, som jeg fandt virkelig værdifuldt med min Asus Merlin firmware til at spore brugen.Netflow er de facto-standarden for denne slags ting, og blandt alle de tilgængelige muligheder kan jeg virkelig godt lide ipt-netflow, fordi det er et indfødt kernemodul, så der er meget lidt overhead og er meget aktivt vedligeholdt.

Det viser sig, at jeg sandsynligvis er den første person, der bruger det på aarch64-arkitekturen, fordi jeg fik hjælp til at få det understøttet på aarch64-chipset. projektets vedligeholder var (og har været) super lydhør over for fejlrettelser, så jeg har ikke haft problemer med at sikre, at modulet er understøttet på de nyeste kerner, som Arch Linux ARM-projektet kører på.

Det er et spørgsmål om at installere ipt-netflow-dkms-git-pakken fra AUR.Den vil bygge til din kerne, fordi dkms er fantastisk, og jeg smed følgende ind i /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Det vil indlæse den, og du konfigurerer den i /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Hvor $ip er din netflow-destination.Endelig bliver trafikken fanget ved at flyde ind i et særligt iptables-mål, hvilket kan gøres direkte fra shorewall, bekvemt nok.I /etc/shorewall/start:

run_iptables -I INPUT -j NETFLOWrun_iptables -I FORWARD -j NETFLOWrun_iptables -I OUTPUT -j NETFLOWreturn 0

Dette dirigerer alle pakker på routeren til først at gå ind i NETFLOW-målet før noget andet, som behandler pakkerne og sender dem tilbage til at flyde gennem de normale regler, som Shorewall sætter op.

Selvfølgelig har ipt-netflow brug for et sted at sende netflow-logs til, men det ligger uden for rammerne af dette indlæg.I mit tilfælde har jeg en Logstash-instans, der kører på mit netværk med netflow-modulet, der kører og aggregerer hændelser i en Elasticsearch-klynge, hvilket giver mig nogle praktiske dashboards og mulighed for at visualisere en lang række oplysninger om mit netværk.Der er nogle standard dashboards:

Inklusive nogle ret fede, som f.eks. et Geo-IP dashboard:

Den mest relevante måling, som jeg er interesseret i, er dog mit samlede båndbreddeforbrug, fordi jeg har en antediluviansk internetudbyder, der bekymrer sig om datalofter.Heldigvis er det nemt med de netflow-data, jeg indsamler: Vi kan bare bede Elasticsearch om at summere nogle felter og nemt få disse målinger.Følgende dashboard har to visualiseringer:

• Måleren sammenligner summen over den pågældende tidsperiode med det loft, min internetudbyder har sat for mig, så jeg nemt kan se, hvor mit nuværende forbrug ligger i forhold til loftet.
• Tidsrækken plotter båndbredden i bytes over tid for at se, hvornår jeg bruger den båndbredde.

Et særligt fedt ved denne opsætning er, at fordi vi gemmer netflowmetrikkerne i Elasticsearch i stedet for en anden datastore eller tidsseriedatabase, kan jeg faktisk fokusere forespørgslerne til disse dashboards for at gøre ting som kun at summere samlede bytes for bestemte CIDR-intervaller, fordi den underliggende lagringsmotor (Lucene) forstår IP-adresser nativt.For eksempel følgende forespørgsel i Kibana:

NOT (netflow.dst_addr:"192.168.1.0/24" AND netflow.src_addr:"192.168.1.0/24")

Vil effektivt filtrere potentielt store klumper af båndbredde, der sker mellem værter på mit LAN, såsom streaming mellem min Kodi host og NAS-maskine.Cool.

Traffic Shaping

Dette blev til et ret massivt foretagende, der var et fascinerende kaninhul at forsvinde ned i.Nogle stock og de fleste brugerdefinerede router firmwares tilbyder en form for QoS eller trafikformning, så jeg håbede at kunne gøre det samme på min brugerdefinerede router for at beskytte noget af min trafik (som Overwatch) mod høje latenstider.

Verden af QoS teknologi er et fascinerende sted.Mens du kan stole på nogle enkle ordninger som et HTB-filter (hierarchical token bucket), er fremskridtene inden for pakkefiltrering overraskende aktive, og der er masser af interessante tilgange.

Det, jeg til sidst besluttede mig for, var et HFSC-filter (hierarchical fair-service curve).Jeg skal være ærlig: matematikken bag det er så langt ude af min liga, at jeg måtte læse flere resuméer, der forsøgte at bryde det ned for normale mennesker, og den bedste forklaring, der gav mening for mig, var en fremragende gist, som jeg faldt over fra GitHub-brugeren eqhmcow, der forklarer fordelene ved og brugen af HFSC i praksis.

Tl;dr er dette: Med en HFSC-trafikstyringsklasse kan du meget effektivt prioritere trafik og opnå en god balance mellem strømme, der kræver høj båndbredde og lave latenstider. det er ikke en magisk kugle – du skal stadig markere, hvilke typer trafik der er latenstidsfølsomme – men det har fungeret ret godt for mig.Uden reglerne på plads vil en Steam- eller Blizzard Launcher-download dræbe ping-tider, mens aktive HFSC-regler elegant vil trimme disse tunge dele af trafikken for at sikre, at interaktive streams ikke påvirkes. det er virkelig godt!

Den førnævnte gist gør et godt stykke arbejde med at lægge ud, hvordan du opsætter dine tc-klasser fra bunden af. Men Shorewall kan faktisk håndtere classful trafikstyring nativt, så vi kan ret nemt opsætte kraftfulde QoS-regler.De følgende konfigurationsfiler er baseret på mine målte båndbreddehastigheder, som er ca. 230 down og 10 up.

Det første skridt er at indstille de relevante tc-klasser for hver enhed i tcdevices-filen:

# cat /etc/shorewall/tcdevices#INTERFACE 97%_down 90%_up options(set hfsc)wan 224mbit:200kb 9mbit hfscbr0 1000mbit:200kb 1000mbit hfsc

Her får LAN-grænsefladen br0 fuld gigabit, men WAN-grænsefladen wan får 97 % af sin down-hastighed og 90 % af min tilgængelige up-hastighed.Begrundelsen for disse tal er forklaret i gist – vi genskaber stort set dette regelsæt i Shorewall-termer.

Dernæst skal du definere, hvordan pakkemærker skal mappe til tc-klasser i tcclasses-filen:

# cat /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIO OPTIONSwan:10 1 full/2:10ms:1540 full 1 tcp-ackwan:11 3 full/2:10ms:1540 full/2 2 defaultbr0:20 2 full*9/10:10ms:1540 full*9/10 1 tcp-ackbr0:21 3 115mbit:10ms:1540 224mbit 2 default

Dette vil droppe vigtig/interaktiv trafik i klasser, der får højere prioritet.Vi skal naturligvis også markere de pakker, der skal have denne højere prioritet, hvilket gøres i mangle:

# cat /etc/shorewall/mangle# ICMP pingMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-requestMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply# sshMARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp ssh# Overwatch, Hearthstone, Diablo. 3478-3497 are very general RTP ports.MARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp,udp bnetgame,blizwow,6113MARK(1-2) 0.0.0.0/0 0.0.0.0/0 udp 3478-3497,5060,5062,6120,6250,12000-64000# Local trafficMARK(1-2) 192.168.1.0/24 192.168.1.0/24