VPN kobler til, men LAN-enheter nås ikke: hva du bør sjekke

Trafikk går inn i tunnelen, gatewayen svarer på sin egen adresse, og ingenting bak den svarer. Det mønsteret er vanlig og ikke en selvmotsigelse: et svar fra gatewayen beviser at tunnelen ble avsluttet, og det beviser ingenting om hva som skjer med en pakke som er adressert forbi den. De to testene bruker ulike kodeveier på samme maskin.

Test noe på den andre siden av gatewayen fra nå av. Gatewayens egen adresse vil fortsette å svare, uansett hvor ødelagt videresendingen er.

Gatewayen svarer fra sin egen stakk

En pakke som er adressert til gatewayen, leveres til dens lokale inngangsvei, der kjernen avgjør om en lyttende socket godtar den. En pakke som er adressert til en vert bak gatewayen, leveres i stedet til videresendingsveien, der et annet sett kontroller gjelder. Videresending kan være helt deaktivert, eller den kan aktiveres av kjernen og deretter avvises av en filterregel som aldri nevner tunnelen. Ingenting av dette påvirker gatewayens eget svar, og derfor villeder symptomet så pålitelig.

Administrasjonssider som nås gjennom tunnelen, hører også til den første kategorien. De er bevis om tunnelen, ikke om nettverket bak den.

Følg flyten til den første grensen som slipper den

Start ved klienten og bekreft ruten og kildeadressen som flyten vil bruke. Se deretter på gatewayen etter at nettopp denne flyten ankommer, og igjen etter den samme flyten som forlater mot LAN. Hvis den aldri ankommer, er problemet på klientsiden eller i tunnelens tillatte prefikser. Hvis den ankommer og aldri forlater, er problemet videresending eller et filter på videresendingsveien, og opptaket har allerede sagt hvilket.

Å kjøre den samme testen fra gatewayen skjuler den interessante halvdelen, fordi en pakke som stammer fra gatewayen, har en annen kilde og et annet returkrav. Bruk klientens flyt, med dens egen kildeadresse, ved hvert trinn. Et opptak tatt på feil grensesnitt gir selvsikker tull.

Returruter og vertsbrannmurer svikter hver for seg

Når pakken når verten, må tre ting til holde. Tjenesten må lytte på adressen pakken ble sendt til, vertens brannmur må godta den, og svaret må ha en rute tilbake mot klientpoolen. Den siste svikter ofte, fordi vertens standardrute peker på en ruter som aldri har hørt om tunnelområdet. Resultatet er en forbindelse som opprettes fra vertens synspunkt og dør stille i den andre retningen.

Test returveien med vilje ved å sende fra klienten og følge med på returen. Et enveisopptak avgjør på sekunder det en times spekulasjon ikke vil avgjøre.

Bekreft hvert hopp med klientens kildeadresse

Kjør kontrollene i rekkefølge og ta vare på hver utdata, fordi verdien ligger i sammenligningen og ikke i en enkelt linje. Kommandoene nedenfor fester kildeadressen, viser den valgte ruten og tar opp begge sider av videresendingen. Erstatt din egen LAN-vert og tunnelgrensesnitt.

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

Ruteforespørselen viser om klienten i det hele tatt ville sende den pakken inn i tunnelen, og ping viser om noe kom tilbake fra verten. Å sammenligne de to opptakene skiller ankomst fra utgang, siden en ramme på tunnelgrensesnittet uten motstykke på LAN-grensesnittet er en videresendingsbeslutning og ikke en tjenestefeil. Når begge opptakene viser forespørselen og bare ett viser svaret, er returruten den gjenværende mistenkte.

Noter hvilken adresse som svarte, og hvilken videresendt destinasjon som sviktet. Den setningen gjør rapporten anvendelig i stedet for en påstand om at serveren er utilgjengelig.