🥇Analyse af det mest demokratiske SD-WAN: arkitektur, opsætning, administration og faldgruber

Judging by the number of questions we have started receiving about SD-WAN, the technology has begun to take root in Denmark. Vendors, of course, are not idle and are offering their concepts, while some brave pioneers are already implementing them in their networks.

Vi arbejder næsten med alle leverandører, og i løbet af de seneste år har jeg haft mulighed for at dykke ned i arkitekturen for hver større udvikler af softwaredefinerede løsninger i vores laboratorium. SD-WAN-løsningen fra Fortinet skiller sig lidt ud, da de simpelthen har indbygget funktionalitet til belastningsbalancering mellem kommunikationslinjer i softwaren til firewall. Løsningen er mere demokratisk, hvilket gør, at den ofte tiltrækker virksomheder, der endnu ikke er klar til store forandringer, men ønsker at udnytte deres kommunikationskanaler mere effektivt.

I denne artikel vil jeg fortælle, hvordan man konfigurerer og arbejder med SD-WAN fra Fortinet, hvem der vil have gavn af denne løsning, og hvilke faldgruber man kan støde på her.

De mest markante spillere på SD-WAN-markedet kan opdeles i to typer:

1. Startups, der har udviklet SD-WAN-løsninger fra bunden. De mest succesrige af disse får et kæmpe udviklingsboost når de bliver opkøbt af store virksomheder – det er historien om Cisco/Viptela, VMWare/VeloCloud, Nuage/Nokia.

2. Store netværksleverandører, der har skabt SD-WAN-løsninger ved at udvikle programmabilitet og styring af deres traditionelle routere – det er historien om Juniper, Huawei.

Fortinet har fundet sin vej. I firewall-softwaren blev der integreret funktionalitet, der muliggør at samle deres grænseflader i virtuelle kanaler og balancere mellem dem ved hjælp af komplekse algoritmer, som er mere avancerede end traditionel routing. Denne funktion kaldes SD-WAN. Kan det, som Fortinet har gjort, kaldes SD-WAN? På markedet er der gradvist ved at danne sig en forståelse for, at Software-Defined betyder adskillelse af Control Plane fra Data Plane, dedikerede controllere og orkestratorer. Fortinet har intet af det. Centraliseret styring er valgfri og tilbydes ved hjælp af den traditionelle løsning Fortimanager. Men efter min mening er det ikke værd at søge efter abstrakt sandhed eller bruge tid på diskussioner om terminologi. I den virkelige verden har enhver tilgang sine fordele og ulemper. Den bedste løsning er at forstå dem og være i stand til at vælge løsninger, der opfylder opgaverne.

Jeg vil forsøge at fortælle, hvordan SD-WAN fra Fortinet ser ud og hvad det kan, med screenshots i hånden.

Hvordan alt er arrangeret

Lad os antage, at du har to filialer, der er forbundet med to datatransmissionskanaler. Disse datatransmissionskanaler samles i en gruppe, ligesom almindelige Ethernet-grænseflader samles i LACP-Port-Channel. De garvede vil huske PPP Multilink – også en passende analogi. Kanalerne kan være fysiske porte, VLAN SVI samt VPN eller GRE-tunneler.

VPN eller GRE bruges typisk til at forbinde lokale netværk i filialer over internettet. Fysiske porte bruges ved tilstedeværelse af L2-forbindelser mellem steder, eller ved forbindelse over dedikeret MPLS/VPN, hvis vi er tilfredse med forbindelsen uden Overlay og kryptering. Endnu et scenarie, hvor fysiske porte bruges i SD-WAN-gruppen, er balancering af lokal udgang for brugere til internettet.

På vores stand er der fire firewalls og to VPN-tunneler, der arbejder gennem to "telekommunikationsoperatører". Skemaet ser således ud:

VPN-tunneler er konfigureret i interface-tilstand, så det ligner Point-to-Point-forbindelser mellem enheder med IP-adresser på P2P-grænseflader, som kan pinge og bekræfte, at forbindelsen gennem den specifikke tunnel fungerer. For at kryptere trafik og sende den til den modsatte side er det tilstrækkeligt at rute den gennem tunnelen. Alternativt kan sortering af trafik til kryptering ved hjælp af subnetlister forvirre administratoren, efterhånden som konfigurationen kompliceres. I et stort netværk kan ADVPN-teknologi anvendes til at opbygge VPN, hvilket er et alternativ til Cisco's DMVPN eller Huaweis DVPN, der forenkler opsætningen.

