VPN ја блокира локалната LAN во Windows: маршрута или политика на клиентот?
Пристапот до локалната LAN во Windows се прекинува од две различни причини: маршрута што недостасува или политика на портата што ја отфрла подмрежата. Три проверки кажуваат која.
Печатач, NAS или развојна машина на вашето сопствено биро престануваат да одговараат во моментот кога работниот VPN се поврзува. Понекогаш една команда за маршрута го поправа тоа за секунди; понекогаш истата маршрута е точна, а пакетите сепак исчезнуваат, што значи дека гледате друг проблем со сличен симптом. Одлуката се сведува на три прашања, а нивното поставување во погрешен ред е причината зошто луѓето поминуваат цела вечер бришејќи и повторно додавајќи маршрути.
Три прашања пред секоја команда
Прво: дали постои запис за локалниот префикс и дали покажува на физичкиот адаптер? Второ: дали клиентот при поврзување добива дозвола или одбивање за локалната мрежа од портата? Трето: дали ви треба само излезен пристап до LAN, или нешто на интернет исто така треба да стигне до услуга што работи на вашата машина?
Првото прашање го одвојува дефектот во рутирањето од дефектот во филтрирањето. Второто кажува дали поправката на маршрутата воопшто смее да работи. Третото ја менува поправката: маршрутата го поправа излезниот сообраќај, додека недостапната влезна услуга обично е проблем со врзувањето на слушателот и повратниот пат, што маршрутата го влошува.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
Прашање прво: маршрута, филтер или име
Прочитајте ја табелата пред да додадете нешто во неа. Индексот на интерфејсот е важен, бидејќи секоја команда за маршрута подолу е закотвена на него:
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 интерфејсот, додека стандардната уште покажува на физичката порта.
Потоа потврдете дека поправката преживува повторно поврзување, бидејќи непостојаните маршрути умираат со адаптерот, а скриптата што се извршува по секое поврзување е чесното место за нив. Во истата сесија тестирајте еден локален уред и еден далечински ресурс, исклучете се, поврзете се повторно и тестирајте повторно. Ако локалниот уред уште не успева додека маршрутата изгледа точна, вратете се на второто прашање: клиентот филтрира, и одговорот е промена на политиката, а не втора конкурентна маршрута.