Miksi BGP VPN:n yli ei hallitse alakerroksen polkua

Kaksi toimipistettä vertaistavat BGP:n IPsec-tunnelin yli, oppivat toistensa etuliitteet, ja kaavio nimetään uudelleen polun hallinnaksi. Juuri se nimike on hämmennysken alku. Istunto todella vaihtaa tavoitettavuutta ja soveltaa käytäntöä, mutta sillä ei ole sananvaltaa siihen, mikä operaattori, kaapeli tai reititin kuljettaa salatut paketit. Olen nähnyt tiimin rakentavan toimivan tunnelin uudelleen, koska he odottivat BGP-reittimuutoksen siirtävän liikenteen toiselle kuitupolulle, johon istunto ei olisi koskaan voinut vaikuttaa.

Mitä ihmiset olettavat istunnon ostavan

Suurin osa odotuksesta tulee siitä, miltä reittimuutos näyttää laboratoriossa. Mainostat etuliitteen tunnelin yli, vastapuoli asentaa sen, ja liikenne liikkuu. Sama jakso tapahtuu reitittimellä, jossa todella on liikenteen suunnittelun vipuja, joten kaksi asiaa sekoitetaan. Laboratoriossa molemmat toimipisteet jakavat yleensä yhden liityntälinkin, ja juuri siksi ero ei koskaan näy siellä.

BGP on tavoitettavuusprotokolla. Se kertoo vertaiselle, että voit toimittaa paketteja etuliitteelle, ja antaa kummankin puolen järjestää vastaanottamansa tarjoukset. Se on aidosti hyödyllistä tunnelin yli: etuliitteet ilmestyvät ja katoavat toimipisteiden tullessa ja mennessä, ja voit hylätä alueen kirjoittamatta staattista reittiä jokaiseen reunalaiteeseen. Mitä se ei tee, on operaattorin reitittimien saattaminen hallintaasi.

Alakerros kantaa ulomman otsikon. Tunnelisi päätepiste lähettää salatut paketit vertaisen osoitteeseen, ja näiden kahden osoitteen välinen verkko välittää ne reiteillä, jotka sen operaattorit ovat asentaneet. Mikään BGP-istunnossa ei muuta sitä päätöstä, ellei sama operaattori tarjoa tuettua palvelua, joka tekee niin.

Mitä istunto todella kantaa

BGP-puhuja avaa TCP-yhteyden vertaisensa porttiin 179 käyttäen viestimuotoja ja polun attribuutteja, jotka on määritelty RFC 4271-spesifikaatiossa. Kun vertaisen osoite on tunnelin sisällä, tunnelin on oltava ylhäällä ja osoitteen tavoitettavissa ennen kuin istunto voi edes alkaa. Valmis IKE-vaihto ei ole BGP-naapuri. Reittipohjaiset IPsec-toteutukset päästävät liikennettä läpi vasta, kun vastaava tunnelireitti on olemassa, ja käytäntöpohjainen tarvitsee vertaisen osoitteen suojatun valitsimen sisään. Tämän tekeminen väärinpäin tuottaa klassisen tilan, jossa tunneli on vihreä ja istunto istuu toimettomana.

Kun istunto on ylhäällä, käytäntö päättää, mikä sen ylittää. Etuliiteluettelot, AS-polun suodattimet, enimmäisetuliitteiden katto ja nimenomainen päätös oletusreiteistä ovat vähimmäisvaatimus, ja ne pätevät molempiin suuntiin. Vertainen, joka hyväksyy kaiken vastaanottamansa, voi antaa sinulle oletusreitin, joka hiljaa korvaa paikallisen internetyhteyden. Kaksi suuntaa tarvitsevat erilliset luettelot, koska se, mitä hyväksyt vertaiselta, ja se, mitä mainostat sille, ovat eri päätöksiä.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Seuraavaksi MTU puree. Kapselointi pienentää käytettävää hyötykuormaa, joten suuri päivitys voi pysäyttää istunnon, joka näyttää täysin vakiintuneelta: vertainen pysyy ylhäällä, etuliitteet eivät koskaan saavu, eikä lokiin tule mitään ilmeistä. Rajoita TCP MSS tunnelin rajapinnalla tai aseta tunnelin MTU, jossa on tilaa ylimääräiselle kuluille, ennen kuin syytät suodattimia.

Minne ulommat paketit yhä menevät

Salatut paketit toimipisteestä toiseen lähtevät sen kautta, minkä paikallinen reititin valitsee vertaisen julkiselle osoitteelle. Jos molemmat toimipisteet ostavat transit-liikennettä samalta operaattorilta, ylittävät saman metro-laitoksen tai toinen puoli istuu operaattoritason NAT:n takana, tunneli selviää operaattorin vikaantumisesta vain sattumalta. Tunnelikuvakkeiden laskeminen valvontatyökalussa ei kerro siitä sinulle mitään.

Reitin valinta ja välityksen asentaminen ovat myös erillisiä tapahtumia. Etuliite voi istua BGP-taulussa parhaana ja silti puuttua välitystaulusta, koska seuraava hyppy ei ole ratkaistavissa tai tarkempi reitti voittaa. Kun joku raportoi, että BGP oppi etuliitteen mutta liikenne ei virtaa, hyödyllinen kysymys on, onko se asennettu ja mihin seuraavaan hyppyyn se osoittaa.