Konfiguration af Site-to-Site VPN for to enheder med BGP-routing på begge sider

„Datacenter“ (DC)
„Filial“ (BRN)

config system interface
edit "WAN1"
set vdom "Internet"
set ip 1.1.1.1 255.255.255.252
set allowaccess ping
set role wan
set interface "DC-BRD"
set vlanid 111
next
edit "WAN2"
set vdom "Internet"
set ip 3.3.3.1 255.255.255.252
set allowaccess ping
set role lan
set interface "DC-BRD"
set vlanid 112
next
edit "BRN-Ph1-1"
set vdom "Internet"
set ip 192.168.254.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.2 255.255.255.255
set interface "WAN1"
next
edit "BRN-Ph1-2"
set vdom "Internet"
set ip 192.168.254.3 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.4 255.255.255.255
set interface "WAN2"
next
end

config vpn ipsec phase1-interface
edit "BRN-Ph1-1"
set interface "WAN1"
set local-gw 1.1.1.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 2.2.2.1
set psksecret ***
next
edit "BRN-Ph1-2"
set interface "WAN2"
set local-gw 3.3.3.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 4.4.4.1
set psksecret ***
next
end

config vpn ipsec phase2-interface
edit "BRN-Ph2-1"
set phase1name "BRN-Ph1-1"
set proposal aes256-sha256
set dhgrp 2
next
edit "BRN-Ph2-2"
set phase1name "BRN-Ph1-2"
set proposal aes256-sha256
set dhgrp 2
next
end

config router static
edit 1
set gateway 1.1.1.2
set device "WAN1"
next
edit 3
set gateway 3.3.3.2
set device "WAN2"
next
end

config router bgp
set as 65002
set router-id 10.1.7.1
set ebgp-multipath enable
config neighbor
edit "192.168.254.2"
set remote-as 65003
next
edit "192.168.254.4"
set remote-as 65003
next
end

config network
edit 1
set prefix 10.1.0.0 255.255.0.0
next
end

config system interface
edit "WAN1"
set vdom "Internet"
set ip 2.2.2.1 255.255.255.252
set allowaccess ping
set role wan
set interface "BRN-BRD"
set vlanid 111
next
edit "WAN2"
set vdom "Internet"
set ip 4.4.4.1 255.255.255.252
set allowaccess ping
set role wan
set interface "BRN-BRD"
set vlanid 114
next
edit "DC-Ph1-1"
set vdom "Internet"
set ip 192.168.254.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.1 255.255.255.255
set interface "WAN1"
next
edit "DC-Ph1-2"
set vdom "Internet"
set ip 192.168.254.4 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.3 255.255.255.255
set interface "WAN2"
next
end

config vpn ipsec phase1-interface
edit "DC-Ph1-1"
set interface "WAN1"
set local-gw 2.2.2.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 1.1.1.1
set psksecret ***
next
edit "DC-Ph1-2"
set interface "WAN2"
set local-gw 4.4.4.1
set peertype any
set net-device disable
set proposal aes128-sha1
set dhgrp 2
set remote-gw 3.3.3.1
set psksecret ***
next
end

config vpn ipsec phase2-interface
edit "DC-Ph2-1"
set phase1name "DC-Ph1-1"
set proposal aes128-sha1
set dhgrp 2
next
edit "DC2-Ph2-2"
set phase1name "DC-Ph1-2"
set proposal aes128-sha1
set dhgrp 2
next
end

config router static
edit 1
set gateway 2.2.2.2
et device "WAN1"
next
edit 3
set gateway 4.4.4.2
set device "WAN2"
next
end

config router bgp
set as 65003
set router-id 10.200.7.1
set ebgp-multipath enable
config neighbor
edit "192.168.254.1"
set remote-as 65002
next
edit "192.168.254.3"
set remote-as 65002
next
end

config network
edit 1
set prefix 10.200.0.0 255.255.0.0
næste
end

