VPN se povezuje, ali LAN uređaji nisu dostupni: što provjeriti

Promet ulazi u tunel, gateway odgovara na vlastitu adresu, a ništa iza njega ne odgovara. Taj je obrazac čest i nije proturječje: odgovor s gatewayja dokazuje da je tunel završio i ne dokazuje ništa o tome što se događa s paketom adresiranim izvan njega. Dva testa aktiviraju različite kodne putanje na istom računalu.

Od sada testirajte nešto na drugoj strani gatewayja. Vlastita adresa gatewayja nastavit će odgovarati koliko god prosljeđivanje bilo pokvareno.

Gateway odgovara iz vlastitog stoga

Paket adresiran na gateway isporučuje se na njegovu lokalnu ulaznu putanju, gdje kernel odlučuje hoće li ga prihvatiti socket koji sluša. Paket adresiran na host iza gatewayja umjesto toga se isporučuje na putanju prosljeđivanja, gdje vrijedi drugačiji skup provjera. Prosljeđivanje može biti potpuno onemogućeno ili ga kernel može omogućiti, a zatim odbiti pravilo filtra koje uopće ne spominje tunel. Ništa od toga ne utječe na vlastiti odgovor gatewayja, zato simptom tako pouzdano obmanjuje.

Administrativne stranice do kojih se dolazi kroz tunel također pripadaju prvoj kategoriji. One su dokaz o tunelu, ne o mreži iza njega.

Pratite tok do prve granice koja ga odbacuje

Počnite od klijenta i potvrdite rutu i izvornu adresu koju će tok koristiti. Zatim na gatewayju promatrajte dolazak tog točno određenog toka, pa ponovno isti tok kako izlazi prema LAN-u. Ako nikad ne dođe, problem je na strani klijenta ili u dopuštenim prefiksima tunela. Ako dođe i nikad ne izađe, problem je u prosljeđivanju ili filtru putanje naprijed, a snimka je već rekla koji je.

Pokretanje istog testa s gatewayja skriva zanimljivu polovicu, jer paket nastao na gatewayju ima drugačiji izvor i drugačiji zahtjev za povratkom. Koristite klijentski tok, s njegovom vlastitom izvornom adresom, u svakom koraku. Snimka napravljena na pogrešnom sučelju daje samouvjerenu besmislicu.

Povratne rute i host firewallovi padaju odvojeno

Kad paket stigne do hosta, moraju vrijediti još tri stvari. Servis mora slušati na adresi na koju je paket poslan, host firewall ga mora prihvatiti, i odgovor mora imati rutu natrag prema bazenu klijenata. Ta posljednja često pada, jer zadana ruta hosta pokazuje na usmjerivač koji nikad nije čuo za raspon tunela. Rezultat je veza koja se uspostavlja iz perspektive hosta i tiho umire u drugom smjeru.

Namjerno testirajte povratnu putanju slanjem s klijenta i promatranjem povratka. Jednosmjerna snimka riješi u sekundama ono što sat nagađanja neće.

Potvrdite svaki hop izvornom adresom klijenta

Izvršite provjere redom i sačuvajte svaki izlaz, jer vrijednost je u usporedbi, a ne u bilo kojem pojedinom retku. Naredbe ispod prikvačuju izvornu adresu, prikazuju odabranu rutu i snimaju obje strane prosljeđivanja. Zamijenite svoj LAN host i sučelje tunela.

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

Upit rute pokazuje bi li klijent uopće poslao taj paket u tunel, a ping pokazuje je li se išta vratilo s hosta. Usporedba dviju snimki razdvaja dolazak od izlaska, jer okvir na sučelju tunela bez pandana na LAN sučelju je odluka o prosljeđivanju, a ne kvar servisa. Kad obje snimke pokazuju zahtjev, a samo jedna pokazuje odgovor, povratna ruta je preostali sumnjivac.

Zapišite koja je adresa odgovorila i koja proslijeđena destinacija nije uspjela. Ta rečenica čini izvještaj primjenjivim umjesto tvrdnje da je poslužitelj nedostupan.