VPN klientas LAN serveryje: kodėl atsakymai išeina neteisingu keliu

Simptomai seka vieną šabloną: hostas veikia, tada jis prisijungia prie VPN kaip klientas, ir dabar LAN klientai jį pasiekia, o jo atsakymai dingsta. Užfiksuotame hosto eisme matyti, kad atsakymai išeina per tunelio įrenginį, o ne per LAN sąsają. Tune nėra nieko sugedusio, o pataisa yra maršrutas, ne pakartotinis prisijungimas. Atlikite keturis patikrinimus žemiau iš eilės ir sustokite ties pirmuoju, kuris nepavyksta.

Atsakymas yra naujas paketas, o ne kelio apsisukimas

Padeda atsisakyti minties, kad atsakymas grįžta tuo pačiu keliu, kuriuo ėjo užklausa. Maršrutizavimas sprendžiamas kiekvienam paketui ir kiekvienai krypčiai siunčiančiame hoste. Užklausa, atėjusi iš 10.64.0.23 tunelio viduje, nesukuria grįžimo kelio; kai hostas atsako, tas atsakymas lyginamas su lentele kaip naujas paketas ir išeina tuo maršrutu, kuris laimi.

Štai kodėl viso tunelio klientas mašinoje, kuri taip pat aptarnauja LAN, sukelia tokį klaidinančią gedimą. Klientas įdiegia numatytąjį maršrutą arba du pusiau numatytuosius maršrutus, kuriuos mėgsta kai kurie klientai, ir atsakymas LAN klientui dabar atitinka tunelį. Jis eina pas teikėją, kuris neturi priežasties jį persiųsti, o LAN klientas mato skirtąjį laiką, nors hostas veikia ir atsako vietoje. Įrašas tai daro akivaizdu, o maršrutų lentelė paaiškina.

Skaitydami likusią dalį turėkite galvoje du potinklius. Vienas yra VPN adresų telkinys, iš kurio ateina nuotoliniai klientai, šiame pavyzdyje 10.64.0.0/24. Kitas yra LAN, kuris turi toliau veikti, 172.16.24.0/24 su maršrutizatoriumi 172.16.24.1. Klaida ta, kad srautą tarp jų nusprendžia numatytasis maršrutas.

Įrodykite tai įrašu ir užklausa

Prieš ką nors keisdami patvirtinkite, kurį įrenginį naudos atsakymas. Užklausa greitesnė už įrašą ir atsako į tą patį klausimą, į kurį atsakys branduolys, kai paketas bus sudarytas.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Skaitykite atsakymą dviem dalimis. Jei jame nurodyta dev tun0, hostas įpakavęs atsakymą perduos jį teikėjui, o LAN klientas jo niekada nepamatys. Jei nurodyta dev eth0, bet klientas vis tiek gauna skirtąjį laiką, maršrutas jau teisingas ir paketas atmetamas vėliau, o tai kita problema su kita pataisa.

To paties žingsnio įrašas išsprendžia abejonę, kurios ping negali. LAN klientą pasiekiantis atgarsio atsakymas įrodo, kad koks nors kelias veikia, o ne kuri sąsaja jį nešė, todėl darykite įrašą pačiame hoste ir stebėkite, iš kur išeina kadrai. To paties potinklio spausdintuvas toliau atsako, nes jo tiesioginis maršrutas konkretesnis už tunelio numatytąjį. Persiųstas prievadas nepavyksta lygiai taip pat, kaip bet koks kitas srautas, nes sąsają renkasi lentelė, o ne ryšys.

Įdiekite siauriausią maršrutą, kuris pranoksta tunelį

Sprendžia priešdėlio ilgis, ne metrika, todėl klientų telkinio maršrutas per LAN maršrutizatorių įveikia bet kurį numatytąjį maršrutą, kurį įdiegia VPN klientas. Metrikos chirurgijos nereikia, o numatytasis maršrutas gali likti tiksliai ten, kur jį padėjo klientas.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Naudokite replace, o ne add, nes klientas, kuris vėl prisijungs, jau bus įdiegęs savo įrašą, o antrasis add nepavyksta su klaida apie jau esamą maršrutą, kuri skaitoma kaip teisių problema. Windows hoste atitikmuo yra route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kur -p išsaugo įrašą tarp perkrovimų, nes klientas gali iš naujo sudaryti lentelę, kai tunelis vėl pakyla. Šiuolaikiniame Windows hoste palaikomas atitikmuo yra New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, o senesnė route komanda paliekama kaip paveldima forma.

Viena detalė nusprendžia, ar tai teisinga, ar tik tikėtina: kitas šuolis turi būti maršrutizatorius, kuris iš tikrųjų valdo kelią atgal į klientus. Maršruto nukreipimas į adresą, kuris pats pasiekiamas per tunelį, sukuria kilpą, kuri pasireiškia kaip protarpinis praradimas, o ne kaip švarus gedimas. Prieš patvirtindami eilutę įsitikinkite, kad kitas šuolis yra LAN potinklyje.

Išsaugokite atsakymą po pakartotinio prisijungimo

Rankiniu būdu pridėtas maršrutas geriausiu atveju išlieka iki kito prisijungimo. Jei klientų telkinys dinaminis, prisekite jį serverio konfigūracijoje, kad jūsų maršrutizuotas priešdėlis liktų priešdėliu, kurį gauna klientai; priešingu atveju įrašas rodo į tuščią intervalą ir simptomas grįžta po kelių savaičių be akivaizdžios priežasties. Maršruto įrašymas į paties kliento up scenarijų yra kita patikima galimybė, nes jis vykdomas po to, kai klientas perrašo lentelę.

Būsenos ugniasienė vis tiek gali nugalėti teisingą maršrutą. Jei įrašas dabar rodo, kad atsakymas išeina per eth0, o klientas vis tiek gauna skirtąjį laiką, patikrinkite, ar hostas nemeta paketo prieš siųsdamas. Griežtas atvirkštinio kelio filtravimas ir net.ipv4.conf.all.rp_filter, nustatytas į 1, meta paketus, kurių šaltinis nebūtų maršrutizuojamas atgal per sąsają, per kurią jie atėjo, ir tai yra būtent tas asimetrinis atvejis, kurį ką tik sukūrėte ir paskui ištaisėte, o conntrack būsena pasakoja tą pačią istoriją persiųstiems prievadams.

Paskutinis patikrinimas yra tas, kurį žmonės praleidžia: pakartokite užklausą po to, kai tunelis buvo nukritęs ir vėl pakilo. Keturios reikšmės turėtų atitikti tai, ką užsirašėte: paskirties vieta, kitas šuolis, įrenginys ir pasirinktas šaltinis. Jei kuri nors pasislinko, klientas perrašė lentelę ir pataisa priklauso jo kabliukams, o ne shell istorijai.