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

Saobraćaj ulazi u tunel, gateway odgovara na vlastitu adresu, a ništa iza njega ne odgovara. Taj obrazac je čest i nije protivrječnost: odgovor s gatewayja dokazuje da je tunel završen i ne dokazuje ništa o tome šta se dešava s paketom adresiranim mimo njega. Dva testa aktiviraju različite kodne putanje na istom računaru.

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

Gateway odgovara iz vlastitog steka

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 važi drugačiji skup provjera. Prosljeđivanje može biti potpuno onemogućeno ili ga kernel može omogućiti, a zatim odbiti pravilo filtera koje uopće ne spominje tunel. Ništa od toga ne utič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 ponovo 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 filteru putanje naprijed, a snimka je već rekla koji je.

Pokretanje istog testa s gatewayja skriva zanimljivu polovinu, 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 interfejsu 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 ruter 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 poređenju, a ne u bilo kojem pojedinom redu. Naredbe ispod prikvačuju izvornu adresu, prikazuju odabranu rutu i snimaju obje strane prosljeđivanja. Zamijenite svoj LAN host i interfejs 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. Poređenje dviju snimki razdvaja dolazak od izlaska, jer okvir na interfejsu tunela bez pandana na LAN interfejsu 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 server nedostupan.