Miks teie Windowsi VPN-i marsruuditabel näitab 0.0.0.0/1 ja 128.0.0.0/1

Looge Windowsi VPN-ühendus ja avage marsruutimistabel, ning kaks kirjet paistavad silma: 0.0.0.0/1 ja 128.0.0.0/1. Need ei ole trükiviga ega asenda vaikemarsruuti. Nende ilmumine sõltub ühest profiilisuvast, ja see paar on viis, kuidas täistunnelit ehitatakse, mitte split-tunneli funktsioon. Lugege suvandit, prefiksit ja liidest koos enne, kui muudate ühtki rida.

Mida vaikelüüsi suvand paigaldab

Profiilisuvand, mis saadab kõik läbi tunneli, töötab nende kahe prefiksi lisamisega. Eemaldage suvand ja need kaovad, jättes marsruudi, mis katab ainult tunneliadapterile antud alamvõrgu. Märkeruut juhib paari; see ei kirjuta ümber ainsat vaikemarsruuti. Seetõttu näeb tabel pärast linnukese eemaldamist välja nagu osaline ümberkirjutus, mitte kustutamine.

0.0.0.0/1 katab IPv4-ruumi alumise poole ja 128.0.0.0/1 ülemise poole, nii et koos katavad need iga unicast-aadressi. Kumbki on täpsem kui vaikemarsruut 0.0.0.0/0, mis tähendab, et pikima prefiksi sobivus saadab tavaliikluse tunnelisse, samal ajal kui füüsiline vaikemarsruut jääb sinna, kus see oli. Selle vaikemarsruudi hoidmine ei ole kosmeetika: krüpteeritud koormust mähkivad paketid on adresseeritud serveri avalikule aadressile ja peavad väljuma füüsilise adapteri kaudu. Asendage vaikemarsruut selle jagamise asemel, ja tunneli enda transport üritab tunnelisse siseneda, mis on silmus, mitte ühendus.

Seetõttu tasub peatuda otsese 0.0.0.0/0 juures, mis osutab VPN-adapterile. Native-klient tavaliselt seda ei kirjuta, seega on käsitsi marsruut või mõne teise kliendi konfiguratsioon tabeli teie selja taga muutnud. Leidke see enne, kui hakkate midagi allpool siluma.

Lammutamine on odavam kui lüüsi hoidmine

Lammutamine on praktiline argument kahe kirje poolt ühe vastu. Klient omab ühenduse ajal täpselt kahte marsruuti ja kustutab need lahtiühendamisel, jättes alles selle, mida füüsiline adapter sel hetkel hoiab. Klient, kes oleks asendanud ainsa vaikemarsruudi, peaks meeles pidama eelmist lüüsi ja võiks pärast DHCP-liisingu muutumist taastada selle, mida enam ei ole. Kaks omatud kirjet sellist olekut ei kanna.

Teised kliendid jõuavad sama lahenduseni. OpenVPN-i profiil koos redirect-gateway def1-ga paigaldab need kaks prefiksit selle asemel, et vaikemarsruut kustutada, ja Windowsi klient järgib sama mustrit samal marsruutimispõhjusel.

Seetõttu võib tabel tunduda täistunnelina, kui ootasite jagunemist. Paar on viis, kuidas täistunnelit ehitatakse, mitte tõend split-tunneli veast. Kui profiil on seatud kasutama kauglüüsi, marsruuditakse kõik, ükskõik mida üks kohalik rakendus veel saavutab.

Pikim prefiks võidab enne mis tahes metrikat

Prefiksi pikkus otsustab otsingu enne mis tahes muud välja. Metrika lahendab ainult viiki marsruutide vahel, millel on identne prefiks, seega võidab /1 kirje /0 vaikemarsruuti ka siis, kui selle metrika on halvem. Liidesega sidumine otsustab, mis jääb alles, kui kaks marsruuti jagavad prefiksit ja Windows peab valima, milline adapter paketi saadab.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Split-tunneli tabel sisaldab füüsilist vaikemarsruuti, kahte poolvaikemarsruuti, tunneli alamvõrgu marsruuti ja iga lisatud kontoriprefiksit. Füüsiline vaikemarsruut võib olla madalama või kõrgema metrikaga sõltuvalt kliendist ja profiilist, ja kuni /1 paar eksisteerib, ei muuda see erinevus midagi. See muudab kõike hetkel, mil paar eemaldatakse, ja just siis ilmub aegunud lüüs või vale liides. Lugege kogu tabelit, mitte seda ühte rida, mida lootsite muuta.

Valige kontoriprefiksile üks omanik

Split-tunneli puhul nimetage ainult see prefiks, mis peab VPN-i kasutama, ja valige üks viis selle omamiseks. Marsruudi suunamine määratud tunneli aadressile töötab, kuni see aadress muutub, samas kui liidesega sidumine elab aadressimuutuse üle, kuid katkeb, kui indeks pärast profiili ümberehitamist uuesti määratakse. Profiiliga seotud cmdlet väldib mõlemat probleemi, hinnaga, et profiili on vaja.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Cmdlet seob prefiksi nimetatud profiiliga, nii et marsruut ilmub ühendusega ja lahkub sellega, mida haldatud sülearvuti soovib. Püsiv marsruut elab üle taaskäivitused ja elab üle profiili, mis selle esile kutsus, nii jätab kasutusest kõrvaldatud VPN kirjed aastateks maha. Valige iga prefiksi kohta üks meetod ja märkige valik üles, sest püsiv marsruut pluss profiilimarsruut sama prefiksi jaoks tekitavad duplikaate, mida on lammutamisel valus lahti harutada. Mida iganes valite, omandus peaks olema nähtav piletil, mitte ainult masinas.

Omandus on küsimus, millele see jaotis vastab, mitte süntaks. Kaks omanikku ühe prefiksi jaoks on tõrkemuster, mida tasub vältida.

Kontrollige sihtkohaga, mitte veebisaidiga

Testige sihtkohta, mis peab tunnelist läbi minema, mitte veebisaiti, mis teatab väljumisaadressi. Find-NetRoute tagastab valitud marsruudi ja lähteaadressi, nii et näete, kas võitis kontoriprefiks või füüsiline vaikemarsruut, ja seejärel avate jagatud ressursi ise.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Väljumisaadressi veebisait on nõrk kontroll, sest DNS, IPv6 ja brauseri puhverserver võivad selle päringu igaüks erinevat teed pidi saata. IPv4-l ja IPv6-l on samas dialoogis ka eraldi seaded ning ühe ruudu tühjendamine jätab teise perekonna puutumata, nii et kahe virna masin võib kanda IPv6 tunnelist läbi, samal ajal kui IPv4 järgib jagatud marsruuti. Kontrollige mõlemat perekonda enne, kui nimetate profiili jagatuks. Kui marsruut on õige ja teenus ikka ei tööta, on järelejäänud kiht filtreerimine, mitte marsruutimine.

Kliendihallatav tulemüür võib kontori alamvõrgu blokeerida ka täiusliku marsruuditabeli korral. See poliitika kuulub sellele, kes profiili levitas, mitte sellele, kes marsruute muudab.