VPN prisijungia, bet LAN įrenginių nepasiekia: ką tikrinti

Srautas patenka į tunelį, tinklų sietuvas atsako savo pačio adresu, o už jo niekas neatsako. Šis modelis įprastas ir tai ne prieštaravimas: atsakymas iš tinklų sietuvo įrodo, kad tunelis baigėsi, ir neįrodo nieko apie tai, kas atsitinka už jo adresuotam paketui. Abu testai naudoja skirtingus kodo kelius toje pačioje mašinoje.

Nuo šiol išbandykite ką nors kitoje tinklų sietuvo pusėje. Pačio tinklų sietuvo adresas ir toliau atsakinės, kad ir kokia sulaužyta būtų peradresavimas.

Tinklų sietuvas atsako iš savo paties kamino

Tinklų sietuvui adresuotas paketas perduodamas į jo vietinį įvesties kelią, kur branduolys nusprendžia, ar jį priims klausantis lizdas. Už tinklų sietuvo esančiam mazgui adresuotas paketas vietoj to perduodamas į peradresavimo kelią, kur galioja kitas patikrų rinkinys. Peradresavimą galima visiškai išjungti, arba branduolys jį įjungia, o paskui atmeta filtro taisyklė, kuri niekada nemini tunelio. Niekas iš to neturi įtakos pačiam tinklų sietuvo atsakymui, todėl simptomas taip patikimai klaidina.

Administravimo puslapiai, pasiekiami per tunelį, taip pat priklauso pirmajai kategorijai. Jie yra įrodymas apie tunelį, o ne apie tinklą už jo.

Sekite srautą iki pirmos ribos, kuri jį numeta

Pradėkite nuo kliento ir patvirtinkite maršrutą bei šaltinio adresą, kurį naudos srautas. Tada stebėkite tinklų sietuvą, ar atvyksta būtent tas srautas, ir dar kartą tą patį srautą, išvykstantį link LAN. Jei jis niekada neatvyksta, problema yra kliento pusėje arba leistinuose tunelio prefiksuose. Jei atvyksta ir niekada neišvyksta, problema yra peradresavime arba priekinio kelio filtre, ir įrašas jau pasakė, kuriame.

To paties testo atlikimas iš tinklų sietuvo paslepia įdomiąją pusę, nes iš tinklų sietuvo kilęs paketas turi kitą šaltinį ir kitą grįžimo reikalavimą. Kiekviename žingsnyje naudokite kliento srautą su jo paties šaltinio adresu. Netinkamoje sąsajoje padarytas įrašas duoda pasitikintį nonsensą.

Grįžimo maršrutai ir mazgo ugniasienės nepavyksta atskirai

Kai paketas pasiekia mazgą, turi galioti dar trys dalykai. Paslauga turi klausytis adrese, į kurį paketas buvo išsiųstas, mazgo ugniasienė turi jį priimti, ir atsakymas turi turėti grįžimo maršrutą link klientų baseino. Pastarasis dažnai nepavyksta, nes numatytasis mazgo maršrutas rodo į maršrutizatorių, kuris niekada negirdėjo apie tunelio diapazoną. Rezultatas yra ryšys, kuris užsimezga mazgo požiūriu ir tyliai miršta kita kryptimi.

Tikslingai patikrinkite grįžimo kelią siųsdami iš kliento ir stebėdami grįžimą. Vienkryptis įrašas per sekundes išsprendžia tai, ko neišspręs valanda spėlionių.

Patvirtinkite kiekvieną šuolį kliento šaltinio adresu

Atlikite patikras iš eilės ir išsaugokite kiekvieną išvestį, nes vertė yra palyginime, o ne vienoje eilutėje. Toliau pateiktos komandos užfiksuoja šaltinio adresą, parodo pasirinktą maršrutą ir įrašo abi peradresavimo puses. Pakeiskite savo LAN mazgą ir tunelio sąsają.

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

Maršruto užklausa parodo, ar klientas apskritai siųstų tą paketą į tunelį, o ping parodo, ar kas nors grįžo iš mazgo. Dviejų įrašų palyginimas atskiria atvykimą nuo išvykimo, nes kadras tunelio sąsajoje be atitikmens LAN sąsajoje yra peradresavimo sprendimas, o ne paslaugos gedimas. Kai abu įrašai rodo užklausą, o tik vienas rodo atsakymą, likęs įtariamasis yra grįžimo maršrutas.

Užrašykite, kuris adresas atsakė ir kuris peradresuotas tikslas nepavyko. Tas sakinys daro ataskaitą veiksmingą vietoj teiginio, kad serveris nepasiekiamas.