VPN klijent na LAN serveru: zašto odgovori odlaze pogrešnim putem

Simptomi slijede jedan obrazac: host radi, zatim se kao klijent poveže na VPN, i sada ga LAN klijenti dosegnu dok njegovi odgovori nestaju. Snimka na hostu pokazuje da odgovori izlaze kroz tunelski uređaj umjesto kroz LAN sučelje. Ništa na tunelu nije pokvareno, a popravak je ruta, ne ponovno povezivanje. Prođite četiri provjere ispod redom i zaustavite se na prvoj koja ne uspije.

Odgovor je novi paket, ne preokret

Korisno je odbaciti ideju da se odgovor vraća istim putem kojim je zahtjev išao. Usmjeravanje se odlučuje po paketu, po smjeru, na hostu pošiljatelju. Zahtjev koji je stigao s 10.64.0.23 unutar tunela ne stvara povratni put; kada host odgovori, taj se odgovor uspoređuje s tablicom kao novi paket i odlazi onom rutom koja pobijedi.

Zato klijent punog tunela na računalu koje ujedno služi LAN stvara tako zbunjujuću grešku. Klijent instalira zadanu rutu, ili dvije poluzadane rute koje neki klijenti preferiraju, i odgovor LAN klijentu sada odgovara tunelu. Odlazi do pružatelja, koji nema razloga da ga proslijedi, a LAN klijent vidi istek vremena iako je host podignut i odgovara lokalno. Snimka to čini očitim, a tablica usmjeravanja to objašnjava.

Držite dvije podmreže u glavi dok čitate ostatak. Jedna je VPN bazen adresa iz kojeg dolaze udaljeni klijenti, u ovom primjeru 10.64.0.0/24. Druga je LAN koji mora nastaviti raditi, 172.16.24.0/24 s usmjerivačem na 172.16.24.1. Greška je u tome što promet između njih određuje zadana ruta.

Dokažite to snimkom i pretragom

Prije nego što išta promijenite, potvrdite koji će uređaj odgovor koristiti. Pretraga je brža od snimke i odgovara na točno ono pitanje na koje će jezgra odgovoriti kad se paket sastavlja.

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

Pročitajte odgovor u dva dijela. Ako navede dev tun0, host će odgovor enkapsulirati i predati ga pružatelju, a LAN klijent ga nikada neće vidjeti. Ako navede dev eth0 ali klijent ipak dobije istek vremena, ruta je već ispravna i paket se odbacuje kasnije, što je drugi problem s drugim popravkom.

Snimka u istom koraku rješava sumnju koju ping ne može. Dolazak eho odgovora do LAN klijenta dokazuje da neki put radi, a ne koje ga je sučelje nosilo, zato snimku izvodite na samom hostu i gledajte odakle okviri izlaze. Pisač na istoj podmreži nastavlja odgovarati, jer je njegova izravna ruta specifičnija od zadane rute tunela. Proslijeđeni port ne uspijeva baš kao i svaki drugi tok, jer sučelje bira tablica, a ne veza.

Instalirajte najužu rutu koja nadjačava tunel

Dužina prefiksa odlučuje, ne metrika, pa ruta za bazen klijenata preko LAN usmjerivača pobjeđuje svaku zadanu rutu koju VPN klijent instalira. Operacija na metrici nije potrebna, a zadana ruta može ostati točno tamo gdje ju je klijent postavio.

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

Koristite replace umjesto add, jer je klijent koji se ponovno poveže već instalirao svoj zapis, a drugi add ne uspijeva s greškom da ruta već postoji, koja zvuči kao problem s dopuštenjima. Na Windows hostu ekvivalent je route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, gdje -p čuva zapis kroz ponovna pokretanja, jer klijent može ponovno sastaviti tablicu kad se tunel vrati. Na suvremenom Windows hostu podržani ekvivalent je New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, a starija naredba route zadržana je kao naslijeđeni oblik.

Jedan detalj odlučuje je li to ispravno ili samo uvjerljivo: sljedeći skok mora biti usmjerivač koji zapravo posjeduje put natrag do klijenata. Usmjeravanje rute na adresu do koje se i sam dolazi kroz tunel stvara petlju koja se pojavljuje kao povremeni gubitak, a ne kao čist neuspjeh. Potvrdite da je sljedeći skok na LAN podmreži prije nego što unesete redak.

Zadržite odgovor nakon ponovnog povezivanja

Ruta dodana rukom preživi u najboljem slučaju do sljedećeg ponovnog povezivanja. Ako je bazen klijenata dinamičan, prikvačite ga u konfiguraciju poslužitelja da prefiks koji ste usmjerili ostane prefiks koji klijenti primaju; inače zapis pokazuje na prazan raspon i simptom se vraća tjednima kasnije bez očitog uzroka. Upisivanje rute u klijentovu vlastitu up-skriptu druga je pouzdana opcija, jer se izvodi nakon što je klijent prepisao tablicu.

Vatrozid sa stanjem ipak može pobijediti ispravnu rutu. Ako snimka sada pokazuje da odgovor izlazi kroz eth0, a klijent još uvijek dobije istek vremena, provjerite odbacuje li host paket prije slanja. Strogo filtriranje obrnutog puta i net.ipv4.conf.all.rp_filter postavljen na 1 odbacuju pakete čiji se izvor ne bi usmjerio natrag kroz sučelje na koje su stigli, a to je upravo asimetrični slučaj koji ste upravo stvorili i zatim popravili, a conntrack stanje priča istu priču za proslijeđene portove.

Posljednja provjera je ona koju ljudi preskaču: ponovite pretragu nakon što je tunel pao i ponovno se podigao. Četiri vrijednosti trebaju odgovarati onome što ste zapisali: odredište, sljedeći skok, uređaj i odabrani izvor. Ako se bilo koja pomaknula, klijent je prepisao tablicu i popravak pripada njegovim hookovima, a ne povijesti ljuske.