VPN maak verbinding, maar LAN-toestelle bly onbereikbaar: wat om na te gaan

Verkeer betree die tonnel, die toegangspoort antwoord op sy eie adres, en niks agter hom reageer nie. Daardie patroon is algemeen en dit is nie ’n teenstrydigheid nie: ’n antwoord van die toegangspoort bewys dat die tonnel beëindig is, en dit bewys niks oor wat gebeur met ’n pakket wat anderkant hom geadresseer is nie. Die twee toetse oefen verskillende kodebane op dieselfde masjien.

Toets voortaan iets aan die ander kant van die toegangspoort. Die toegangspoort se eie adres sal bly antwoord, maak nie saak hoe stukkend die aanstuur is nie.

Die toegangspoort antwoord uit sy eie stapel

’n Pakket wat aan die toegangspoort geadresseer is, word na sy plaaslike insetpad afgelewer, waar die kern besluit of ’n luisterende sok dit aanvaar. ’n Pakket wat aan ’n gasheer agter die toegangspoort geadresseer is, word eerder na die aanstuurpad afgelewer, waar ’n ander stel kontroles geld. Aanstuur kan heeltemal gedeaktiveer wees, of deur die kern geaktiveer en dan deur ’n filterreël verwerp word wat nooit die tonnel noem nie. Niks daarvan raak die toegangspoort se eie antwoord nie, en daarom mislei die simptoom so betroubaar.

Administrasiebladsye wat deur die tonnel bereik word, hoort ook by die eerste kategorie. Hulle is getuienis oor die tonnel, nie oor die netwerk agter hom nie.

Volg die vloei tot by die eerste grens wat dit laat val

Begin by die kliënt en bevestig die roete en die bronadres wat die vloei sal gebruik. Kyk dan by die toegangspoort na daardie presiese vloei wat aankom, en weer na dieselfde vloei wat na die LAN vertrek. As dit nooit aankom nie, is die kliëntkant of die tonnel se toegelate voorvoegsels die probleem. As dit aankom en nooit vertrek nie, is aanstuur of ’n voortpadfilter die probleem, en die opname het reeds gesê watter een.

As jy dieselfde toets vanaf die toegangspoort doen, verberg jy die interessante helfte, want ’n pakket wat by die toegangspoort ontstaan het, het ’n ander bron en ’n ander terugkeervereiste. Gebruik die kliënt se vloei, met sy eie bronadres, vir elke stap. ’n Opname op die verkeerde koppelvlak lewer selfversekerde nonsens.

Terugroetes en gasheerfirewalls faal afsonderlik

Sodra die pakket die gasheer bereik, moet nog drie dinge geld. Die diens moet luister op die adres waarnatoe die pakket gestuur is, die gasheer se firewall moet dit aanvaar, en die antwoord moet ’n roete terug na die kliëntpoel hê. Daardie laaste een faal dikwels, want die gasheer se verstekroete wys na ’n roeteerder wat nog nooit van die tonnelreeks gehoor het nie. Die gevolg is ’n verbinding wat uit die gasheer se oogpunt tot stand kom en in die ander rigting stil sterf.

Toets die terugpad doelbewus deur van die kliënt te stuur en op die terugkeer te let. ’n Eenrigtingopname besleg in sekondes wat ’n uur se spekulasie nie sal doen nie.

Bevestig elke hop met die kliënt se bron

Voer die kontroles in volgorde uit en hou elke uitset, want die waarde lê in die vergelyking, nie in enige enkele reël nie. Die opdragte hieronder spel die bronadres vas, wys die gekose roete en neem beide kante van die aanstuur op. Vervang jou eie LAN-gasheer en tonnelkoppelvlak.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Die roetevraag wys of die kliënt daardie pakket hoegenaamd in die tonnel sou stuur, en die ping wys of iets van die gasheer teruggekom het. Om die twee opnames te vergelyk, skei aankoms van uitgang, want ’n raam op die tonnelkoppelvlak sonder ’n eweknie op die LAN-koppelvlak is ’n besluit oor aansturing eerder as ’n diensfout. Wanneer beide opnames die versoek wys en net een die antwoord wys, is die terugroete die oorblywende verdagte.

Teken aan watter adres geantwoord het en watter aangestuurde bestemming gefaal het. Daardie sin maak die verslag bruikbaar eerder as ’n bewering dat die bediener onbereikbaar is.