Kies ’n stabiele registrasiebron vir GET VPN-lede

Iemand wys die groeplid se registrasie na ’n loopback-adres en verklaar die GET VPN-onstabiliteit opgelos. Soms is dit so. Dikwels is die loopback net uit die lid se eie roetegids bereikbaar en van nêrens anders nie, so registrasie breek steeds die volgende keer wanneer die uplink wat dit gedra het, wankel. Die registrasie-adres is ’n identiteit op die beheervlak, en dit help net wanneer daar ’n werklike pad in albei rigtings bestaan. Om dit doelbewus te kies is die moeite werd, en dit is ’n kleiner verandering as wat die volksoorlewering voorstel.

Wat die registrasie-adres identifiseer

In ’n GDOI-ontplooiing registreer die groeplid by die sleutelbediener en ontvang groepbeleid daarvan. Die adres wat die sleutelbediener aanteken, is die lid se identiteit vir daardie gesprek.

Daardie identiteit dek die beheergesprek: registrasie, hersluiteling en die aflaai van beleid. Dit word nie die bron van klanteverkeer nie, en dit verander nie watter koppelvlakke watter strome beskerm nie.

Om die twee apart te hou is die eerste stap, want die meeste verwarring rondom hierdie instelling kom daaruit dat daar van ’n verandering op die beheervlak verwag word om ’n simptoom op die datavlak reg te maak.

’n Loopback is net so goed soos sy roete

’n Loopback gee die lid ’n logiese adres wat nie verdwyn wanneer een fisiese uplink faal nie. Dit is ’n werklike voordeel op ’n router met verskeie paaie na die sleutelbediener.

Dit is ook net ’n adres. As die sleutelbediener geen roete terug daarheen het nie, misluk registrasie net soos voorheen. As die lid se roetegids die sleutelbediener slegs deur een uplink bereik, is die loopback stabiel en die pad nie.

Kontroleer bereikbaarheid in albei rigtings deur elke uplink wat jy wil laat oorleef. ’n Loopback wat administratief aan bly, bewys niks oor aanstuur nie, en die fout verskyn as ’n onbereikbare sleutelbediener eerder as ’n koppelvlakprobleem. Skryf die kontrole as ’n opdrag per uplink, nie as ’n aanname nie. Dan begin die volgende veranderingsvenster met bewyse eerder as met ’n diagram.

Hou beheerverkeer en beskermde verkeer apart

Cisco se GDOI-omseilingsgids dokumenteer die registrasie-koppelvlak en die verhouding tussen registrasie en die hantering van omseiling. Lees die gedrag vir die weergawe wat jy werklik gebruik eerder as om een frase as ’n universele opdrag te behandel.

Hersien filtering en vertaling op die beheerpad, en bevestig dat sleutelbestuurverkeer nie per ongeluk in ’n beskermingsbeleid ingesleep word wat afhang van juis die groepbeleid wat dit probeer aflaai nie. Daardie kringafhanklikheid is ’n klassieke manier om ’n werkende ontplooiing ná ’n beleidsverandering te laat misluk.

Datavlak-beleid is ’n aparte ontwerp. Om te verander waar registrasie vandaan kom, laat die beskermde strome, die selektore en die omseilreëls presies waar hulle was.

Kontroleer identiteit deur die oorgang

Voor die verandering, teken die groep, die gekose registrasie-adres, die sleutelbediener-bestemming, die roeteringskonteks en die toegelate beheerpad aan. Ná ’n goedgekeurde uplink-verandering, inspekteer die sleutelbediener se geregistreerde lid-aansig en die lid se beheertoestand weer.

Wat jy wil sien, is die beoogde logiese eindpunt wat steeds bereikbaar is en steeds voorgestel word soos jy dit ontwerp het. Wat jy nie wil hê nie, is ’n tweede registrasie vanaf ’n adres wat jy nie bedoel het nie; dit is juis hoe duplikaat lid-inskrywings ontstaan.

Toets dan beskermde toepassingsverkeer op sy eie. ’n Oordrag kan slaag terwyl die volgende hersluiteling nêrens het om heen te gaan nie, en ’n suksesvolle registrasie sê niks oor of ’n bepaalde stroom korrek gekies en gerouteer word nie.

Wat ’n stabiele bron nie regmaak nie

Dit verwyder nie duplikaat lid-inskrywings wat deur ’n vorige foutkonfigurasie geskep is nie. Dit herstel nie ’n hersluitelingsfout wat deur beleidsverskille tussen lid en sleutelbediener veroorsaak word nie. Dit oorleef nie ’n fisiese padfout wat die enigste roete na die sleutelbediener verwyder het nie.

Wat dit wel doen, is om een veranderlike te verwyder: die identiteit verander nie meer wanneer ’n uplink-adres verander nie. Dit is die moeite werd, en dit is een reël in ’n ontwerp eerder as die hele ontwerp.

Orde van werk: benoem die beheerpad, kies ’n adres met ’n roete in albei rigtings, bevestig die sleutelbediener se aansig, en toets dan beskermde verkeer apart. As registrasie steeds misluk, was die loopback nooit die probleem nie.