VPN ansluter men når inte LAN-enheter: vad du bör kontrollera

Trafik går in i tunneln, gatewayen svarar på sin egen adress och ingenting bakom den svarar. Det mönstret är vanligt och inte en självmotsägelse: ett svar från gatewayen bevisar att tunneln avslutades, och det bevisar ingenting om vad som händer med ett paket som adresserats förbi den. De två testerna använder olika kodvägar på samma maskin.

Testa något på andra sidan gatewayen från och med nu. Gatewayens egen adress fortsätter att svara, hur trasig vidarebefordran än är.

Gatewayen svarar från sin egen stack

Ett paket som adresserats till gatewayen levereras till dess lokala inmatningsväg, där kärnan avgör om en lyssnande socket accepterar det. Ett paket som adresserats till en värd bakom gatewayen levereras i stället till vidarebefordringsvägen, där en annan uppsättning kontroller gäller. Vidarebefordran kan vara helt avstängd, eller aktiveras av kärnan och sedan avvisas av en filterregel som aldrig nämner tunneln. Inget av detta påverkar gatewayens eget svar, och därför vilseleder symtomet så pålitligt.

Administrationssidor som nås genom tunneln tillhör också den första kategorin. De är bevis om tunneln, inte om nätverket bakom den.

Följ flödet till den första gränsen som släpper det

Börja vid klienten och bekräfta rutten och källadressen som flödet kommer att använda. Titta sedan på gatewayen efter att just det flödet anländer, och igen efter samma flöde när det lämnar mot LAN. Om det aldrig anländer ligger problemet på klientsidan eller i tunnelns tillåtna prefix. Om det anländer och aldrig lämnar ligger problemet i vidarebefordran eller i ett filter på vidarebefordringsvägen, och fångsten har redan sagt vilket.

Att köra samma test från gatewayen döljer den intressanta halvan, eftersom ett paket som kommer från gatewayen har en annan källa och ett annat returkrav. Använd klientens flöde, med dess egen källadress, vid varje steg. En fångst tagen på fel gränssnitt ger självsäkert nonsens.

Returrutter och värdbrandväggar fallerar var för sig

När paketet når värden måste tre saker till gälla. Tjänsten måste lyssna på adressen som paketet skickades till, värdens brandvägg måste acceptera det, och svaret måste ha en rutt tillbaka mot klientpoolen. Det sista fallerar ofta, eftersom värdens standardrutt pekar på en router som aldrig har hört talas om tunnelområdet. Resultatet är en anslutning som upprättas ur värdens perspektiv och dör tyst i den andra riktningen.

Testa returvägen med avsikt genom att skicka från klienten och bevaka returen. En enkelriktad fångst avgör på sekunder det som en timmes spekulation inte avgör.

Bekräfta varje hopp med klientens källadress

Kör kontrollerna i ordning och spara varje utdata, eftersom värdet ligger i jämförelsen och inte i en enda rad. Kommandona nedan låser källadressen, visar den valda rutten och fångar båda sidorna av vidarebefordran. Byt ut din egen LAN-värd och tunnelgränssnitt.

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

Ruttfrågan visar om klienten ens skulle skicka det paketet in i tunneln, och ping visar om något kom tillbaka från värden. Att jämföra de två fångsterna skiljer ankomst från utgång, eftersom en ram på tunnelgränssnittet utan motsvarighet på LAN-gränssnittet är ett vidarebefordringsbeslut och inte ett tjänstefel. När båda fångsterna visar begäran och bara en visar svaret är returrutten den kvarvarande misstänkta.

Notera vilken adress som svarade och vilken vidarebefordrad destination som misslyckades. Den meningen gör rapporten användbar i stället för ett påstående att servern är oåtkomlig.