VPN blokira lokalni LAN na Windowsu: ruta ili klijentska politika?

Pisač, NAS ili razvojno računalo na vašem vlastitom stolu prestaju odgovarati u trenutku kada se poslovni VPN spoji. Ponekad naredba za rutu to popravi u sekundama; ponekad je ista ruta ispravna, a paketi ipak nestaju, što znači da gledate drugi problem sa sličnim simptomom. Odluka se svodi na tri pitanja, a njihovo postavljanje u pogrešnom redoslijedu razlog je zašto ljudi provedu cijelu večer brišući i ponovno dodajući rute.

Tri pitanja prije bilo koje naredbe

Prvo: postoji li zapis za lokalni prefiks i pokazuje li na fizički adapter? Drugo: dobiva li klijent pri spajanju dopuštenje ili zabranu lokalne mreže od pristupnika? Treće: trebate li samo odlazni pristup LAN-u, ili nešto na internetu također mora doći do usluge koja radi na vašem računalu?

Prvo pitanje razdvaja kvar usmjeravanja od kvara filtriranja. Drugo kaže smije li popravak rute uopće djelovati. Treće mijenja popravak: ruta popravlja odlazni promet, dok je nedostupna ulazna usluga obično problem vezanja slušatelja i povratnog puta koji ruta pogoršava.

Pitanje prvo: ruta, filtar ili naziv

Pročitajte tablicu prije nego joj išta dodate. Indeks sučelja je važan jer je svaka naredba za rutu ispod vezana uz njega:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Izravno povezana podmreža obično zadržava rutu na vezi čak i dok je tunel aktivan, pa zapis može postojati, a promet ipak ne uspijeva. Ta kombinacija potpis je filtra koji radi nakon usmjeravanja i to je slučaj u kojem druga, preciznija ruta ne mijenja baš ništa.

Testirajte odvojeno po adresi i po nazivu. Ako ping 192.168.1.50 odgovara, a net view 192.168.1.50 ne, tablica usmjeravanja nikada nije bila problem: tunel je promijenio razrješivač i lokalni naziv se više ne razrješava. Dodavati rutu za to je uzaludan posao.

Pitanje drugo: dopušta li pristupnik pristup lokalnom LAN-u?

Komercijalni klijent instalira više od ruta. Pri spajanju dobiva politiku, a ta politika može sadržavati izričito dopuštenje lokalne mreže. U Cisco IPsec implementacijama grupna politika nosi postavku split-tunnelinga i zasebnu zastavicu pristupa lokalnom LAN-u; potvrdni okvir u klijentu zahtjev je koji pristupnik može odbiti. U AnyConnectu profil upravlja popisima uključivanja i isključivanja split-a i istim dopuštenjem. Na Windows RRAS-u ekvivalenti su opcija zadanog pristupnika u profilu plus statičke rute koje poslužitelj dodjeljuje.

Kad je zastavica isključena, dokumentirano ponašanje je da klijent blokira promet prema izravno povezanoj podmreži iako postoji valjana, preciznija ruta. Zato i rute koje klijent ne posjeduje mogu nestati sekundama nakon što ih dodate: klijent ponovno gradi stanje koje mu je rečeno da izgradi, ne bori se protiv vas.

Klijentski zapis bilježi odluku pri spajanju i čitanje je brže od bilo kojeg pokusa na računalu. Ako zapis kaže da je lokalni pristup blokiran, zaustavite se: nijedan popravak iz naredbenog retka to ne preživi, a preostaju samo promjena politike, dolazak do resursa kroz tunel ili zatvaranje klijenta u virtualno računalo i ostavljanje hosta na lokalnoj mreži.

Pitanje treće: koji smjer trebate?

Odlazni promet prema obližnjem uređaju pitanje je usmjeravanja. Usmjerite prefiks LAN-a na lokalni pristupnik s metrikom dovoljno niskom da pobijedi zadanu rutu tunela:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Drugi oblik prikvačuje jedan uređaj, što želite kada je jedna adresa cijeli zahtjev. Ekvivalent netsh bilježi istu odluku po nazivu sučelja umjesto po indeksu:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Naredbe za rutu ne uspijevaju s Parametar je netočan kada se adresa i maska ne slažu, na primjer adresa hosta s maskom /24. Upotrijebite mrežnu adresu za rutu podmreže i masku hosta za jedan host.

Ulazni je drukčiji. VNC ili SSH poslužitelj na istom računalu postaje nedostupan kada odgovori na ulaznu vezu odu kroz VPN pristupnik i nikada se ne vrate. Provjerite na čemu usluga sluša prije nego dirate rute:

netstat -ano | findstr :5900

Slušatelj vezan na jednu određenu adresu neće odgovarati na drugom sučelju. Vezati ga na sva sučelja svjesna je odluka, donesena zajedno s pravilom vatrozida ograničenim na mrežu kojoj vjerujete. Tek nakon toga popravak rute vraća povratni put.

Primijenite najmanju promjenu koja odgovara

Drugi uobičajeni potez je isključiti „Koristi zadani pristupnik na udaljenoj mreži“ u naprednim svojstvima IPv4. To zadržava internetski promet lokalnim, ali čini dvije stvari odjednom: VPN prestaje biti zadani put i klijent prestaje primati rute za udaljenu mrežu, uključujući multicast. Isključite to i udaljeni LAN nestaje, osim ako poslužitelj gura određene udaljene prefikse koje svaki klijent treba.

Ta asimetrija odlučuje redoslijed rada. Ako udaljena strana mora ostati potpuno dostupna, gurajte udaljene podmreže s poslužitelja i pustite lokalnu zadanu rutu na miru. Ako ne možete promijeniti poslužitelj, dodajte trajnu rutu prema udaljenom prefiksu kroz adresu koju je tunel dodijelio i provjerite s route print da prefiks pokazuje na VPN sučelje dok zadana ruta još pokazuje na fizički pristupnik.

Zatim potvrdite da popravak preživljava ponovno spajanje, jer nepovratne rute umiru s adapterom, a skripta koja se izvodi nakon svake veze pošteno je mjesto za njih. Testirajte jedan lokalni uređaj i jedan udaljeni resurs u istoj sesiji, prekinite vezu, ponovno se spojite i testirajte opet. Ako lokalni uređaj i dalje ne uspijeva dok ruta izgleda ispravno, vratite se na drugo pitanje: klijent filtrira i odgovor je promjena politike, a ne druga konkurentska ruta.