Dalīts tunelis sistēmā Windows: vārtejas lodziņš un trūkstošais prefikss

Tunelis ziņo, ka ir savienots, un viki joprojām ielādējas. Tad lejupielāde apstājas un koplietojums plauktā pārstāj atbildēt. Tunelis izdarīja savu darbu, un profils vienkārši pieprasīja katru galamērķi.

Windows VPN savienojumu uzskata par maršrutēšanas lēmumu. Kamēr šis lēmums nav sašaurināts, iekārta uzvedas tā, it kā būtu pārcēlusies uz biroju.

Kāpēc strādājošs tunelis šķiet kā pārtraukums

Profils, kuram atļauts izmantot attālo vārteju, instalē noklusējuma maršrutu pa tuneli. Tad katrs galamērķis, kas nav lokālajā saitē, iziet caur biroja ugunsmūri. Lokālie koplietojumi pārstāj atbildēt, jo to datplūsma tagad ceļo uz citu kontinentu un atpakaļ. Nekas klienta stāvoklī to neatspoguļo.

Simptomi ir apzināti mulsinoši. Nosaukumu izšķiršana var vēl strādāt, kamēr koplietojums beidzas ar taimautu, vai otrādi. Lietotājs ziņo, ka VPN ir salūzis, klients ziņo, ka tam viss ir kārtībā, un abi apgalvojumi ir precīzi.

Atzīmes lodziņš, kas slēpjas IPv4 dialoglodziņā

Iestatījums atrodas vairākus dialoglodziņus dziļāk. Atveriet ncpa.cpl, ar labo peles pogu noklikšķiniet uz savienojuma, tad IPv4 rekvizītus, tad Papildu, un noņemiet opciju, kas ļauj savienojumam kļūt par attālo noklusējuma vārteju. Šis viens lodziņš izšķir, vai profils ir pilns tunelis. Viss pārējais profilā joprojām ir spēkā.

Salīdziniet route print -4 pirms un pēc atkārtotas pievienošanas. Ierakstam 0.0.0.0, kas agrāk norādīja uz tuneli, vajadzētu būt pazudušam, un uzņēmuma prefiksiem joprojām jābūt tur.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Saskarnes metrikas maiņa nav aizstājējs. Metrika izšķir tikai starp diviem konkurējošiem noklusējuma maršrutiem, un klients, kas katrā savienojumā no jauna instalē savu noklusējuma maršrutu, uzvar šajā sacensībā neatkarīgi no iestatītā skaitļa.

Prefikss, kuru neviens neuzskaitīja

Dalīts tunelis atklāj tieši tos prefiksus, kas ierakstīti profilā. Biroja apakštīkls, kas pievienots pēc profila uzrakstīšanas, paliek nesasniedzams, kamēr tunelis ir pilnīgi vesels. Tad ziņojums pienāk kā viens salūzis serveris, nevis salūzis VPN.

Ar roku pievienots maršruts aizpilda plaisu, līdz mainās vārtejas adrese. Prefiksa ierakstīšana savienojumā ir noturīgāka, jo prefikss tad seko savienojumam, nevis minētai adrese.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Lasiet saglabāto sarakstu un dzīvo tabulu kopā. Saglabāts prefikss var pastāvēt, kamēr tabula to nekad nesaņem, kas notiek, kad pārvaldības aģents filtrē maršrutus pēc savienojuma pacelšanas. Notiek arī pretējais, kad reģistra maršruts norāda uz adapteri, kas ir izslēgts. Neviens no abiem skatiem vienatnē neizstāsta visu stāstu.

Rezultāta pierādīšana pēc pārstartēšanas

Izsekojiet abos virzienos un atrisiniet pēc nosaukuma. Publiskajai izsekošanai jāiet ārā pa pakalpojumu sniedzēju, iekšējai izsekošanai jāienāk tunelī, un iekšējam resursdatoram jāatbild pēc nosaukuma, nevis tikai pēc adreses.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Atkārtojiet pēc atvienošanas, atkārtotas pievienošanas un vienas pārstartēšanas. Prefikss, kas pārdzīvo manuālu atkārtotu pievienošanu un pazūd pēc pārstartēšanas, nekad nav bijis saglabāts profilā.

Paturiet testā arī printeri un NAS, jo dalīts tunelis, kas nogriež ierīces blakus klēpjdatoram, ir atrisinājis vienu problēmu, radot mazāku un kaitinošāku. Microsoft Add-VpnConnectionRoute uzziņa ir vieta, kur pārbaudīt parametru pareizrakstību pret jūsu moduļa versiju.