🥇Analys av den mest demokratiska SD-WAN: arkitektur, konfiguration, administration och fallgropar

Utifrån antalet frågor som vi har fått om SD-WAN verkar teknologin verkligen ha börjat få fäste i Ryssland. Leverantörerna ligger naturligtvis inte på latsidan och erbjuder sina koncept, medan vissa djärva pionjärer redan implementerar dem i sina nätverk.

Vi arbetar med nästan alla leverantörer, och under flera år har jag haft möjlighet att granska arkitekturen hos varje stor utvecklare av programvarudefinierade lösningar i vårt laboratorium. En särskilt intressant aktör är SD-WAN från Fortinet, som har integrerat funktionalitet för trafikbalansering mellan kommunikationskanaler direkt i mjukvaran för brandväggar. Lösningen är ganska demokratisk, så den blir ofta intressant för företag som ännu inte är redo för stora förändringar, men vill använda sina kommunikationskanaler mer effektivt.

I denna artikel vill jag berätta om hur man konfigurerar och arbetar med SD-WAN från Fortinet, vem som kan dra nytta av denna lösning och vilka fallgropar man kan stöta på.

De mest framträdande aktörerna på SD-WAN-marknaden kan delas in i två typer:

1. Nyetablerade företag som har skapat SD-WAN-lösningar från grunden. De mest framgångsrika av dessa får ett stort utvecklingssprång när de köps upp av stora företag – det är historien om Cisco/Viptela, VMWare/VeloCloud, Nuage/Nokia.

2. Stora nätverksleverantörer som har utvecklat SD-WAN-lösningar genom att förbättra programmabiliteten och hanterbarheten hos sina traditionella routrar – det inkluderar företag som Juniper, Huawei.

Fortinet har lyckats hitta sin väg. I mjukvaran för brandväggar har funktionalitet lagts till som möjliggör sammanlänkning av deras gränssnitt i virtuella kanaler och belastningsbalansering mellan dem med hjälp av komplexa algoritmer jämfört med den traditionella rutingen. Denna funktionalitet fick namnet SD-WAN. Kan det som Fortinet har gjort kallas SD-WAN? På marknaden håller man gradvis på att förstå att Software-Defined betyder separation av Control Plane från Data Plane, dedikerade kontroller, orkestratorer. Hos Fortinet finns ingenting av det. Centraliserad hantering är valfri och erbjuds med hjälp av det traditionella verktyget Fortimanager. Men enligt min åsikt bör man inte leta efter en abstrakt sanning och slösa tid på att diskutera termer. I den verkliga världen har varje tillvägagångssätt sina fördelar och nackdelar. Den bästa lösningen är att förstå dem och kunna välja lösningar som passar behoven.

Jag kommer att försöka förklara med skärmdumpar i handen hur SD-WAN från Fortinet ser ut och vad det kan göra.

Så här är det uppbyggt

Anta att du har två filialer som är kopplade till varandra via två datakommunikationskanaler. Dessa datakanaler kombineras i en grupp, på samma sätt som vanliga Ethernet-gränssnitt kombineras i LACP-Port-Channel. Gamla rävar kommer att minnas PPP Multilink - en också passande analogi. Kanalerna kan vara fysiska portar, VLAN SVI samt VPN eller GRE-tunnlar.

VPN eller GRE används vanligtvis för att koppla samman lokala nätverk för filialer över internet. Fysiska portar används när det finns L2-anslutningar mellan platser, eller när man kopplar samman över dedikerad MPLS/VPN, om vi är nöjda med en anslutning utan Overlay och kryptering. En annan scenarion där fysiska portar används i SD-WAN-gruppen är lokal lastbalansering av användares utgång till internet.

I vår labb finns fyra brandväggar och två VPN-tunnlar som arbetar genom två "teleoperatörer". Diagrammet ser ut så här:

VPN-tunnlarna är inställda i gränssnittsläge, så att det liknar Point-to-Point-anslutningar mellan enheter med IP-adresser på P2P-gränssnitt som kan pingas för att se till att anslutningen genom den specifika tunneln fungerar. För att trafik ska krypteras och skickas till andra sidan, räcker det att dirigera den till tunneln. Alternativet är att selektera trafik för kryptering med hjälp av subnätlistor, vilket komplicerar livet för administratören ju mer konfigurationskraven ökar. I ett stort nätverk kan teknologin ADVPN användas för att bygga VPN, vilket är analogt med DMVPN från Cisco eller DVPN från Huawei, som förenklar inställningen.