Jeg præsenterer konfigurationen i tekstformat, fordi jeg mener, at det er lettere at konfigurere VPN på den måde. Næsten alle indstillinger er ens på begge sider, og i tekstformat kan de nemt kopieres og indsættes. Hvis man gør det samme i webgrænsefladen, er det nemt at lave en fejl - glemme at sætte et flueben eller indtaste en forkert værdi.

Når vi har tilføjet grænsefladerne til bundtet

kan alle ruter og sikkerhedspolitikker henvise til det i stedet for de grænseflader, der indgår i det. Mindst skal trafik fra interne netværk til SD-WAN tillades. Når der oprettes regler for dem, kan man anvende beskyttelsestiltag som IPS, antivirus og HTTPS-oplåsning.

SD-WAN-regler konfigureres for bundtet. Disse regler definerer balanceringsalgoritmen for specifik trafik. De ligner routingpolitikker i Policy-Based Routing, men i stedet for at resultere i next-hop eller en almindelig udgående grænseflade, er resultaterne de grænseflader, der er tilføjet til SD-WAN-bundtet plus balanceringsalgoritmen mellem disse grænseflader.

Trafik kan udskilles fra den generelle strøm baseret på L3-L4-information, genkendte applikationer, internettjenester (URL og IP), samt genkendte brugere af arbejdsstationer og bærbare computere. Derefter kan en af følgende balanceringsalgoritmer tildeles den udskilte trafik:

I Interface Preference-listen vælges de grænseflader, der allerede er tilføjet til bundtet, som skal håndtere denne type trafik. Ved ikke at tilføje alle grænseflader kan man begrænse, hvilke kanaler for eksempel e-mail bruger, hvis man ikke ønsker at belaste de dyre kanaler med høj SLA. I FortiOS 6.4.1 er det blevet muligt at gruppere de grænseflader, der er tilføjet til SD-WAN-bundtet, i zoner, hvilket giver mulighed for at oprette en zone til kommunikation med fjernlokationer og en anden til lokal internetadgang ved hjælp af NAT. Ja, trafikken, der går til det almindelige internet, kan også balanceres.

Om balanceringsalgoritmer

Når det kommer til, hvordan Fortigate (firewall fra Fortinet) kan opdele trafik mellem kanaler, er der to interessante muligheder, som ikke er meget udbredte på markedet:

Laveste omkostning (SLA) – blandt alle grænseflader, der opfylder SLA i øjeblikket, vælges den med den laveste vægt (cost), som er angivet af administratoren manuelt; denne tilstand er velegnet til "volumetrisk" trafik, såsom backup og filoverførsler.

Bedste Kvalitet (SLA) – denne algoritme kan, udover de sædvanlige forsinkelser, jitter og pakke tab, også bruge den nuværende belastning af kanalen til at vurdere kvaliteten; denne tilstand er velegnet til "følsom" trafik, såsom IP-telefoni (VoIP) og videokonferencer.

For disse algoritmer kræves der opsætning af ydeevnemåleren – Performance SLA. Denne måler kontrollerer periodisk (check interval) information om overholdelsen af SLA: tab (packet loss), forsinkelse (latency) og jitter i kommunikationskanalen, – og kan "forkaste" de kanaler, som i øjeblikket ikke opfylder tærskelværdierne for kvalitet – taber for mange pakker eller har for lange forsinkelser. Derudover overvåger måleren kanalens status og kan midlertidigt fjerne den fra bundtet i tilfælde af gentagne tab af svar (failures before inactive). Ved genopretning, efter flere på hinanden følgende svar (restore link after) vil måleren automatisk genføre kanalen i bundtet, og data kan igen begynde at blive overført.

Sådan ser opsætningen af "måleren" ud:

I webgrænsefladen er der tilgængelige protokoller til tests såsom ICMP-Echo-request, HTTP-GET og DNS-forespørgsel. I kommandolinjen er der lidt flere muligheder: TCP-echo og UDP-echo er tilgængelige, samt den specialiserede protokol til kvalitetsmåling – TWAMP.

Resultaterne af målingerne kan ses i webgrænsefladen:

Og i kommandolinjen:

Fejlfinding

Hvis der er oprettet en regel, men det ikke fungerer som forventet, er det værd at se på værdien Hit Count i listen over SD-WAN-regler. Det viser, om trafikken overhovedet rammer denne regel:

