VPN koplar til, men LAN-einingar er ikkje tilgjengelege: kva du bør sjekke

Trafikk går inn i tunnelen, gatewayen svarar på si eiga adresse, og ingenting bak han svarar. Det mønsteret er vanleg og ikkje ei sjølvmotseiing: eit svar frå gatewayen provar at tunnelen vart avslutta, og det provar ingenting om kva som skjer med ein pakke som er adressert forbi han. Dei to testane nyttar ulike kodevegar på same maskin.

Test noko på den andre sida av gatewayen frå no av. Den eiga adressa til gatewayen vil halde fram med å svare, uansett kor øydelagd vidaresendinga er.

Gatewayen svarar frå sin eigen stakk

Ein pakke som er adressert til gatewayen, vert levert til den lokale inngangsvegen hans, der kjernen avgjer om ein lyttande socket godtek han. Ein pakke som er adressert til ein vert bak gatewayen, vert i staden levert til vidaresendingsvegen, der eit anna sett kontrollar gjeld. Vidaresending kan vere heilt deaktivert, eller han kan aktiverast av kjernen og deretter avvisast av ein filterregel som aldri nemner tunnelen. Ingenting av dette påverkar det eigne svaret til gatewayen, og difor villeder symptomet så påliteleg.

Administrasjonssider som ein når gjennom tunnelen, høyrer også til den fyrste kategorien. Dei er prov om tunnelen, ikkje om nettverket bak han.

Følg flyten til den fyrste grensa som slepp han

Start ved klienten og stadfest ruta og kjeldeadressa som flyten vil nytte. Sjå deretter på gatewayen etter at nettopp denne flyten kjem inn, og igjen etter den same flyten som går ut mot LAN. Viss han aldri kjem, er problemet på klientsida eller i dei tillatne prefiksa til tunnelen. Viss han kjem og aldri går ut, er problemet vidaresending eller eit filter på framovervegen, og opptaket har allereie sagt kva av dei.

Å køyre den same testen frå gatewayen skjuler den interessante halvdelen, fordi ein pakke som stammar frå gatewayen, har ei anna kjelde og eit anna returkrav. Bruk flyten til klienten, med si eiga kjeldeadresse, ved kvart steg. Eit opptak teke på feil grensesnitt gjev sjølvsikker tull.

Returruter og vertsbrannmurar sviktar kvar for seg

Når pakken når verten, må tre ting til halde. Tenesta må lytte på adressa pakken vart send til, brannmuren til verten må godta han, og svaret må ha ei rute tilbake mot klientpoolen. Den siste sviktar ofte, fordi standardruta til verten peikar på ein ruter som aldri har høyrt om tunnelområdet. Resultatet er ei tilkopling som vert oppretta frå synsvinkelen til verten og døyr stille i den andre retninga.

Test returvegen med vilje ved å sende frå klienten og følgje med på returen. Eit einvegssopptak avgjer på sekund det ein times spekulasjon ikkje vil avgjere.

Stadfest kvart hopp med kjeldeadressa til klienten

Køyr kontrollane i rekkefølgje og ta vare på kvar utdata, fordi verdien ligg i samanlikninga og ikkje i ei einskilde linje. Kommandoane nedanfor festar kjeldeadressa, viser den valde ruta og tek opp begge sider av vidaresendinga. Byt ut din eigen 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

Rutespurnaden viser om klienten i det heile ville sende den pakken inn i tunnelen, og ping viser om noko kom tilbake frå verten. Å samanlikne dei to opptaka skil ankomst frå utgang, sidan ei ramme på tunnelgrensesnittet utan motstykke på LAN-grensesnittet er ei vidaresendingsavgjerd og ikkje ein tenestefeil. Når begge opptaka viser førespurnaden og berre eitt viser svaret, er returruta den gjenverande mistenkte.

Noter kva adresse som svara, og kva vidaresend destinasjon som svikta. Den setninga gjer rapporten anvendeleg i staden for ei påstand om at tenaren er utilgjengeleg.