Konfiguration Site-to-Site VPN för två enheter med BGP-routing på båda sidor

"DC" (Data Center)
"BRN" (Filial)

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

Jag ger konfigurationen i textformat, eftersom jag tycker att det är lättare att konfigurera VPN på det sättet. Nästan alla inställningar är desamma från båda sidor, vilket gör att de kan kopieras och klistras in i textformat. Om man gör samma sak i webbgränssnittet är det lätt att göra fel - glömma att kryssa i något, ange fel värde.

När vi har lagt till gränssnitten i bundlingen

kan alla rutter och säkerhetspolicyer hänvisa till den istället för till de ingående gränssnitten. Åtminstone måste vi tillåta trafik från interna nätverk till SD-WAN. När vi skapar regler för dem kan vi tillämpa skyddsåtgärder såsom IPS, antivirus och HTTPS-avslöjande.

För bundlingen konfigureras SD-WAN-regler. Dessa regler definierar balanceringsalgoritmen för specifik trafik. De liknar routingpolicyer i Policy-Based Routing, men istället för att en trafikpolicy ger next-hop eller vanlig utgående gränssnitt, anges de gränssnitt som lagts till i SD-WAN-bundlingen plus balanceringsalgoritmen mellan dessa gränssnitt.

Traffic can be distinguished from the overall flow based on L3-L4 information, recognized applications, internet services (URL and IP), as well as identified users of workstations and laptops. After this, one of the following load balancing algorithms can be assigned to the highlighted traffic:

In the Interface Preference list, the interfaces already added to the bundle that will handle this type of traffic are selected. By not adding all interfaces, you can limit the channels through which, say, email is sent, if you don't want to overload expensive channels with high SLA. In FortiOS 6.4.1, it became possible to group interfaces added to the SD-WAN bundle into zones, for example, creating one zone for communication with remote sites and another for local internet access using NAT. Yes, traffic going to the regular internet can also be balanced.

On Load Balancing Algorithms

Regarding how Fortigate (the firewall from Fortinet) can split traffic between channels, there are two interesting options that are not very common in the market:

Lowest Cost (SLA) – among all the interfaces that meet the SLA at the moment, the one with the lowest cost, specified by the administrator, is chosen; this mode is suitable for "volume" traffic, such as backups and file transfers.

Best Quality (SLA) – this algorithm, in addition to the usual delay, jitter, and packet loss, can also use the current channel load for evaluating channel quality; this mode is suitable for "sensitive" traffic, such as VoIP and video conferencing.

För dessa algoritmer krävs konfiguration av prestationsmätaren för kommunikationskanalen – Performance SLA. Denna mätare kontrollerar periodiskt (check interval) information om efterlevnaden av SLA: förluster (packet loss), latens (latency) och jitter (jitter) i kommunikationskanalen, och kan "avvisa" de kanaler som för närvarande inte uppfyller kvalitetsgränsvärdena – tappar för många paket eller har för hög latens. Dessutom övervakar mätaren statusen på kanalen och kan tillfälligt ta bort den från bundlen vid upprepade svarsförluster (failures before inactive). Vid återställning, efter flera på varandra följande mottagna svar (restore link after), kommer mätaren automatiskt att återföra kanalen till bundlen, och data kommer återigen att överföras genom den.

Så här ser konfigurationen av "mätaren" ut:

I webbgränssnittet finns ICMP-Echo-request, HTTP-GET och DNS-request tillgängliga som protokoll för tester. I kommandoraden finns det lite fler alternativ: TCP-echo och UDP-echo är tillgängliga, liksom det specialiserade kvalitetsmätningsprotokollet – TWAMP.

Resultaten från mätningarna kan ses både i webbgränssnittet:

Och i kommandoraden:

Felsökning

Om ett regel har skapats men det fungerar inte som förväntat, kan det vara värt att titta på värdet Hit Count i listan över SD-WAN-regler. Det visar om trafiken överhuvudtaget träffar denna regel:

