VPN gekoppel, maar een diens faal: isoleer die stadium

Gekoppel is die minste insiggewende feit in ’n VPN-tikket. Dit teken op dat twee eweknies ’n handshake voltooi het, en niks oor die naam wat nagevra is, die koppelvlak waardeur die pakket vertrek het, sy grootte, of die verre kant dit aanvaar het nie. Dis hoekom een diens kan faal terwyl elke ander toepassing op dieselfde skootrekenaar werk. Stap die stadiums in volgorde deur, en die eerste wat faal, benoem die fout.

Begin by die naam, nie die tonnel nie

Los eers op voordat jy roeteer, want ’n slegte antwoord maak elke latere toets betekenisloos. Vra die naam by die stelseloplosser en vergelyk daardie antwoord met die adres wat die toepassing werklik gebruik het. ’n Privaat naam wat as ’n openbare adres terugkom, beteken die navraag het na ’n oplosser gegaan wat geen besigheid het om dit te beantwoord nie. ’n Naam wat nie oplos nie, is dieselfde kategorie, net harder.

resolvectl query host.internal
getent hosts host.internal

Blaaiers met hul eie secure-DNS-instelling faal hier terwyl die res van die stelsel werk. Dis hoekom ’n klag wat net die blaaier raak, eerste by hierdie stadium hoort, voordat iemand aan ’n roete raak. Vergelyk albei opdragte eerder as een, want getent volg die NSS-pad en die oplosser-navraag nie.

Vra die kernel watter pad hy gekies het

Die roetetabel is ’n voorkeurorde, en die pad wat die kernel kies is nie altyd die een wat die diagram wys nie. Vra hom direk vir die bestemming ter sprake. Die antwoord noem die koppelvlak, die volgende hop en die bronadres wat gebruik sal word. ’n Pakket kan deur die tonnel vertrek met ’n bronadres wat die verre kant weier, en ’n meer spesifieke inskrywing in die fisiese tabel kan dit eerder deur die Wi-Fi-koppelvlak uitstuur.

ip route get 10.20.30.40
ip -brief address show

Lees die dev-, via- en src-velde in daardie volgorde, want elkeen skakel ’n ander vermoede uit. Hierdie stadium besit ook toestand wat die kliënt geïnstalleer het, want firewall-reëls en roetes kan ná ’n abnormale afsluiting bly staan. Dis hoekom geen internet sonder die tonnel en geen internet tensy die kliënt loop een familie fout is, nie twee nie.

Toets die pakketgrootte

’n Klein antwoord wat terugkom terwyl ’n groot oordrag vasdraai wys eerste na die pad-MTU. Een toets met die do-not-fragment-bis ingestel, van binne die tonnel gestuur, skei hierdie stadium van die res. Verhoog die payload totdat die toets faal, en jy het die nommer wat saak maak.

ping -M do -s 1400 10.20.30.40

Klein toetse wat slaag terwyl ’n gidslys of ’n oplaai hang, is die handtekening van hierdie stadium. Die klag klink na geloofsbriewe of ’n firewall-reël, en dit is nie een van die twee nie.

Die nommer is ’n eienskap van die pad eerder as van die kliënt, so ’n waarde wat op ’n kantoorverbinding werk, kan op ’n mobiele skakel faal. Hou die toetsopdrag by die tikket, want die volgende persoon het dieselfde meting nodig. As ’n kleiner payload deurkom, is die oplossing ’n clamp of ’n laer tonnel-MTU, nie ’n nuwe cipher nie.

Toets die verre kant

Toets die bestemming by sy adres en kyk dan wat daar luister. ’n Verbinding wat geweier word en ’n verbinding wat nooit antwoord nie, is verskillende bevindings. Die eerste sê iets is op en bedien nie daardie poort nie, en die tweede sê niks het teruggekom nie. Nie een is by verstek ’n kliëntprobleem nie.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Niks wat deur ’n tonnel bereikbaar is, kan ’n diens wees wat net op 127.0.0.1 luister nie, want die listener sien nooit die pakket nie. Wanneer die verre gasheer se firewall die kantoor-subnet toelaat en die tonnel-poel weier, lyk die resultaat soos ’n kliëntfout en is dit nie een nie. Remote Desktop of lêerdeling wat breek terwyl webverkeer oorleef, beland gewoonlik hier, hoe die gebruiker dit ook al verwoord.

Karteer die klag na een stadium

Die meeste verslae val in een van vyf vorms, en elke vorm noem ’n stadium. Een werf wat net deur die tonnel werk, is ’n naamantwoord of ’n beleid wat aan die bronadres gekoppel is. Opdaterings wat sonder die tonnel faal terwyl blaai werk, is ’n naam- of roeteprobleem vir daardie kliënt.

Alles wat stop wanneer ’n verskaffer-kliënt begin, is geïnstalleerde toestand, wat ’n roete- en firewall-vraag is. Een diens wat onbereikbaar is terwyl die res reg is, is die verre kant. Oordragte wat ’n paar sekondes in vasdraai, is pakketgrootte. Pas die vorm voor jy opdragte hardloop, want dit bepaal watter bewyse eerste ingesamel word.

Teken die stadium aan wat die eerste fout opgelewer het, saam met die opdraguitset. ’n Tikket wat sê die bronadres was verkeerd, met die roetelyn aangeheg, is werd om op te tree, terwyl een wat die VPN as stukkend rapporteer, dit nie is nie.