Twa Windows-VPN’s tagelyk: hokker profyl hâldt de standertrûte?

Slút de twadde tunnel oan en de earste wurdt stil, wylst beide klanten noch altyd in sûne ferbining melde. Windows hat mar ien standertrûte om te jaan, en elk profyl dat dêrop oanspraak makket, nimt dy fan it oare ôf. It symptoom liket in VPN-steuring, mar it is in rûtestriid tusken twa profylen. Beslis hokker tunnel dy rûte besitte moat, en de rest fan ’e konfiguraasje folget.

Mar ien ynfier kin de bêste standert wêze

De IPv4-rûtetabel hâldt ien winende rûte foar bestimmingen sûnder in mear spesifike oerienkomst. In VPN-profyl dat syn eigen ynstallearret, ferfangt de foarige sadree’t it ferbynt, en ferkear dat earst de earste tunnel yn gie, giet no troch de twadde derút. De earste tunnel bliuwt oan; wat ferdwynt, is elk pakket dat him foar algemiene bestimmingen brûkt hawwe soe.

Klantstatuspiktogrammen kinne dat net sjen litte. Se melde dat in tunnel oanlein is, net hokker prefiksen dêr noch hinne rûte wurde, sadat de brûker twa griene piktogrammen en in tiidferstriken yn in applikaasje sjocht. It lêzen fan route print -4 by de steuring is ynformativear as hokker VPN-log dan ek.

Nammebesolving is in twadde, selsstannich konflikt, en allinnich de rûtetabel reparearje sil dat net oplosse.

Wat it fakje ynstallearret, en wat it fuorthellet

De opsje sit yn ’e eigenskappen fan ’e adapter fan elk VPN-profyl ûnder de útwreide IPv4-ynstellingen, ferwurde as it brûken fan de standertgateway op it fiere netwurk. Ynskeakele foeget elke ferbining in standertrûte troch de tunnel ta en set dy interface yn ’e rige foar algemien ferkear. Utskeakele hâldt Windows de rûte foar it eigen subnet fan ’e tunnel en lit de rest fan ’e tabel gewurde.

It is by it ôffinkjen fan it fakje dat de measte minsken fêst komme te sitten. It fiere plak hat ornaris mear as ien prefiks, en gjin fan dy prefiksen sit yn it subnet fan ’e adapter, sadat triemtsjinners en beheardadressen ophâlde mei antwurdzjen. It fakje hat de tunnel net brutsen; it helle de brede rûte fuort dy’t alles dekte.

Mingde konfiguraasjes binne legitime en gewoan: in bedriuwsprofyl hâldt it fakje as folsleine tunnel, wylst in laboratoariumprofyl splitst is sadat it de bedriuwsstandert net ferkringe kin.

Kies neffens wat elke tunnel drage moat

Trije fragen beslisse de opstelling. Moat dizze tunnel gewoan ynternetferkear drage, of allinnich adressen binnen syn eigen plak? Brûke de twa plakken losse privee-berikken? En as it profyl troch in wurkjouwer beheard wurdt, meie jo dan wol syn rûtegedrach feroarje?

As ien tunnel fol wêze moat, besit dy de standert en moat de oare splitst wêze. As gjin fan beide algemien ynternetferkear nedich hat, helje it fakje dan by beide fuort en lit de fysike adapter de standert hâlde. As de berikken oerlaapje, stopje: 172.22.0.0/16 kin net ien masine oan ’e bedriuwskaat en in oare oan ’e laboratoariumkaat betsjutte, en gjin fakje lost dat op.

Skriuw de beslissing njonken de profylnammen. Oars sil in tredde VPN dy’t folgjend fearnsjier tafoege wurdt, it ûndersyk fan it begjin ôf werhelje.

Foegje de ûntbrekkende prefiksen ta en test it resultaat

Foegje foar elke splitste tunnel de fiere berikken eksplisyt ta, mei it peersadres dat op dy adapter sjen litten wurdt ynstee fan it iepenbiere serveradres:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

In PPP-adapter brûkt syn peersadres as folgjende sprong, wylst in TAP-adapter ornaris de gateway brûkt dy’t op dy interface sjen litten wurdt, dus lês de adapterdetails ynstee fan in getal út in hânlieding te kopiearjen. Foegje it permaninte flagge pas ta neidat de rûte him as korrekt bewiisd hat, en wiskje âlde permaninte ynfieren foar’t jo ferfangende tafoegje. Behearde klanten kinne har eigen rûtes ynstallearje en beskermje, yn hokker gefal de eigner fan it profyl de feroaring dwaan moat.

DNS hat in aparte gong nedich. Beide tunnels kinne resolvers trochdrukke, en Windows hâldt in list per interface mei in foarkarsfolchoarder, sadat in namme fan it twadde netwurk nei de resolver fan it earste netwurk stjoerd wurde kin. Sjoch wat elke adapter wier krigen hat foar’t jo in oplossing kieze:

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

In belied foar nammebesolving per domein is ornaris better as it ferfangen fan ’e globale resolverlist, om’t dy list troch elke applikaasje op ’e masine dield wurdt en it stil feroarjen derfan net-relatearre syktochten ferpleatst.

Akseptearje de opstelling mei fjouwer kontrôles: ien boarne yn elk fier netwurk berikber op adres, in nammesykjen yn elk, de ynternetstandert dy’t noch altyd nei de fysike adapter wiist, en in fiere buroblêdsesje dy’t it opkommen fan ’e twadde ferbining oerlibbet.