VPN ühendub, kuid LAN-seadmed ei ole kättesaadavad: mida kontrollida

Liiklus siseneb tunnelisse, lüüs vastab omaenda aadressil ja miski selle taga ei vasta. See muster on tavaline ega ole vastuolu: lüüsist tulev vastus tõestab, et tunnel lõppes, ja ei tõesta midagi selle kohta, mis juhtub väljapoole seda adresseeritud paketiga. Kaks testi kasutavad samas masinas erinevaid kooditeid.

Edaspidi katsetage midagi lüüsi teisel poolel. Lüüsi oma aadress vastab jätkuvalt, ükskõik kui katki edastamine ka on.

Lüüs vastab omaenda virnast

Lüüsile adresseeritud pakett toimetatakse selle kohalikule sisendteele, kus tuum otsustab, kas kuulav pesa selle vastu võtab. Lüüsi taga olevale hostile adresseeritud pakett toimetatakse seevastu edastusteele, kus kehtib teistsugune kontrollide kogum. Edastamise saab täielikult välja lülitada või tuum selle sisse lülitada ja siis lükkab selle tagasi filtreerimisreegel, mis tunnelit üldse ei maini. Miski sellest ei mõjuta lüüsi enda vastust, seepärast eksitab sümptom nii usaldusväärselt.

Tunneli kaudu jõutavad halduslehed kuuluvad samuti esimesse kategooriasse. Need on tõendus tunnelist, mitte selle taga olevast võrgust.

Järgige voogu kuni esimese piirini, mis selle maha viskab

Alustage kliendist ja kinnitage marsruut ning lähteaadress, mida voog kasutab. Seejärel jälgige lüüsil täpselt selle voo saabumist ja uuesti sama voogu LAN-i suunas lahkumas. Kui see ei saabu kunagi, on probleem kliendi poolel või tunneli lubatud prefiksites. Kui see saabub ega lahku kunagi, on probleem edastamises või edasise tee filtril, ja püüd on juba öelnud, milles.

Sama testi lüüsilt jooksutamine varjab huvitava poole, sest lüüsilt pärineval paketil on teine lähtekoht ja teine tagasituleku nõue. Kasutage iga sammu jaoks kliendi voogu koos selle enda lähteaadressiga. Vale liidese pealt tehtud püüd annab enesekindlat jama.

Tagasiteed ja hosti tulemüürid nurjuvad eraldi

Kui pakett on hostini jõudnud, peavad kehtima veel kolm asja. Teenus peab kuulama aadressil, kuhu pakett saadeti, hosti tulemüür peab selle vastu võtma ja vastusel peab olema tagasitee kliendikogumi poole. Viimane nurjub sageli, sest hosti vaikemarsruut osutab ruuterile, mis ei ole tunneli vahemikust kunagi kuulnud. Tulemuseks on ühendus, mis luuakse hosti vaatepunktist ja sureb teises suunas vaikselt.

Katsetage tagasiteed meelega: saatke kliendist ja jälgige tagasitulekut. Ühesuunaline püüd lahendab sekunditega selle, mida tund oletusi ei lahenda.

Kinnitage iga hüpe kliendi lähteaadressiga

Käivitage kontrollid järjekorras ja hoidke iga väljund alles, sest väärtus peitub võrdluses, mitte üheski üksikus reas. Allolevad käsud kinnitavad lähteaadressi, näitavad valitud marsruuti ja püüavad edastuse mõlemad pooled. Asendage oma LAN-host ja tunneli liides.

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

Marsruudipäring näitab, kas klient üldse selle paketi tunnelisse saadaks, ja ping näitab, kas hostist tuli midagi tagasi. Kahe püüde võrdlemine eraldab saabumise väljumisest, sest kaader tunneli liidesel ilma vasteta LAN-i liidesel on edastusotsus, mitte teenuse tõrge. Kui mõlemad püüded näitavad päringut ja ainult üks näitab vastust, on järelejäänud kahtlusalune tagasitee.

Pange kirja, milline aadress vastas ja milline edastatud sihtkoht nurjus. See lause muudab aruande tegutsemisväärseks, selle asemel et väita, nagu server oleks kättesaamatu.