VPN блокира локалну LAN мрежу на Windows-у: рута или политика клијента?

Штампач, NAS или развојна машина на сопственом столу престају да одговарају у тренутку када се повеже пословни VPN. Понекад једна команда руте то поправи за неколико секунди; понекад је иста рута исправна, а пакети ипак нестају, што значи да гледате други проблем са сличним симптомом. Одлука се своди на три питања, а њихово постављање у погрешном редоследу разлог је зашто људи проведу цело вече бришући и поново додајући руте.

Три питања пре било које команде

Прво: постоји ли запис за локални префикс и показује ли на физички адаптер? Друго: да ли клијент при повезивању добија дозволу или одбијање локалне мреже од пролаза? Треће: да ли вам треба само одлазни приступ LAN мрежи, или нешто на интернету такође мора да стигне до услуге која ради на вашој машини?

Прво питање раздваја квар усмеравања од квара филтрирања. Друго каже да ли је поправка руте уопште дозвољена. Треће мења поправку: рута поправља одлазни саобраћај, док је недоступна улазна услуга обично проблем везивања слушаоца и повратног пута који рута још погоршава.

Питање прво: рута, филтер или име

Прочитајте табелу пре него што јој било шта додате. Индекс интерфејса је важан, јер је свака команда руте испод везана за њега:

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

Директно повезана подмрежа обично задржава on-link руту чак и док је тунел активан, тако да запис може постојати, а саобраћај ипак не успети. Та комбинација је потпис филтера који ради после усмеравања, и то је случај у којем друга, прецизнија рута не мења баш ништа.

Тестирајте одвојено по адреси и по имену. Ако ping 192.168.1.50 одговара, а net view 192.168.1.50 не, табела усмеравања никада није била проблем: тунел је променио резолвер и локално име се више не разрешава. Додавање руте због тога је узалудан посао.

Питање друго: да ли пролаз дозвољава приступ локалној LAN мрежи?

Комерцијални клијент инсталира више од рута. При повезивању добија политику, а та политика може садржати изричиту дозволу локалне мреже. У распоређивањима Cisco IPsec групна политика носи подешавање split-tunneling и засебну заставицу приступа локалној LAN мрежи; поље за потврду у клијенту је захтев који пролаз може одбити. У AnyConnect-у профил контролише листе укључивања и искључивања split-а и исту дозволу. На Windows RRAS-у еквиваленти су опција подразумеваног пролаза у профилу плус статичне руте које сервер додељује.

Када је заставица искључена, документовано понашање је да клијент блокира саобраћај ка директно повезаној подмрежи, иако постоји важећа, прецизнија рута. Зато и руте које клијент не поседује могу нестати неколико секунди након што их додате: клијент поново гради стање које му је наређено да изгради, не бори се против вас.

Клијентски дневник бележи одлуку при повезивању, а његово читање је брже од било ког експеримента на машини. Ако дневник каже да је локални приступ блокиран, зауставите се: ниједна поправка из командовне линије то не преживљава, и остају само промена политике, приступ ресурсу кроз тунел или затварање клијента у виртуелну машину и остављање домаћина на локалној мрежи.

Питање треће: који смер вам је потребан?

Одлазни саобраћај ка оближњем уређају је питање усмеравања. Усмерите префикс LAN мреже ка локалном пролазу са метриком довољно ниском да победи подразумевану руту тунела:

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

Други облик причвршћује један уређај, што је оно што желите када је једна адреса цео захтев. Еквивалент netsh бележи исту одлуку по имену интерфејса, а не по индексу:

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

Команде руте не успевају са Параметар је нетачан када се адреса и маска не слажу, на пример адреса домаћина са маском /24. За руту подмреже користите адресу мреже, а за једног домаћина маску домаћина.

Улазни саобраћај је другачији. VNC или SSH сервер на истој машини постаје недоступан када одговори на улазну везу оду кроз VPN пролаз и никада се не врате. Проверите на чему услуга слуша пре него што дирнете руте:

netstat -ano | findstr :5900

Слушалац везан на једну одређену адресу неће одговарати на другом интерфејсу. Везивање на све интерфејсе је свесна одлука, донета заједно са правилом заштитног зида ограниченим на мрежу којој верујете. Тек након тога поправка руте враћа повратни пут.

Примените најмању промену која одговара

Други уобичајени потез је уклањање ознаке на „Користи подразумевани пролаз на удаљеној мрежи“ у напредним својствима IPv4. То задржава интернет саобраћај локалним, али чини две ствари одједном: VPN престаје да буде подразумевани пут, и клијент престаје да прима руте за удаљену мрежу, укључујући multicast. Уклоните ознаку и удаљена LAN мрежа нестаје, осим ако сервер не гура конкретне удаљене префиксе који су потребни сваком клијенту.

Та асиметрија одређује редослед рада. Ако удаљена страна мора да остане потпуно доступна, гурајте удаљене подмреже са сервера и оставите локалну подразумевану на миру. Ако не можете да промените сервер, додајте трајну руту ка удаљеном префиксу кроз адресу коју је тунел доделио, и проверите помоћу route print да префикс показује на VPN интерфејс, док подразумевана још увек показује на физички пролаз.

Затим потврдите да поправка преживљава поновно повезивање, јер неперзистентне руте умиру са адаптером, а скрипта која се покреће после сваке везе је поштено место за њих. Тестирајте један локални уређај и један удаљени ресурс у истој сесији, прекините везу, повежите се поново и тестирајте још једном. Ако локални уређај и даље не успева док рута изгледа исправно, вратите се на друго питање: клијент филтрира, и одговор је промена политике, а не друга конкурентска рута.