Tänk på en lokal lösning.
I en Cisco viptela sdwan lösning. Kan du ha olika WAN-underliggande länkar i olika VPN:er/vrfs?
Standard är VPN 0
Men för mig är det en säkerhetsrisk att ha en internetlänk och en MPLS-länk i samma vrf/VPN. Eftersom du nu delar ett företags routetabell och internet. Speciellt om inte alla MPLS-anslutna platser är klara med SD-WAN än.
Kan du ha internet i VPN 0 och MPLS i VPN 1 till exempel?
Och ha kontrollanslutningar till vbond över båda. Vad är bästa praxis här?
Det var bara en tanke just nu.
Tack.
Nej, tunnlar bildas endast över transport-VPN, VPN 0.
Du har ett djupare problem i ditt tänkande. MPLS bör inte litas på för att skicka rådata, den tiden är förbi.
I en modern SD-WAN lösning behöver du se MPLS som en annan transport för att bygga säkra tunnlar. Precis som inet eller LTE.
Ingen av dina privata routningar skulle skickas till din leverantör längre. Endast dina nätverk i VPN0 skulle skickas till din leverantörs PE. Det är allt de behöver för att bygga tunnlar.
Alla dina transporter är i 1 VRF, tjänstesidan (eller lokala nätverk) i en annan.
Dina underlag är opålitliga. Du krypterar dina overlay-nät mot dina huvudrouters oavsett vad din underlag är (privat eller offentligt). Så det finns ingen skillnad ur ett säkerhetsperspektiv?
Redigering: du routar INGET annat än hur du når dina huvudrouters i din underliggande routingtabell.
Jag och andra har pratat om varför detta inte behövs, men det är nog värt att nämna detta tydligt:
Du kan bokstavligen inte bygga tunnlar på annat VPN än 0. Så vilken rationell anledning du hittar för att kräva det är ganska irrelevant. Produkten fungerar inte så alls, någonsin.
Det är min åsikt att detta är acceptabelt av de skäl som nämns på annat håll, och troligen är gapet här en förståelse för hur VPN 0-konfigurationer fungerar i praktiken. Att övervinna insikten om att “VPN 0 inte faktiskt vidarebefordrar paket som traditionella routrar gör” var en viktig del av min egen bekantskap med produkten back in the day, så jag förstår det.
Du nämnde “skulle inte fungera i statliga organisationer”. Jag har faktiskt ingen aning om Cisco SDWAN används av några regeringar (USA eller annat), och jag skulle vara intresserad av att höra det om så är fallet. Men 100% om de använder det alls, då utgör de absolut tunnlar för både INET och MPLS i VPN 0 eftersom, återigen, det är det enda sättet att göra det.
Dataplanen är IPsec-krypterad med nycklar som potentiellt roteras så ofta som varje timme (ur minnet).
Kontrollplanet är TLS 1.2 (snart 1.3) krypterat. Om detta är ett bekymmer är det mesta av internet också det.
Sedan har du självklart applikationsnivåkryptering på mycket trafik nuförtiden också.
Som andra har sagt till dig, tillåter inte Cisco SDWAN-lösningen transit-routing när du har en offentlig och en privat länk som terminerar på samma enhet.
Om du inte litar på Cisco-programvaran, välj en annan leverantör du litar på. Eller kör tunnlar i GRE-läge och ha tredje part krypterare för all trafik från en leverantör du litar på.
Flera topologier är en funktion i Vipitel, men MPLS och internet är båda underliggande transport, jag ser inte behovet av att placera dem i olika VPN:er medan det finns andra mekanismer för att skilja trafiken i olika topologier.
Så vad sägs om den här uppsättningen?
SD-WAN, en E-Line tillbaka till datacentret och en rå internetlänk.
I datacentret finns BGP och statiska routningar som pekar på subnätet bakom SD-WAN-enheten.
Om E-line-länken gick ner och på grund av de konfigurerade statiska rutterna skulle internetlänken INTE bära trafik eftersom den statiska rutten slår all annan routing.
Rätt?
Faktiskt, även om jag kan ha fel, verkar det som att OP inte förstår skillnaden mellan overlay och underlay nätverk som gäller för SDWAN.
Jag tänker på en migrationsmetod. Inte många platser har möjligheten att börja från noll.
Okej. Så du skulle börja med ett nytt MPLS-nät och behandla det lika säkert som internet.
Migreringen skulle inkludera att byta till en ny MPLS-instans. I VPN 0.
Icke-migrerade platser skulle behöva stanna kvar på det äldre MPLS-nätet, som kan vara anslutet via en tjänst-VPN.
Det känns inte bra att ha offentliga och privata länkar i samma vrf.
Okej. Internet och MPLS i samma VPN. Inget som en brandvägg framför internet? Att sätta mycket tro på Cisco-programvaran…
Hur migrerar du? Separat MPLS-nät under migrationen?
Okej.. så det är standardpraxis att ha privat och offentlig trafik i samma VPN/vrf? Inte ens praxis, det finns inget annat val?
Det går emot alla äldre principer. Jag förstår att detta är en annan metod, men jag tycker det är hälsosamt att ifrågasätta och inte blint lita på de översta lagren.
Vad har folk gjort under migrationen? Ett opålitat MPLS-nät för SD-WAN-anslutna platser?
Jag vill ta itu med bekymret om att kasta övergripande rutter från dina legacy MPLS-platser till ditt globala tabell på dina SD-WAN-enheter.
En enkel lösning är att placera alla dina PE → CE-nätverk i ett supernet och använda en lokal routningspolicy för att filtrera ned till det inkommande på din cedge inom ditt PE → CE-routningsprotokoll. På så sätt, under din övergång, drar du inte privata rutrer in i transporttabellerna.
Japp. Du har fel.. Jag förstår skillnaden. Varför lägga tid på att kommentera om du inte ska tillföra något värde.
Om det bara är att ha dina privata och offentliga rutrer i samma tabell på en enhet är ett säkerhetsproblem för dig, borde du kanske tänka på hur varje icke-VRF medveten router fungerar.
För det första, även om de skulle dras in i dina transport-sidor-tabeller, filtrerar alla leverantörer RFC1918 så att det inte finns någon inåtkomst till dem, och eftersom det inte finns någon VPN 0 → VPN 0 hairpin NAT, kan du inte prata utåt heller.
Jag håller med om att de inte bör vara i samma tabell, men jag tror att jag behöver hjälp att förstå din logik bakom detta är en så stor sak. Vad tror du kommer hända? Det kan inte gå ut på grund av leverantörens bogon-filtrering och du kan inte routa till det via leverantörsutrustning.
För mig rankar MPLS-inställningen du beskrev högre än detta problem på min säkerhetslista. Det är bara min åsikt, inte att säga att din är ogiltig.
Det är en IPsec-tunnel? Om du inte har tillit till Cisco, kan du gärna lägga din egen kryptering ovanpå? lol
Enligt min uppfattning är det mer att skiftet mot WAN = opålitligt (oavsett medium). Detta kombinerat med i princip separata routingutrymmen/vrf/segment (beroende på leverantörens tillvägagångssätt) innebär att vi inte egentligen ändrar på traditionella konstruktioner för att uppnå ett resultat.
Okej.. ja.. men din MPLS-cloud har hela din routetabell. Som är direkt ansluten.
En ganska svag säkerhetsmekanism.
Allt i samma vrf som internet måste behandlas som opålitligt som internet.
Jag menade inte att förolämpa, ursäkta om jag gjorde det.
Det jag ville säga är att jag inte har mycket mer att tillägga till vad mreimert sa: MPLS, Internet, LTE… Det är allt bara rör du använder för att bygga dina tunnlar över. Underliggande nätverk kan per definition inte påverka överläggssäkerheten, inom rimlighetens gräns. Om du annonserar interna overlay-rutter till ditt underliggande nätverk vid något tillfälle, har du verkligen ett säkerhetsrisk.
Jag skulle faktiskt hävda att du har en ganska allvarlig designfel från början om detta scenariot inträffar 
Offentliga och privata nätverk har alltid varit isolerade och aldrig på samma enhet. Än mindre på samma enhet i samma routetabell.
Om du har fullständig no trust i WAN, ja, då är det inte ett problem. Det viktiga är… MPLS behandlas som osäkert som internet, i den här modellen. Har jag rätt i denna tanke..
Inte den delen.. kontrollanslutningar och omp etc. Och alla andra tjänster som väntar där är öppna för exploateringar..
Inget att skratta åt.