På sidan för konfiguration av själva mätaren kan man se förändringen av kanalparametrarna över tid. Gränsvärdet för parametern är markerat med streckad linje.

I webbgränssnittet kan man se hur trafiken fördelas efter mängden överförda/mottagna data och antal sessioner:

Förutom allt detta finns det en utmärkt möjlighet att spåra paketen med maximal detaljrikedom. Vid arbete i ett verkligt nätverk samlas en mängd routningspolitiker, brandväggar och trafikfördelning efter SD-WAN-portar i enhetens konfiguration. Allt detta interagerar på komplicerade sätt med varandra, och även om leverantören presenterar detaljerade flödesscheman över pakethanteringsalgoritmer, är det mycket viktigt att ha möjlighet att inte bara bygga och testa teorier, utan också se vart trafiken verkligen går.

Till exempel kommer följande uppsättning kommandon

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

Att spåra två paket med källadressen 10.200.64.15 och destinationsadressen 10.1.7.2.
Pingar 10.7.1.2 från 10.200.64.15 två gånger och kolla på konsolutmatningen.

Första paketet:

Andra paketet:

Här har det första paketet tagits emot av brandväggen:
id=20085 trace_id=475 func=print_pkt_detail line=5605 msg="vd-Internet:0 mottog ett paket(proto=1, 10.200.64.15:42->10.1.7.2:2048) från DMZ-Office. typ=8, kod=0, id=42, sek=0." VDOM – Internet, Proto=1 (ICMP), DMZ-Office – namnet på L3-gränssnittet. Typ=8 – Echo.

En ny session har skapats för det:
msg="allocate a new session-0006a627"

Och en överensstämmelse i routingpolicyerna upptäcktes
msg="Match policy routing id=2136539137: to 10.1.7.2 via ifindex-110"

Det visar sig att paketet behöver skickas genom en av VPN-tunnlarna:
"find a route: flag=04000000 gw-192.168.254.1 via DC-Ph1-1"

I brandväggens policyer finns en godkännande regel:
msg="Allowed by Policy-3:"

Paketet krypteras och skickas i VPN-tunneln:
func=ipsecdev_hard_start_xmit line=789 msg="gå in i IPsec-gränssnitt-DC-Ph1-1" func=_ipsecdev_hard_start_xmit line=666 msg="IPsec-tunnel-DC-Ph1-1" func=esp_output4 line=905 msg="IPsec kryptera/autentisera"

Det krypterade paketet skickas till gateway-adressen för denna WAN-gränssnitt:
msg="send to 2.2.2.2 via intf-WAN1"

För det andra paketet sker allting på liknande sätt, men det skickas genom en annan VPN-tunnel och går ut genom en annan brandväggsport:
func=ipsecdev_hard_start_xmit line=789 msg="gå in i IPsec-gränssnittet-DC-Ph1-2" func=_ipsecdev_hard_start_xmit line=666 msg="IPsec tunnel-DC-Ph1-2" func=esp_output4 line=905 msg="IPsec kryptera/autentisera" func=ipsec_output_finish line=622 msg="skicka till 4.4.4.2 via intf-WAN2"

Fördelar med lösningen

Pålitlig funktionalitet och användarvänligt gränssnitt. Funktionerna som fanns i FortiOS innan SD-WAN kom, har bevarats fullt ut. Det innebär att vi har inte en nyutvecklad programvara, utan ett moget system från en pålitlig brandväggstillverkare. Med en traditionell uppsättning nätverksfunktioner och ett enkelt och lättanvänt webbgränssnitt. Hur många SD-WAN-tillverkare har till exempel funktionalitet för Remote-Access VPN på sina slutpunktsenheter?

Säkerhet på nivå 80. FortiGate är en av de bästa lösningarna för brandväggsskydd. Det finns många resurser på nätet för konfiguration och administration av brandväggar, och på arbetsmarknaden finns det många säkerhetsspecialister som redan har behärskat tillverkarens lösningar.

Ingen kostnad för SD-WAN-funktionalitet. Att bygga ett SD-WAN-nätverk på FortiGate kostar lika mycket som att bygga ett vanligt WAN-nätverk på det, eftersom inga ytterligare licenser krävs för att realisera SD-WAN-funktionaliteten.

