VPN forbinder, men LAN-enheder kan ikke nås: hvad du skal kontrollere

Trafik går ind i tunnelen, gatewayen svarer på sin egen adresse, og intet bag den svarer. Det mønster er almindeligt og ikke en selvmodsigelse: et svar fra gatewayen beviser, at tunnelen blev afsluttet, og det beviser intet om, hvad der sker med en pakke, der er adresseret forbi den. De to tests bruger forskellige kodestier på samme maskine.

Test noget på den anden side af gatewayen fra nu af. Gatewayens egen adresse vil fortsat svare, uanset hvor brudt videresendelsen er.

Gatewayen svarer fra sin egen stak

En pakke, der er adresseret til gatewayen, leveres til dens lokale inputvej, hvor kernen afgør, om en lyttende socket accepterer den. En pakke, der er adresseret til en vært bag gatewayen, leveres i stedet til videresendelsesvejen, hvor et andet sæt kontroller gælder. Videresendelse kan være helt deaktiveret, eller den kan aktiveres af kernen og derefter afvises af en filterregel, der aldrig nævner tunnelen. Intet af det påvirker gatewayens eget svar, og derfor vildleder symptomet så pålideligt.

Administrationssider, der nås gennem tunnelen, hører også til den første kategori. De er bevis om tunnelen, ikke om netværket bag den.

Følg flowet til den første grænse, der dropper det

Start ved klienten, og bekræft den rute og kildeadresse, som flowet vil bruge. Overvåg derefter gatewayen for netop det flow, der ankommer, og igen for det samme flow, der forlader mod LAN. Hvis det aldrig ankommer, er problemet klientsiden eller tunnelens tilladte præfikser. Hvis det ankommer og aldrig forlader, er problemet videresendelse eller et filter på videresendelsesvejen, og optagelsen har allerede sagt hvilket.

At køre den samme test fra gatewayen skjuler den interessante halvdel, fordi en pakke, der stammer fra gatewayen, har en anden kilde og et andet returkrav. Brug klientens flow, med dens egen kildeadresse, ved hvert trin. En optagelse på den forkerte grænseflade giver selvsikker nonsens.

Returruter og vært-firewalls fejler hver for sig

Når pakken når værten, skal tre ting mere holde. Tjenesten skal lytte på den adresse, pakken blev sendt til, værtens firewall skal acceptere den, og svaret skal have en rute tilbage mod klientpuljen. Den sidste fejler ofte, fordi værtens standardrute peger på en router, der aldrig har hørt om tunnelens interval. Resultatet er en forbindelse, der oprettes fra værtens synspunkt og dør stille i den anden retning.

Test returvejen med vilje ved at sende fra klienten og holde øje med returen. En envejsoptagelse afgør på sekunder det, en times spekulation ikke vil afgøre.

Bekræft hvert hop med klientens kilde

Kør kontrollerne i rækkefølge, og gem hver uddata, fordi værdien ligger i sammenligningen og ikke i nogen enkelt linje. Kommandoerne nedenfor fastlåser kildeadressen, viser den valgte rute og optager begge sider af videresendelsen. Erstat din egen LAN-vært og tunnelgrænseflade.

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

Ruteordren viser, om klienten overhovedet ville sende den pakke ind i tunnelen, og ping viser, om noget kom tilbage fra værten. At sammenligne de to optagelser adskiller ankomst fra udgang, da en ramme på tunnelgrænsefladen uden modstykke på LAN-grænsefladen er en videresendelsesbeslutning og ikke en tjenestefejl. Når begge optagelser viser anmodningen, og kun én viser svaret, er returruten den resterende mistænkte.

Notér hvilken adresse der svarede, og hvilken videresendt destination der fejlede. Den sætning gør rapporten anvendelig i stedet for en påstand om, at serveren er utilgængelig.