VPN anslutet men en tjänst misslyckas: isolera steget

„Ansluten“ är det minst informativa faktumet i ett VPN-ärende. Det registrerar att två parter slutförde ett handshake och ingenting om namnet som slogs upp, gränssnittet paketet lämnade genom, dess storlek eller om den andra änden accepterade det. Därför kan en tjänst misslyckas medan alla andra program på samma bärbara dator fungerar. Gå igenom stegen i ordning och det första som misslyckas namnger felet.

Börja med namnet, inte tunneln

Slå upp innan du routar, eftersom ett dåligt svar gör varje senare test meningslöst. Fråga efter namnet hos systemets resolver och jämför svaret med den adress programmet faktiskt använde. Ett privat namn som kommer tillbaka som en offentlig adress betyder att frågan gick till en resolver som inte har något med saken att göra. Ett namn som inte går att slå upp är samma kategori, bara högre.

resolvectl query host.internal
getent hosts host.internal

Webbläsare med egen inställning för säker DNS misslyckas här medan resten av systemet fungerar. Därför hör ett klagomål som bara gäller webbläsaren först hemma i detta steg, innan någon rör en rutt. Jämför båda kommandona i stället för ett, eftersom getent följer NSS-vägen och resolverfrågan inte gör det.

Fråga kärnan vilken väg den valde

Routtabellen är en preferensordning, och vägen kärnan väljer är inte alltid den som diagrammet visar. Fråga den direkt om den aktuella destinationen. Svaret namnger gränssnittet, nästa hopp och källadressen som kommer att användas. Ett paket kan lämna tunneln med en källadress som den andra änden avvisar, och en mer specifik post i den fysiska tabellen kan skicka det genom Wi-Fi-gränssnittet i stället.

ip route get 10.20.30.40
ip -brief address show

Läs fälten dev, via och src i den ordningen, eftersom var och en utesluter en annan misstanke. Detta steg äger också det tillstånd klienten installerade, eftersom brandväggsregler och rutter kan finnas kvar efter en onormal avslutning. Därför är „inget internet utan tunneln“ och „inget internet om inte klienten kör“ en fel familj, inte två.

Testa paketstorleken

Ett litet svar som kommer tillbaka medan en stor överföring fastnar pekar först på banans MTU. En enda sond med do-not-fragment-biten satt, skickad inifrån tunneln, skiljer detta steg från resten. Höj nyttolasten tills sonden misslyckas och du har talet som betyder något.

ping -M do -s 1400 10.20.30.40

Små sonder som lyckas medan en mapplista eller en uppladdning hänger är signaturen för detta steg. Klagomålet låter som inloggningsuppgifter eller en brandväggsregel, och det är inget av dem.

Talet är en egenskap hos banan, inte hos klienten, så ett värde som fungerar på en kontorsanslutning kan misslyckas på en mobil länk. Behåll sondkommandot med ärendet, eftersom nästa person behöver samma mätning. Om en mindre nyttolast passerar är lösningen en clamp eller en lägre tunnel-MTU, inte ett nytt chiffer.

Testa den andra änden

Testa destinationen på dess adress och se sedan vad som lyssnar där. En avvisad anslutning och en anslutning som aldrig svarar är olika fynd. Den första säger att något kör och inte betjänar den porten, och den andra säger att ingenting kom tillbaka. Ingen av dem är ett klientproblem som standard.

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

Ingenting som nås genom en tunnel kan vara en tjänst som bara lyssnar på 127.0.0.1, eftersom lyssnaren aldrig ser paketet. När brandväggen på den fjärran värden tillåter kontorets subnät och avvisar tunnelpoolen ser resultatet ut som ett klientfel och är det inte. Fjärrskrivbord eller fildelning som går sönder medan webbtrafiken överlever hamnar vanligtvis här, hur användaren än formulerar det.

Koppla klagomålet till ett steg

De flesta rapporter faller i en av fem former, och varje form namnger ett steg. En webbplats som bara fungerar genom tunneln är ett namn svar eller en policy knuten till källadressen. Uppdateringar som misslyckas utan tunneln medan surfandet fungerar är ett namn- eller ruttproblem för den klienten.

Att allt stannar när en leverantörsklient startar är installerat tillstånd, alltså en rutt- och brandväggsfråga. En tjänst oåtkomlig medan resten är i ordning är den andra änden. Överföringar som fastnar efter några sekunder är paketstorleken. Matcha formen innan du kör kommandon, eftersom den avgör vilka bevis som samlas in först.

Anteckna steget som gav det första felet tillsammans med kommandots utdata. Ett ärende som säger att källadressen var fel, med ruttraden bifogad, är värt att agera på, medan ett som rapporterar att VPN:en är trasig inte är det.