Waarom BGP oor ’n VPN nie jou onderlaagpad beheer nie
BGP oor ’n VPN ruil bereikbaarheid uit en pas roetebeleid toe, maar die onderlaag kies steeds die buitenste pad. Wat die sessie werklik beheer.
Twee terreine peer BGP oor ’n IPsec-tonnel, leer mekaar se prefikse, en die diagram word herbenoem as padbeheer. Daardie etiket is waar die verwarring begin. Die sessie ruil wel bereikbaarheid uit en pas wel beleid toe, maar dit het geen sê in watter verskaffer, kabel of roeteerder die geënkripteerde pakkette dra nie. Ek het ’n span ’n werkende tonnel sien herbou omdat hulle verwag het ’n BGP-roeteverandering sou verkeer na ’n ander veselpad skuif wat die sessie nooit kon beïnvloed nie.
Wat mense aanneem ’n sessie koop
Die meeste van die verwagting kom uit hoe ’n roeteverandering in ’n laboratorium lyk. Jy adverteer ’n prefiks oor die tonnel, die ander kant installeer dit, en verkeer beweeg. Dieselfde reeks gebeur op ’n roeteerder wat wel verkeersingenieurswese-knoppies het, so die twee word verwar. In die laboratorium deel albei terreine gewoonlik een toegangskakel, en dit is juis waarom die verskil nooit daar opduik nie.
BGP is ’n bereikbaarheidsprotokol. Dit sê vir ’n eweknie dat jy pakkette vir ’n prefiks kan aflewer en laat elke kant die aanbiedinge rangskik wat dit ontvang. Dit is werklik nuttig oor ’n tonnel: prefikse verskyn en verdwyn soos terreine kom en gaan, en jy kan ’n reeks weier sonder om ’n statiese roete op elke randtoestel te skryf. Wat dit nie doen nie, is om ’n verskaffer se roeteerders onder jou beheer te plaas.
Die onderlaag dra die buitenste kop. Jou tonnel-eindpunt stuur geënkripteerde pakkette na ’n eweknie-adres, en die netwerk tussen daardie twee adresse stuur dit aan met watter roetes sy operateurs ook al geïnstalleer het. Niks in die BGP-sessie verander daardie besluit nie, tensy dieselfde verskaffer ’n ondersteunde diens blootstel wat dit doen.
Wat die sessie werklik dra
Die BGP-spreker maak ’n TCP-verbinding na poort 179 op sy eweknie oop, met die boodskapformate en padkenmerke wat in RFC 4271 gedefinieer word. Wanneer die eweknie-adres binne die tonnel lê, moet die tonnel op wees en daardie adres bereikbaar wees voordat die sessie selfs kan begin. ’n Voltooide IKE-uitruiling is nie ’n BGP-buur nie. Roetegebaseerde IPsec-implementasies laat verkeer eers deur sodra ’n passende tonnelroete bestaan, en ’n beleidgebaseerde een het die eweknie-adres binne die beskermde keurder nodig. Om dit omgekeerd te kry, lewer die klassieke toestand waar die tonnel groen is en die sessie ledig sit.
Sodra die sessie op is, besluit beleid wat dit kruis. Prefikslêers, AS-padfilters, ’n maksimum-prefiksplafon en ’n eksplisiete besluit oor verstekroetes is die minimum, en hulle geld in beide rigtings. ’n Eweknie wat alles aanvaar wat dit ontvang, kan jou ’n verstekroete gee wat plaaslike internettoegang stilweg vervang. Die twee rigtings het aparte lêers nodig, want wat jy van ’n eweknie aanvaar en wat jy aan dit adverteer, is verskillende besluite.
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
MTU byt volgende. Die enkapsulering verklein die bruikbare loonvrag, so ’n groot opdatering kan ’n sessie laat stol wat heeltemal gevestig lyk: die eweknie bly op, prefikse kom nooit aan nie, en niks ooglopends beland in die log nie. Knyp die TCP-MSS op die tonnelkoppelvlak vas, of stel ’n tonnel-MTU met ruimte vir die oorhoofse koste, voordat jy die filters blameer.
Waar die buitenste pakkette steeds heen gaan
Geënkripteerde pakkette van een terrein na die ander vertrek deur wat die plaaslike roeteerder ook al vir die eweknie se publieke adres kies. As albei terreine deurvoer by dieselfde verskaffer koop, dieselfde metro-fasiliteit kruis, of een kant agter carrier-grade NAT sit, oorleef die tonnel ’n verskafferfout net per ongeluk. Om tonnelikone in ’n moniteringshulpmiddel te tel, sê niks daaroor nie.
Roetekeuse en die installering van aansturing is ook aparte gebeurtenisse. ’n Prefiks kan as die beste in die BGP-tabel sit en steeds uit die aansturingstabel ontbreek, omdat die volgende sprong onoplaasbaar is of ’n meer spesifieke roete wen. Wanneer iemand rapporteer dat BGP die prefiks geleer het maar verkeer nie vloei nie, is die nuttige vraag of dit geïnstalleer is en na watter volgende sprong dit wys.
Die eerlike antwoord vir ’n ontwerphersiening is ’n lys gedeelde afhanklikhede: toegangskring, opstroomverskaffer, fasiliteit en enige toestandhoudende toestel in die terugpad. ’n Sessie oor die tonnel kan nie ’n afhanklikheid verwyder waaronder dit nie sit nie.
Drie besluite wat die moeite werd is om te skei
Wanneer ’n ontwerp hierdie dinge deurmekaar meng, gaan elke onderbrekingsgesprek in sirkels. Hou hulle eers op papier apart en karteer dan elkeen na die toestel wat dit werklik afdwing.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
Elke ry het ’n ander eienaar. Die eerste is ’n onderhandeling, die tweede is konfigurasie op jou toestelle, die derde is meestal iemand anders se netwerk. ’n Veranderingsversoek wat die ry noem wat dit raak, is baie makliker om goed te keur as een wat sê BGP-probleem.
Foutmodusse wat die moeite werd is om voor te beplan
Om ’n eweknie se opsommingsroete te aanvaar, is die algemeenste selfopgelegde wond. Iemand adverteer ’n kort samevoeging om die uitruiling te vereenvoudig, die ander kant aanvaar dit, en verkeer vir reekse wat nie agter die tonnel is nie, volg die tonnel en sterf. Filtreer op presiese verwagte prefikse, of gebruik ’n prefikslêer met die regte grense, en aanvaar nooit ’n kaal samevoeging omdat dit die sessie netjies laat lyk nie.
Onttrekkingstydsberekening is die tweede. Opsporing hang af van hou-tydhouers, BFD as jy dit geaktiveer het, tonnel-dooie-eweknie-opsporing en hoe vinnig die ander kant ophou adverteer. Bestaande sessies is ’n aparte probleem: ’n nuwe roete kan nuwe verbindings herstel terwyl gevestigde TCP-sessies aanhou om verouderde adresse te gebruik, en toestandhoudende firewalls of NAT op die pad kan inskrywings hou wat nie meer pas nie. Sit toepassingsherstel in die aanvaardingskriteria eerder as om te aanvaar ’n roeteverandering besleg alles.
Die derde is terugpad-asimmetrie. Verkeer kan oor die tonnel aankom en terugkeer oor ’n verskafferskakel wat nooit bedoel was om dit te dra nie, wat wys as eenrigting-klank, mislukte handdrukke of ’n firewall wat antwoorde laat val. Kontroleer albei rigtings apart.
Wat om in die kontrak te skryf, en hoe om dit te verifieer
Vra die toegelate prefikse skriftelik: wie is gemagtig om elke reeks te oorsprong, of ’n verstekroete toegelaat word, en watter adresfamilies die tonneldiens ondersteun. RFC 8212 het eksplisiete invoer- en uitvoerbeleid die verwagting vir eBGP gemaak in implementasies wat dit volg, so ’n eweknie wat steeds op implisiete aanvaar-enigiets-gedrag staatmaak, is die moeite werd om te bevraagteken.
Verifieer dan vanaf die toestel eerder as die diagram. Nuttige opdragte op FRR-agtige roeteerders:
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
Voeg twee waarnemings by wat die roetebeheertabel jou nie kan gee nie. Vang op die buitenste koppelvlak vas om te bevestig watter adres die geënkapsuleerde pakkette werklik teiken, byvoorbeeld tcpdump -ni eth0 udp port 51820 vir ’n WireGuard-tonnel, of ’n ESP-filter vir IPsec. Volg dan na die eweknie se publieke adres en vergelyk die spronge met ’n naspoor binne die tonnel; as albei dieselfde verskaffersketting volg, woon jou oortolligheid in roetebeleid eerder as in die netwerk.
Toets laastens ’n onttrekking doelbewus. Bring die tonnel af tydens ’n onderhoudsvenster, teken op hoe lank die prefiks geïnstalleer bly, wat met bestaande sessies gebeur, en of die ander kant terugval op ’n roete wat jy werklik sou aanvaar. Daardie oefening sê meer oor die ontwerp as enige diagram.
’n Roete is nie magtiging nie. Die prefikse wat jy ooreenkom om uit te ruil, sê niks oor watter gebruikers watter diens agter die tonnel mag bereik nie, so hou stawing, toegelate dienste en gasheer-firewalls presies waar hulle was. ’n Bereikbare eweknie is ook nie toestemming vir onbeperkte deurvoer of vir die oorsprong van willekeurige adresse nie, en daardie soort gesag hoort in die kontrak as ’n kommersiële vraag, nie in ’n BGP-beleidsreël nie.
- Noem die prefikse wat elke kant mag oorsprong, en die wat dit nooit mag aanvaar nie.
- Knyp MSS op die tonnel vas en bevestig dat groot opdaterings werklik aankom.
- Lys die gedeelde onderlaag-afhanklikhede, nie die tonneltelling nie.
- Tyd ’n werklike onttrekking en let op wat die toepassing doen.