Å dømme etter antall spørsmål som begynte å komme til oss via SD-WAN, har teknologien begynt å slå rot i Russland. Leverandører sover naturligvis ikke og tilbyr konseptene sine, og noen modige pionerer implementerer dem allerede på nettverkene deres.
Vi samarbeider med nesten alle leverandører, og over flere år i laboratoriet vårt klarte jeg å fordype meg i arkitekturen til alle store utviklere av programvaredefinerte løsninger. SD-WAN fra Fortinet skiller seg litt ut her, som rett og slett bygde funksjonaliteten med å balansere trafikk mellom kommunikasjonskanaler inn i brannmurprogramvaren. Løsningen er ganske demokratisk, så den vurderes vanligvis av selskaper som ennå ikke er klare for globale endringer, men som ønsker å bruke kommunikasjonskanalene sine mer effektivt.
I denne artikkelen vil jeg fortelle deg hvordan du konfigurerer og jobber med SD-WAN fra Fortinet, hvem denne løsningen passer for og hvilke fallgruver du kan støte på her.
De mest fremtredende aktørene i SD-WAN-markedet kan klassifiseres i en av to typer:
1. Startups som har laget SD-WAN-løsninger fra bunnen av. De mest suksessrike av disse får en enorm drivkraft for utvikling etter å ha blitt kjøpt av store selskaper - dette er historien til Cisco/Viptela, VMWare/VeloCloud, Nuage/Nokia
2. Store nettverksleverandører som har laget SD-WAN-løsninger, utvikler programmerbarheten og administrerbarheten til sine tradisjonelle rutere – dette er historien til Juniper, Huawei
Fortinet klarte å finne veien. Brannmurprogramvaren hadde innebygd funksjonalitet som gjorde det mulig å kombinere grensesnittene deres til virtuelle kanaler og balansere belastningen mellom dem ved hjelp av komplekse algoritmer sammenlignet med konvensjonell ruting. Denne funksjonaliteten ble kalt SD-WAN. Kan det Fortinet kalles SD-WAN? Markedet forstår gradvis at Software-Defined betyr separasjon av kontrollplanet fra dataplanet, dedikerte kontroller og orkestratorer. Fortinet har ingenting slikt. Sentralisert administrasjon er valgfritt og tilbys gjennom det tradisjonelle Fortimanager-verktøyet. Men etter min mening bør du ikke se etter abstrakt sannhet og kaste bort tid på å krangle om vilkår. I den virkelige verden har hver tilnærming sine fordeler og ulemper. Den beste utveien er å forstå dem og kunne velge løsninger som samsvarer med oppgavene.
Jeg skal prøve å fortelle deg med skjermbilder i hånden hvordan SD-WAN fra Fortinet ser ut og hva det kan gjøre.
Hvordan alt fungerer
La oss anta at du har to grener forbundet med to datakanaler. Disse datakoblingene er kombinert til en gruppe, lik hvordan vanlige Ethernet-grensesnitt kombineres til en LACP-Port-Channel. Oldtimers vil huske PPP Multilink - også en passende analogi. Kanaler kan være fysiske porter, VLAN SVI, samt VPN- eller GRE-tunneler.
VPN eller GRE brukes vanligvis når du kobler til lokale filialnettverk over Internett. Og fysiske porter - hvis det er L2-forbindelser mellom nettsteder, eller ved tilkobling over en dedikert MPLS/VPN, hvis vi er fornøyd med forbindelsen uten Overlay og kryptering. Et annet scenario der fysiske porter brukes i en SD-WAN-gruppe er å balansere brukernes lokale tilgang til Internett.
På standen vår er det fire brannmurer og to VPN-tunneler som opererer gjennom to "kommunikasjonsoperatører". Diagrammet ser slik ut:
VPN-tunneler er konfigurert i grensesnittmodus slik at de ligner punkt-til-punkt-forbindelser mellom enheter med IP-adresser på P2P-grensesnitt, som kan pinges for å sikre at kommunikasjonen gjennom en bestemt tunnel fungerer. For at trafikken skal være kryptert og gå til motsatt side, er det nok å rute den inn i tunnelen. Alternativet er å velge trafikk for kryptering ved hjelp av lister over undernett, noe som forvirrer administratoren kraftig ettersom konfigurasjonen blir mer kompleks. I et stort nettverk kan du bruke ADVPN-teknologi til å bygge en VPN; dette er en analog av DMVPN fra Cisco eller DVPN fra Huawei, som muliggjør enklere oppsett.
Nettsted-til-side VPN-konfigurasjon for to enheter med BGP-ruting på begge sider
«ЦОД» (DC)
«Филиал» (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
next
end
Jeg gir konfigurasjonen i tekstform, fordi det etter min mening er mer praktisk å konfigurere VPN på denne måten. Nesten alle innstillingene er like på begge sider, i tekstform kan de gjøres som en copy-paste. Hvis du gjør det samme i nettgrensesnittet, er det lett å gjøre en feil - glem et merke et sted, skriv inn feil verdi.
Etter at vi la til grensesnittene til pakken
alle ruter og sikkerhetspolicyer kan referere til den, og ikke til grensesnittene som er inkludert i den. Som et minimum må du tillate trafikk fra interne nettverk til SD-WAN. Når du oppretter regler for dem, kan du bruke beskyttelsestiltak som IPS, antivirus og HTTPS-avsløring.
SD-WAN-regler er konfigurert for pakken. Dette er regler som definerer balansealgoritmen for spesifikk trafikk. De ligner på rutingpolicyer i policybasert ruting, bare som et resultat av trafikk som faller inn under policyen, er det ikke neste-hoppet eller det vanlige utgående grensesnittet som er installert, men grensesnittene lagt til SD-WAN-pakken pluss en trafikkbalanseringsalgoritme mellom disse grensesnittene.
Trafikk kan skilles fra den generelle flyten av L3-L4-informasjon, av anerkjente applikasjoner, Internett-tjenester (URL og IP), samt av anerkjente brukere av arbeidsstasjoner og bærbare datamaskiner. Etter dette kan en av følgende balanseringsalgoritmer tilordnes den tildelte trafikken:
I grensesnittpreferanselisten velges de grensesnittene fra de som allerede er lagt til pakken som skal betjene denne typen trafikk. Ved å legge til ikke alle grensesnitt, kan du begrense nøyaktig hvilke kanaler du bruker, for eksempel e-post, hvis du ikke vil belaste dyre kanaler med en høy SLA med det. I FortiOS 6.4.1 ble det mulig å gruppere grensesnitt lagt til SD-WAN-pakken i soner, for eksempel opprette en sone for kommunikasjon med eksterne nettsteder, og en annen for lokal Internett-tilgang ved hjelp av NAT. Ja, ja, trafikk som går til det vanlige Internett kan også balanseres.
Om balansealgoritmer
Når det gjelder hvordan Fortigate (en brannmur fra Fortinet) kan dele trafikk mellom kanaler, er det to interessante alternativer som ikke er veldig vanlige på markedet:
Laveste kostnad (SLA) – fra alle grensesnittene som tilfredsstiller SLA for øyeblikket, velges den med lavere vekt (kostnad), manuelt angitt av administratoren; denne modusen er egnet for "bulk" trafikk som sikkerhetskopiering og filoverføringer.
Beste kvalitet (SLA) – denne algoritmen, i tillegg til den vanlige forsinkelsen, jitter og tap av Fortigate-pakker, kan også bruke gjeldende kanalbelastning for å vurdere kvaliteten på kanalene; Denne modusen er egnet for sensitiv trafikk som VoIP og videokonferanser.
Disse algoritmene krever å sette opp en kommunikasjonskanalytelsesmåler - Ytelse SLA. Denne måleren overvåker med jevne mellomrom (sjekkintervall) informasjon om overholdelse av SLA: pakketap, latens og jitter i kommunikasjonskanalen, og kan "avvise" de kanalene som for øyeblikket ikke oppfyller kvalitetsgrensene - de mister for mange pakker eller opplever for mange pakker. mye ventetid. I tillegg overvåker måleren statusen til kanalen, og kan midlertidig fjerne den fra pakken i tilfelle gjentatte tap av svar (feil før inaktiv). Når den gjenopprettes, etter flere påfølgende svar (gjenopprett lenke etter), vil måleren automatisk returnere kanalen til pakken, og data vil begynne å bli sendt gjennom den igjen.
Slik ser "meter"-innstillingen ut:
I webgrensesnittet er ICMP-Echo-request, HTTP-GET og DNS-forespørsel tilgjengelig som testprotokoller. Det er litt flere alternativer på kommandolinjen: TCP-ekko og UDP-ekko alternativer er tilgjengelige, samt en spesialisert kvalitetsmålingsprotokoll - TWAMP.
Måleresultatene kan også sees i webgrensesnittet:
Og på kommandolinjen:
Feilsøking
Hvis du opprettet en regel, men alt ikke fungerer som forventet, bør du se på Hit Count-verdien i listen over SD-WAN-regler. Den vil vise om trafikken i det hele tatt faller inn under denne regelen:
På innstillingssiden til selve måleren kan du se endringen i kanalparametere over tid. Den stiplede linjen indikerer terskelverdien til parameteren
I webgrensesnittet kan du se hvordan trafikken er fordelt etter mengden data som overføres/mottas og antall økter:
I tillegg til alt dette er det en utmerket mulighet til å spore passasjen av pakker med maksimal detalj. Når du arbeider i et ekte nettverk, akkumulerer enhetskonfigurasjonen mange rutingpolicyer, brannmurer og trafikkdistribusjon på tvers av SD-WAN-porter. Alt dette samhandler med hverandre på en kompleks måte, og selv om leverandøren gir detaljerte blokkdiagrammer over pakkebehandlingsalgoritmer, er det veldig viktig å ikke kunne bygge og teste teorier, men å se hvor trafikken faktisk går.
For eksempel følgende sett med 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
Lar deg spore to pakker med en kildeadresse på 10.200.64.15 og en destinasjonsadresse på 10.1.7.2.
Vi pinger 10.7.1.2 fra 10.200.64.15 to ganger og ser på utgangen på konsollen.
Første pakke:
Andre pakke:
Her er den første pakken som ble mottatt av brannmuren:
id=20085 trace_id=475 func=print_pkt_detail line=5605 msg="vd-Internet:0 received a packet(proto=1, 10.200.64.15:42->10.1.7.2:2048) from DMZ-Office. type=8, code=0, id=42, seq=0."
VDOM – Internet, Proto=1 (ICMP), DMZ-Office – название L3-интерфейса. Type=8 – Echo.
En ny økt er opprettet for ham:
msg="allocate a new session-0006a627"
Og et samsvar ble funnet i innstillingene for rutingpolicy
msg="Match policy routing id=2136539137: to 10.1.7.2 via ifindex-110"
Det viser seg at pakken må sendes til en av VPN-tunnelene:
"find a route: flag=04000000 gw-192.168.254.1 via DC-Ph1-1"
Følgende tillatelsesregel oppdages i brannmurpolicyer:
msg="Allowed by Policy-3:"
Pakken er kryptert og sendt til 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 krypterte pakken sendes til gateway-adressen for dette WAN-grensesnittet:
msg="send to 2.2.2.2 via intf-WAN1"
For den andre pakken skjer alt på samme måte, men den sendes til en annen VPN-tunnel og går gjennom en annen brannmurport:
func=ipsecdev_hard_start_xmit line=789 msg="enter 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 to 4.4.4.2 via intf-WAN2"
Fordeler med løsningen
Pålitelig funksjonalitet og brukervennlig grensesnitt. Funksjonssettet som var tilgjengelig i FortiOS før bruken av SD-WAN er fullstendig bevart. Det vil si at vi ikke har nyutviklet programvare, men et modent system fra en velprøvd brannmurleverandør. Med et tradisjonelt sett med nettverksfunksjoner, et praktisk og lettlært nettgrensesnitt. Hvor mange SD-WAN-leverandører har, for eksempel, fjerntilgang VPN-funksjonalitet på sluttenheter?
Sikkerhetsnivå 80. FortiGate er en av de beste brannmurløsningene. Det finnes mye stoff på Internett om oppsett og administrasjon av brannmurer, og på arbeidsmarkedet er det mange sikkerhetsspesialister som allerede har mestret leverandørens løsninger.
Nullpris for SD-WAN-funksjonalitet. Å bygge et SD-WAN-nettverk på FortiGate koster det samme som å bygge et vanlig WAN-nettverk på det, siden ingen ekstra lisenser er nødvendig for å implementere SD-WAN-funksjonalitet.
Lav inngangsbarrierepris. Fortigate har en god gradering av enheter for ulike ytelsesnivåer. De yngste og rimeligste modellene egner seg ganske godt til å utvide et kontor eller et salgssted med for eksempel 3-5 ansatte. Mange leverandører har rett og slett ikke slike lavytelses- og rimelige modeller.
Høy ytelse. Redusering av SD-WAN-funksjonalitet til trafikkbalansering tillot selskapet å frigjøre en spesialisert SD-WAN ASIC, takket være hvilken SD-WAN-drift ikke reduserer ytelsen til brannmuren som helhet.
Muligheten til å implementere et helt kontor på Fortinet-utstyr. Dette er et par brannmurer, brytere, Wi-Fi-tilgangspunkter. Et slikt kontor er enkelt og praktisk å administrere - brytere og tilgangspunkter registreres på brannmurer og administreres fra dem. Dette er for eksempel hvordan en svitsjport kan se ut fra brannmurgrensesnittet som styrer denne svitsjen:
Mangel på kontrollere som et enkelt feilpunkt. Leverandøren selv fokuserer på dette, men dette kan bare delvis kalles en fordel, fordi for de leverandørene som har kontrollere, er det rimelig å sikre feiltoleransen deres, oftest til prisen av en liten mengde dataressurser i et virtualiseringsmiljø.
Hva skal jeg se etter?
Ingen skille mellom kontrollplan og dataplan. Dette betyr at nettverket må konfigureres enten manuelt eller ved hjelp av de tradisjonelle administrasjonsverktøyene som allerede er tilgjengelige - FortiManager. For leverandører som har implementert en slik separasjon, settes nettverket sammen selv. Administratoren trenger kanskje bare å justere topologien, forby noe et sted, ikke noe mer. FortiManagers trumfkort er imidlertid at den kan administrere ikke bare brannmurer, men også brytere og Wi-Fi-tilgangspunkter, det vil si nesten hele nettverket.
Betinget økning i kontrollerbarhet. På grunn av det faktum at tradisjonelle verktøy brukes til å automatisere nettverkskonfigurasjon, øker nettverksadministrasjonen litt med introduksjonen av SD-WAN. På den annen side blir ny funksjonalitet raskere tilgjengelig, siden leverandøren først slipper den kun for brannmuroperativsystemet (som umiddelbart gjør det mulig å bruke det), og først deretter supplerer styringssystemet med de nødvendige grensesnittene.
Noe funksjonalitet kan være tilgjengelig fra kommandolinjen, men er ikke tilgjengelig fra nettgrensesnittet. Noen ganger er det ikke så skummelt å gå inn på kommandolinjen for å konfigurere noe, men det er skummelt å ikke se i nettgrensesnittet at noen allerede har konfigurert noe fra kommandolinjen. Men dette gjelder vanligvis de nyeste funksjonene og gradvis, med FortiOS-oppdateringer, forbedres funksjonene til webgrensesnittet.
Hvem vil passe
For de som ikke har mange grener. Implementering av en SD-WAN-løsning med komplekse sentrale komponenter på et nettverk med 8-10 filialer koster kanskje ikke lyset – du må bruke penger på lisenser for SD-WAN-enheter og virtualiseringssystemressurser for å være vert for de sentrale komponentene. Et lite selskap har vanligvis begrensede gratis dataressurser. Når det gjelder Fortinet er det nok å kjøpe brannmurer.
For de som har mange små grener. For mange leverandører er minimumsløsningsprisen per filial ganske høy og er kanskje ikke interessant sett fra sluttkundens virksomhet. Fortinet tilbyr små enheter til svært attraktive priser.
For de som ikke er klare til å gå for langt ennå. Implementering av SD-WAN med kontrollere, proprietær ruting og en ny tilnærming til nettverksplanlegging og -administrasjon kan være et for stort skritt for noen kunder. Ja, en slik implementering vil til syvende og sist bidra til å optimalisere bruken av kommunikasjonskanaler og arbeidet til administratorer, men først må du lære mye nytt. For de som ennå ikke er klare for et paradigmeskifte, men ønsker å skvise mer ut av kommunikasjonskanalene sine, er løsningen fra Fortinet helt riktig.
Kilde: www.habr.com