Twee VPN-kliënte gelyktydig: wie wen die verstekroete?

Om twee VPN-kliënte gelyktydig te laat loop, is 'n debat oor roetes, nie 'n privaatheidinstelling nie. Watter tonnel ook al die meer spesifieke roete besit, ontvang die verkeer, en die ander een bly verbind maar ledig. Die korporatiewe poort sien dan 'n verbinding wat van die persoonlike uitgang af kom, terwyl die korporatiewe kliënt op jou masjien steeds elke adapter sien. Om te besluit watter van dié twee feite saak maak, is die hele oefening.

Die roetetabel kies een wenner

Neem die tabel vas voor en nadat die korporatiewe kliënt begin het, en lees die koppelvlakkolom eerder as net die bestemming. 'n Gewone verstekroete vanaf die buitenste tonnel is maklik om te verdring, want 'n /1-paar is meer spesifiek as /0. Die letterlike paar 0.0.0.0/1 en 128.0.0.0/1 dek die hele IPv4-ruimte in twee helftes en klop enige enkele verstek. Sodra dit ingestel is, wys die buitenste tonnel steeds verbind en dra niks.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

Beleidsroetering kan die hooftabel heeltemal oorheers, so lees die reëls sowel as die roetes. 'n Reël wat gemerkte verkeer na 'n ander tabel stuur, wen voordat die hooftabel geraadpleeg word. Dis hoe een toepassing op die fisiese skakel kan bly terwyl alles anders die tonnel gebruik.

ip rule show

Windows beslis dit met metrieke waardes

Op Windows is die wenner die roete met die laagste metrieke waarde vir die bestemming, en twee kliënte kan albei 'n verstekroete met verskillende metrieke installeer. Lees die tabel en die koppelvlakkonfigurasie saam, want die adapter met die laer metrieke waarde is nie altyd die een wat jy verwag nie. 'n Kliënt wat ook 'n koppelvlakmetriek stel, kan die verstek verskuif sonder om 'n enkele roete by te voeg. Die adapter wat verloor, bly op en ontvang eenvoudig niks.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Vergelyk die twee uitsette en noem die koppelvlak wat 0.0.0.0/0 besit. As albei kliënte dit opeis, besluit die metrieke waarde, en daarom kan 'n toets van die verbindingsorde op verskillende masjiene inkonsekwent lyk. As nie een van die uitsette 'n verstekpoort wys nie, loop die kliënt nie voltonnel nie en het die kettingargument geen waarde nie.

Twee waarnemers, twee verskillende menings

Die afgeleë poort sien een verbinding wat van die buitenste uitgang af kom, plus alles wat die kliënt in sy tonnel deurstuur. Die plaaslike kliënt sien adapters, roetes en die bestaan van 'n ander tonnel, want hy loop met die regte om dit te skep. Om daardie menings te skei is die punt; om te beweer die kliënt kan niks opmerk nie, is dit nie.

Aanvaar dat die kliënt kan opsom net wat hy wil, en beplan eerder vir die poort se siening. 'n Ontwerp wat daarvan afhang dat die kliënt blind bly, is een opdatering weg van breek.

DNS en IPv6 is waar die ketting lek

DNS volg watter oplosserinstelling ook al wen, en dit is nie noodwendig die pad wat die pakkette volg nie. 'n Korporatiewe oplosser wat deur die korporatiewe tonnel bereik word, stem met die ontwerp ooreen; 'n plaaslike oplosser wat daarbuite bereik word, nie, en dit onthul name wat die tonnel moes wegsteek. IPv6 is die tweede lek: 'n dubbelstapel-gasheer hou aan om IPv6 te gebruik na bestemmings wat die tonnel net oor IPv4 dra. Kontroleer die families afsonderlik, want 'n slegs-IPv4-tonnel sê niks oor IPv6-roetes of -oplossers nie.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Maak die oplosser en die IPv6-roete doelbewus reg in plaas daarvan om 'n tweede tonnel bo-op te stapel. Dubbele inkapseling kos ook MTU, so 'n kleiner binneste MTU is die eerste ding om te probeer wanneer bladsye vasval nadat die ketting opgekom het. 'n Oplosser wat vinnig antwoord, is nie bewys dat dit die regte oplosser is nie.