Rehellinen vastaus suunnittelukatsaukseen on luettelo jaetuista riippuvuuksista: liityntäpiiri, ylävirran operaattori, laitos ja mikä tahansa tilallinen laite paluupolulla. Tunnelin yli kulkeva istunto ei voi poistaa riippuvuutta, jonka yläpuolella se ei ole.

Kolme päätöstä, jotka kannattaa erottaa

Kun suunnittelu sekoittaa nämä, jokainen katkoskeskustelu menee ympyrää. Erottele ne ensin paperilla ja kohdista sitten kukin laitteelle, joka todella panee sen täytäntöön.

Jokaisella rivillä on eri omistaja. Ensimmäinen on neuvottelu, toinen on konfiguraatio omissa laitteissasi, kolmas on enimmäkseen jonkun muun verkko. Muutospyyntö, joka nimeää koskemansa rivin, on paljon helpompi hyväksyä kuin sellainen, joka sanoo BGP-ongelma.

Vikatilat, joihin kannattaa varautua

Vertaisen koostereitin hyväksyminen on yleisin itse aiheutettu haava. Joku mainostaa lyhyen aggregaatin vaihdon yksinkertaistamiseksi, vastapuoli hyväksyy sen, ja liikenne alueille, jotka eivät ole tunnelin takana, seuraa tunnelia ja kuolee. Suodata täsmälleen odotetuilla etuliitteillä tai käytä oikein rajattua etuliiteluetteloa, äläkä koskaan hyväksy paljasta aggregaattia, koska se saa istunnon näyttämään siistiltä.

Peruutuksen ajoitus on toinen. Tunnistus riippuu pitoajastimista, BFD:stä jos olet ottanut sen käyttöön, tunnelin kuolleen vertaisen tunnistuksesta ja siitä, kuinka nopeasti vastapuoli lopettaa mainostamisen. Olemassa olevat istunnot ovat erillinen ongelma: uusi reitti voi palauttaa uudet yhteydet, kun taas vakiintuneet TCP-istunnot käyttävät edelleen vanhentuneita osoitteita, ja polulla olevat tilalliset palomuurit tai NAT voivat pitää merkintöjä, jotka eivät enää täsmää. Laita sovelluksen palautuminen hyväksymiskriteereihin sen sijaan, että olettaisit reittimuutoksen selvittävän kaiken.

Kolmas on paluupolun epäsymmetria. Liikenne voi saapua tunnelin yli ja palata operaattorin linkin kautta, jota ei koskaan ollut tarkoitettu sitä kantamaan, mikä näkyy yksisuuntaisena äänenä, epäonnistuneina kättelyinä tai palomuurina, joka pudottaa vastaukset. Tarkista molemmat suunnat erikseen.

Mitä sopimukseen kirjoitetaan ja miten se varmennetaan

Pyydä sallitut etuliitteet kirjallisesti: kuka on valtuutettu luomaan kunkin alueen, sallitaanko oletusreitti ja mitä osoiteperheitä tunnelipalvelu tukee. RFC 8212 teki nimenomaisesta tuonti- ja vientikäytännöstä eBGP:n odotuksen niissä toteutuksissa, jotka sitä noudattavat, joten vertainen, joka yhä nojaa implisiittiseen hyväksy-kaikki-käyttäytymiseen, kannattaa kyseenalaistaa.

Varmenna sitten laitteesta, ei kaaviosta. Hyödyllisiä komentoja FRR-tyylisillä reitittimillä:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Lisää kaksi havaintoa, joita reititystaulu ei voi antaa. Kaappaa ulommalla rajapinnalla vahvistaaksesi, mihin osoitteeseen kapseloidut paketit todella tähtäävät, esimerkiksi tcpdump -ni eth0 udp port 51820 WireGuard-tunnelille tai ESP-suodatin IPsecille. Jäljitä sitten kohti vertaisen julkista osoitetta ja vertaa hyppyjä tunnelin sisäiseen jäljitykseen; jos molemmat seuraavat samaa operaattoriketjua, redundanssisi elää reittikäytännössä eikä verkossa.

Testaa lopuksi peruutus tahallasi. Laske tunneli alas huoltoikkunan aikana, kirjaa, kuinka kauan etuliite pysyy asennettuna, mitä olemassa oleville istunnoille tapahtuu ja palaako vastapuoli reitille, jonka todella hyväksyisit. Se harjoitus kertoo suunnittelusta enemmän kuin mikään kaavio.

Reitti ei ole valtuutus. Etuliitteet, joista sovit vaihtavanne, eivät kerro mitään siitä, ketkä käyttäjät voivat saavuttaa minkä palvelun tunnelin takana, joten pidä todennus, sallitut palvelut ja isäntien palomuurit täsmälleen siellä, missä ne olivat. Tavoitettavissa oleva vertainen ei ole lupaa rajoittamattomaan transit-liikenteeseen tai mielivaltaisten osoitteiden luomiseen, ja sellainen valtuus kuuluu sopimukseen kaupallisena kysymyksenä, ei BGP-käytännön riville.

• Nimeä etuliitteet, joita kumpikin puoli saa luoda, ja ne, joita se ei saa koskaan hyväksyä.
• Rajoita MSS tunnelilla ja vahvista, että suuret päivitykset todella saapuvat.
• Luettele jaetut alakerroksen riippuvuudet, älä tunnelien määrää.
• Ajoita todellinen peruutus ja kirjaa, mitä sovellus tekee.