pull-filter jämför text, inte subnät: läs det som ett prefix
Filtret jämför början av varje pushad option med din text. Ett saknat mellanslag, en bred tidigare regel och fel åtgärd ger olika fel.
Avsikten var att släppa en pushad rutt. Efter ändringen saknas en annan routingoption, eller så återansluter klienten i en loop. Båda utfallen kommer av att filtret läses som en subnätregel medan det jämför text. Klienten kontrollerar om en pushad option börjar med de tecken du angav, och ingen adresslogik är inblandad i något steg.
Vad filtret faktiskt jämför
Varje pushad option kommer som en rad av ett namn och dess argument. Filtret jämför dina tecken med början av den raden, innan någon adress tolkas och innan någon rutt installeras. Därför fångar en regel skriven för ett namn varje option som börjar med de bokstäverna, inte bara den du tittade på. Det är därför ett filter kan se korrekt ut isolerat och ändå ta bort något orelaterat.
En sträng som ser ut som ett nätområde är fortfarande bara tecken. Den väljer inget prefix, gör ingen aritmetik på nätbits och kan inte uttrycka en uppsättning mål. När en sådan regel verkar fungera och sedan slutar, har den pushade texten vanligtvis ändrat form.
Ett mellanslag ändrar träffmängden
Samma optionsnamn med och utan avslutande avgränsare väljer olika rader. Utan avgränsaren förblir träffen öppen, med den måste optionsnamnet sluta exakt där innan argumenten börjar.
pull-filter ignore "route"
pull-filter ignore "route "Den öppna formen fångar också optioner som bara börjar med samma bokstäver, och så försvinner orelaterat routingbeteende tillsammans med rutten du ville släppa. Kopiera den pushade raden från loggen innan du skriver filtret. Behåll en oförändrad kopia av profilen bredvid den redigerade, eftersom en bred träff är lättare att ångra från en fil än från minnet.
Ordning och åtgärd ger olika symtom
Regler utvärderas i ordning och den första träffen avgör resultatet, så en bred regel placerad tidigt gör varje senare specifik regel onåbar. Åtgärden ändrar också felet: att ignorera en träff släpper optionen och sessionen fortsätter, medan avvisning reser ett fel som startar om anslutningen. En rad som pushas upprepade gånger tillsammans med avvisningsåtgärden ger därför en återanslutningscykel. Den cykeln är lätt att läsa som ett nätverksfel, och loggraden som namnger den matchade optionen är det som skiljer de två.
| Action | Effect on the session | How it gets reported |
|---|---|---|
| Ignore | Option dropped, session continues | Something is missing afterwards |
| Reject | Error raised, connection restarts | The VPN keeps dropping |
Anteckna vilken rad som matchade och vilken åtgärd som kördes. En släppt rutt och en omstartscykel kräver olika reparationer, och anteckningen bör säga vilken av dem som hände i stället för att lämna båda öppna.
Kontrollera vad värden installerade
Läs de tillämpade rutterna efter återanslutning och testa målet du ville behålla såväl som det du ville ta bort. Att släppa en pushad rutt ger ingen ersättning, så en resurs kan bli onåbar via en annan väg medan den oönskade rutten är borta. Om ett namn nu löses någon annanstans, kontrollera om den pushade resolveroptionen fångades av samma breda prefix. En ändring som klarar testet du körde och misslyckas med det du avsåg är det normala utfallet här.
Behåll den skillnaden i ärendet: rutten du tog bort, rutten du förväntade dig att behålla och vad tabellen visar nu. Nästa ändring kommer att bedömas mot den registreringen.
Behandla det inte som en förtroendegräns
Ett filter över text är en konfigurationsbekvämlighet, inte en kontroll mot en server du inte litar på. Bara formateringsvariationer besegrar det, och därför begränsar handboken det påståendet. När servern tillhör din organisation är det tydligare att rätta pushpolicyn än att samla lokala undantag.
Skriv ned varför det lokala filtret överhuvudtaget finns, så att nästa person kan avgöra om det fortfarande behövs. Filter hopar sig långt efter att skälet är borta.