På siden for indstillingen af selve måleren kan ændringen af kanalens parametre over tid ses. Det tærskelværdi er angivet med stiplet linje.

I webgrænsefladen kan man se, hvordan trafikken fordeles efter volumen af overførte/modtagne data og antal sessioner:

Derudover er der en fremragende mulighed for at spore pakkers gennemstrømning med maksimal detaljeringsgrad. Når der arbejdes i et reelt netværk, ophobes et væld af routingpolitikker, firewallindstillinger og trafikfordeling over SD-WAN-porte i enhedens konfiguration. Alt dette interagerer komplekst, og selvom leverandøren præsenterer detaljerede flowcharts over pakkebehandlingsalgoritmer, er det meget vigtigt at have mulighed for ikke blot at bygge og teste teorier, men faktisk at se, hvor trafikken reelt går hen.

For eksempel kan det følgende sæt kommandoer

diagnose debug flow filter saddr 10.200.64.15 diagnose debug flow filter daddr 10.1.7.2 diagnose debug flow show function-name diagnose debug enable diagnose debug trace 2

Muliggøre sporing af to pakker med afsenders adresse 10.200.64.15 og modtagerens adresse 10.1.7.2.
Vi pinger 10.7.1.2 fra 10.200.64.15 to gange og ser på output i konsollen.

Første pakke:

Anden pakke:

Her er den første pakke modtaget af firewallen:
id=20085 trace_id=475 func=print_pkt_detail line=5605 msg="vd-Internet:0 modtager et paket(proto=1, 10.200.64.15:42->10.1.7.2:2048) fra DMZ-Office. type=8, kode=0, id=42, sekvens=0." VDOM – Internet, Proto=1 (ICMP), DMZ-Office – navnet på L3-interface. Type=8 – Echo.

For den blev der oprettet en ny session:
msg="allocate a new session-0006a627"

Og der blev opdaget et match i routingpolitikkerne
msg="Match policy routing id=2136539137: to 10.1.7.2 via ifindex-110"

Det viser sig, at pakken skal sendes til en af VPN-tunnelerne:
"find a route: flag=04000000 gw-192.168.254.1 via DC-Ph1-1"

I firewallpolitikkerne findes der en tilladende regel:
msg="Allowed by Policy-3:"

Pakken krypteres og sendes i VPN-tunnelen:
func=ipsecdev_hard_start_xmit line=789 msg="enter IPsec interface-DC-Ph1-1" func=_ipsecdev_hard_start_xmit line=666 msg="IPsec tunnel-DC-Ph1-1" func=esp_output4 line=905 msg="IPsec encrypt/auth"

Den krypterede pakke sendes til gateway-adressen for denne WAN-grænseflade:
msg="send to 2.2.2.2 via intf-WAN1"

For den anden pakke foregår alt på samme måde, men den sendes til en anden VPN-tunnel og forlader gennem en anden firewall-port:
func=ipsecdev_hard_start_xmit line=789 msg="gå ind i IPsec interface-DC-Ph1-2" func=_ipsecdev_hard_start_xmit line=666 msg="IPsec tunnel-DC-Ph1-2" func=esp_output4 line=905 msg="IPsec encrypt/auth" func=ipsec_output_finish line=622 msg="send til 4.4.4.2 via intf-WAN2"

Fordele ved løsningen

Pålidelig funktionalitet og brugervenligt interface. Funktionssættet, der eksisterede i FortiOS før SD-WANs ankomst, er bevaret fuldt ud. Det vil sige, at vi ikke har en nyudviklet software, men et modent system fra en velprøvet firewall-leverandør. Med et traditionelt sæt netværksfunktioner og et nemt og intuitivt webinterface. Hvor mange SD-WAN-leverandører har for eksempel Remote-Access VPN-funktionalitet på slutpunkterne?

Sikkerhed på niveau 80. FortiGate er blandt de bedste løsninger inden for firewalls. Der findes mange materialer online til opsætning og administration af firewalls, og på arbejdsmarkedet er der adskillige sikkerhedsspecialister, der allerede har mestret leverandørens løsninger.

Ingen omkostninger for SD-WAN-funktionalitet. At bygge et SD-WAN-netværk på FortiGate koster det samme som at bygge et almindeligt WAN-netværk, da der ikke er behov for yderligere licenser for at implementere SD-WAN-funktionalitet.