Lågt inträdespris. FortiGate har en bra gradation av enheter för olika prestandanivåer. De lägsta och billigaste modellerna passar bra för att sätta upp ett kontor eller en försäljningspunkt, säg, för 3-5 anställda. Många tillverkare har helt enkelt inga sådana lågpresterande och prisvärda modeller.

High performance. Att reducera SD-WAN-funktionaliteten till trafikbalansering har gjort att företaget kunde släppa en specialiserad SD-WAN ASIC, vilket gör att SD-WAN:s arbete inte sänker brandväggens övergripande prestanda.

Möjlighet att helt implementera kontoret med Fortinet-utrustning. Det här är en uppsättning brandväggar, switchar och Wi-Fi-åtkomstpunkter. En sådan kontorslösning är enkel och bekväm att hantera – switcharna och åtkomstpunkterna registreras på brandväggarna och styrs från dem. Så här kan, till exempel, en switchport se ut från gränssnittet på brandväggen som styr den här switchen:

Avsaknad av kontroller som en enda felpunkt. Detta uppmärksammar själva leverantören, men detta kan endast delvis kallas en fördel, eftersom hos de leverantörer som har kontroller, är kostnaden för att säkerställa deras redundans låg, oftast i form av ett litet antal beräkningsresurser i en virtualiseringsmiljö.

Vad man bör uppmärksamma

Avsaknad av uppdelning mellan Control Plane och Data Plane. Det betyder att nätverket antingen måste konfigureras manuellt eller med hjälp av redan befintliga traditionella hanteringsverktyg – FortiManager. Hos leverantörer med sådan uppdelning konstrueras nätverket automatiskt. Administratören kan behöva justera dess topologi, förbjuda något här eller där, inte mer än så. Men fördelen med FortiManager är att den kan hantera inte bara brandväggar utan också switchar och Wi-Fi-åtkomstpunkter, vilket praktiskt taget omfattar hela nätverket.

Förutsatt ökat hanterbarhet. Eftersom traditionella verktyg används för att automatisera nätverkskonfigurationen, ökar nätverkets hanterbarhet marginellt med införandet av SD-WAN. Å andra sidan blir den nya funktionaliteten tillgänglig snabbare, eftersom leverantören först släpper den enbart för operativsystemet på brandväggarna (vilket omedelbart ger möjlighet att använda den), och först därefter kompletterar hanteringssystemet med nödvändiga gränssnitt.

En del funktionalitet kan vara tillgänglig från kommandoraden, men inte från webbgränssnittet. Det är inte så skrämmande att ibland gå in i kommandoraden för att konfigurera något, som att se i webbgränssnittet att något redan har konfigurerats av någon från kommandoraden. Men detta gäller vanligtvis de allra senaste funktionerna och gradvis, med uppdateringarna av FortiOS, kommer webbgränssnittets möjligheter att förbättras.

Vem det passar för

För dem med inte så många kontor. Implementering av SD-WAN-lösningar med komplexa centrala komponenter i nätverk med 8–10 filialer kanske inte är värt besväret – det krävs investeringar i licenser för SD-WAN-enheter och resurser för virtualisering av de centrala komponenterna. Vanligtvis har små företag knappa beräkningsresurser. I fallet med Fortinet räcker det att bara köpa brandväggar.

Till dem som har många små filialer. Hos många leverantörer är det minimala priset för lösningar per filial relativt högt och kan vara oattraktivt ur slutanvändarens perspektiv. Fortinet erbjuder små enheter till ett mycket attraktivt pris.

Till dem som inte är redo att ta ett för stort steg ännu. Implementering av SD-WAN med controllers, proprietär routing, en ny strategi för nätverksplanering och -hantering kan vara ett för stort steg för vissa kunder. Ja, en sådan implementation kommer slutligen att hjälpa till att optimera användningen av kommunikationskanaler och arbetet för administratörer, men först måste man lära sig mycket nytt. För dem som ännu inte är redo för ett paradigmskifte, men som vill få ut mer av sina kommunikationskanaler, passar Fortinets lösning perfekt.

Källa: habr.com