Ping vanaf die IPsec-gateway gebruik ’n ander bronadres

Ping die ander kant vanaf die IPsec-gateway, kry geen antwoord nie en maak die gevolgtrekking dat die tonnel stukkend is, terwyl elke werklading agter die gateway normale verkeer deurstuur. Die twee resultate is nie teenstrydig nie. ’n Ping wat op die gateway begin, is ’n pakkie met ’n plaaslike bron, en die gateway kies ’n bronadres uit sy eie roetetabel. Daardie keuse kan verskil van die adresse wat werklike werfverkeer gebruik, en dit verander watter beleid pas en watter terugroete geld. Bepaal wat die toets moet bewys voordat jy enigiets uit die uitslag aflei.

Drie verskillende vrae wat ’n ping kan beantwoord

Die eerste vraag is of die ander kant hoegenaamd vanaf hierdie gasheer bereikbaar is. Die tweede is of die tonnel se selectors of die roetegebaseerde beleid verkeer van ’n bepaalde bron toelaat. Die derde is of deurgestuurde verkeer van ’n werklading agter die gateway van punt tot punt werk. Een opdrag kan nie al drie beantwoord nie, en dit is die bronadres wat hulle skei.

Kies eers die vraag. Anders word ’n mislukte ping bewys vir watter teorie jy ook al gehad het.

Waarom die gateway ’n adres kies wat jy nie verwag het nie

Wanneer jy ’n bestemming ping, kies die plaaslike stack ’n bron uit die roete wat daarby pas. Op ’n roetegebaseerde tonnel kan dit die skakeladres van die tonnelkoppelvlak wees, wat in baie werfontwerpe ’n 169.254.x.x-paar is wat vir die punt-tot-punt-hop gekies is. Daardie adresse bestaan om die skakel te laat werk; hulle word nie as toepassingsbron-netwerke aan die ander kant geadverteer nie.

Die ander kant kan dus ’n echo-versoek ontvang van ’n adres waarnatoe dit geen terugroete het nie, of een wat geen selector pas nie. Die tonnel kan gesond wees en die ping kan steeds misluk, en dit is presies die valse negatief waaroor hierdie artikel gaan.

Kies die bron doelbewus

Kies op ’n beheerde Linux-gateway ’n bron wat reeds plaaslik toegewys is: ping -c 4 -I 10.30.0.1 10.40.0.20. Die adresse hier is illustratief, so vervang die gateway se werklike binne-adres en ’n werklike afgeleë bestemming, en bevestig dat die bron wat jy kies aan hierdie toestel behoort en deur die werfbeleid toegelaat word.

Moenie ’n werklading se adres vir die toets leen nie. Om ’n gasheer na te boots wat nie aan die gateway toegewys is nie, skep ’n resultaat wat niemand kan herhaal nie, en op sommige stacks misluk dit op maniere wat soos ’n tonnelfout lyk.

Lees die antwoordpad, nie net die versoek nie

Kyk watter bron werklik by die afgeleë bestemming aankom, insluitend enige doelbewuste vertaling op pad. Kyk dan na die ander kant se roete terug na daardie bron en die selectors of beleid wat dit toelaat. ’n Versoek wat met ’n onverwagte bron aankom, is ’n roetering- en beleidsvraag, nie ’n kriptografiese een nie.

Dit is ook waar ’n opname meer help as nog ’n ping: dit wys die bron wat die ander kant gesien het, en dit is die adres wat sy antwoord moet bereik.

Toets dan die werklading

Die beslissende toets is ’n ping van ’n gewone gasheer agter die gateway na ’n gewone gasheer agter die afgeleë gateway. Dit oefen die gateway se deurstuurrol, die werklike toepassingsbron en die ware terugpad, en dit is die vloei waaroor gebruikers sorg.

Hou die resultate apart in jou notas: bereikbaarheid vanaf die gateway, beleidstoelating vir ’n gekose bron, en deurgestuurde verkeer. ’n Geslaagde vasgepen ping is nuttige bewyse dat die tonnel iets dra; dit is nie bewys dat elke deurgestuurde vloei werk nie. En ’n outomaties gekose gateway-bron wat nie bereik kan word nie, is nie bewys dat die werftonnel af is nie.

Moenie ’n oorkoepelende roete vir 169.254.0.0/16 byvoeg net om een diagnostiese antwoord te kry nie. Dit ruil ’n misleidende toets vir ’n permanente roeteringsbesluit, en die volgende persoon erf dit sonder die konteks.