Lav adgangsbarriere i pris. Fortigate har en god gradation af enheder til forskellige præstationer. De mindste og billigste modeller kan sagtens bruges til at opsætte et kontor eller en salgsstation for eksempel til 3-5 medarbejdere. Mange leverandører har slet ikke sådanne lavt ydende og prisvenlige modeller.

Høj ydeevne. At reducere SD-WAN-funktionaliteten til trafikbalancering har gjort det muligt for virksomheden at udgive en specialiseret SD-WAN ASIC, som sikrer, at SD-WAN's funktionalitet ikke forringer performance af firewall'en generelt.

Mulighed for at implementere hele kontoret med Fortinet-udstyr. Dette inkluderer et par firewalls, switches og Wi-Fi adgangspunkter. Et sådant kontor er nemt og bekvemt at administrere – switches og adgangspunkter registreres på firewalls og administreres derfra. Her er et eksempel på, hvordan en switch-port kan se ud fra firewallen, der administrerer denne switch:

Fravær af controllere som et enkelt fejlfunktionspunkt. Dette er et fokuspunkt for leverandøren selv, men det kan kun delvist betragtes som en fordel, da de leverandører, der har controllere, ofte kan sikre deres fejlsikkerhed til en lav pris, oftest til omkostningerne ved et lille antal beregningsressourcer i en virtualiseringsmiljø.

Hvad man skal være opmærksom på

Fravær af adskillelse mellem Control Plane og Data Plane. Det betyder, at netværket skal konfigureres enten manuelt eller ved hjælp af de allerede eksisterende traditionelle styringsmidler — FortiManager. Hos leverandører, der har implementeret en sådan adskillelse, opstiller netværket sig selv. Administratoren kan kun være nødt til at justere dens topologi, forbyde noget et sted, ikke mere. Men forteen ved FortiManager er, at den kan administrere ikke kun firewalls, men også switches og Wi-Fi adgangspunkter, det vil sige næsten hele netværket.

Betinget vækst i styrbarhed. Da traditional værktøjer anvendes til automatisering af netværksopsætningen, er netværksadministrationen med implementeringen af SD-WAN kun marginalt forbedret. På den anden side bliver den nye funktionalitet tilgængelig hurtigere, da leverandøren først frigiver den til operativsystemet for firewalls (hvilket straks giver mulighed for at bruge dem) og derefter tilføjer de nødvendige grænseflader til administrationssystemet.

En del funktionalitet kan være tilgængelig fra kommandolinjen, men ikke fra webgrænsefladen. Det er ikke så skræmmende at gå ind i kommandolinjen for at konfigurere noget, som det er skræmmende ikke at kunne se i webgrænsefladen, at noget allerede er blevet konfigureret fra kommandolinjen. Men dette vedrører normalt kun de nyeste funktioner, og efterhånden som FortiOS opdateres, bliver webgrænsefladens muligheder forbedret.

Hvem det passer til

Til dem, der ikke har mange filialer. Implementeringen af SD-WAN-løsninger med komplekse centrale komponenter i netværk med 8-10 filialer kan være umagen værd – det vil kræve penge til licenser til SD-WAN-enheder og ressourcer til virtualiseringssystemet til placeringen af de centrale komponenter. Små virksomheder har normalt ikke mange ledige beregningsressourcer. I tilfælde af Fortinet er det tilstrækkeligt blot at købe firewalls.

Til dem, der har mange små filialer. For mange leverandører er prisen på løsningen per filial relativt høj, hvilket kan være uinteressant fra slutkundens forretningsperspektiv. Fortinet tilbyder små enheder til en meget konkurrencedygtig pris.

Til dem, der ikke er klar til at tage et stort skridt endnu. Implementeringen af SD-WAN med controllere, proprietær routing, og en ny tilgang til planlægning og netværksstyring kan være et for stort skridt for nogle kunder. Ja, en sådan implementering vil i sidste ende hjælpe med at optimere brugen af kommunikationskanaler og arbejdet for administratorer, men først skal man lære meget nyt. For dem, der ikke er klar til skiftet, men ønsker at maksimere udbyttet af deres kommunikationskanaler, er Fortinets løsning lige det, der passer.

Kilde: habr.com