Jou ou standaardroete oorleef OpenVPN doelbewus
Twee /1-roetes staan bo die standaard sonder om dit te vervang. Kyk watter roete ’n bestemming werklik volg, en laat dan die ou gateway staan.
Jy maak die tonnel oop, hardloop ip route, en die oorspronklike standaardgateway staan steeds daar. Die volgende gedagte is dat die kliënt nie die roete oorgeneem het nie, so jy verwyder die standaard met die hand en verloor heeltemal die konnektiwiteit. Daardie inskrywing is veronderstel om te bly. Met redirect-gateway def1 installeer OpenVPN twee meer spesifieke roetes wat bo die gewone standaard staan in plaas van om dit te vervang. Die ou gateway bly en hou op om die verkeer te dra wat jy getoets het.
Wat def1 werklik doen
Die vlag voeg 0.0.0.0/1 en 128.0.0.0/1 by, albei na die tonnel. 0.0.0.0/1 neem elke adres waarvan die eerste okteet 0 tot 127 is, en 128.0.0.0/1 neem 128 tot 255, so elke IPv4-bestemming het ’n passing wat meer spesifiek is as die ou standaard. Voorvoegsellengte, nie metrieke waarde nie, bepaal watter roete wen.
Om die oorspronklike standaard te laat staan, is doelbewus. Die kliënt hoef nie te onthou wat hy vervang het nie, en hy herskryf nie die roete wat sy eie verbinding na die VPN-bediener dra nie. By ontkoppeling verwyder dit die twee halfroetes en die tabel keer terug na wat dit was.
Waarom /1 en nie /0 nie
Roetering kies die langste passende voorvoegsel, nie die laagste metrieke waarde nie, so ’n /1 klop ’n /0 ongeag wat die standaard se metrieke waarde sê. Albei helftes bestaan omdat een /1 net die helfte van die ruimte dek; met net 0.0.0.0/1 teenwoordig, volg alles van 128.0.0.0 opwaarts steeds die ou standaard, wat die verwarrende simptoom gee waar sommige werwe werk en ander nie.
Om die ou standaard se metrieke waarde te verhoog of te verlaag, verander niks, en ’n standaard met ’n laer metrieke waarde op ’n ander koppelvlak steel ook nie die verkeer nie. Voorvoegsellengte besluit eerste, en net gelyke voorvoegsels val terug op metrieke waarde.
Lees ’n werklike roetertabel
’n Gekoppelde gasheer kan al drie inskrywings gelyk wys, met die tonnel wat die helftes dra en die oorspronklike gateway wat steeds gelys word. Die adresse is voorbeelde eerder as ’n konfigurasie om te kopieer, want koppelvlakname, tonneltopologie en ekstra roetes verskil per platform en kliënt.
default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0Wat saak maak, is die verhouding: twee spesifieke helftes bo een algemene standaard. Die ou gateway-lyn bly omdat niks dit vervang het nie.
Kyk watter roete die pakkie werklik volg
Meer spesifieke roetes kan steeds wen: ’n roete vir ’n private reeks, ’n plaaslike subnet of die VPN-bediener se eie adres is langer as ’n /1. Die tonnel het ’n buitenste pad na sy bediener nodig, en om daardie verbinding terug in die tonnel te stuur, sou dit dadelik breek. Op Linux vra jy die kern eerder as om die tabel met die oog te lees: ip route get met die bestemming wat jou interesseer, druk die gekose roete, koppelvlak en bron. As beleidsroetering opgestel is, inspekteer ook die reëls, want ’n reël kan ’n ander tabel kies voordat die hoof een geraadpleeg word.
As net ’n deel van IPv4 verkeerd optree, bevestig dat albei helftes geïnstalleer is en soek dan na ’n uitsondering wat by die falende bestemming pas. Om die ou standaard te verwyder, is nie ’n oplossing nie, en dit verwyder die roete wat die kliënt nodig het om die tonnel skoon af te breek.
Wat def1 nie dek nie
Twee IPv4-inskrywings sê niks oor IPv6 nie: ’n gasheer met IPv6-konnektiwiteit bly sy eie standaard gebruik totdat iets daardie familie afsonderlik herlei, en daarom lyk dit of sommige verkeer die tonnel op ’n dubbelstapel-netwerk omseil. Ander kliënte en netwerkbestuurders implementeer voltonnelroetering anders, en hul tabelle sal nie ooreenstem nie. Die def1-gedrag wat hier beskryf word, hoort by OpenVPN se gedokumenteerde vlag, nie by elke VPN op die masjien nie.
’n Doodskakelaar beantwoord ’n ander vraag: wat die masjien doen wanneer die tonnel val. Roeteprioriteit bepaal waar verkeer heen gaan terwyl die tonnel op is; dit bepaal nie wat ’n firewall daarna doen nie. Orde van werk: lees die tabel, bevestig dat albei helftes bestaan, hardloop ip route get vir die falende bestemming, kyk na beleidsreëls en kyk dan afsonderlik na IPv6. Laat die ou standaard waar dit is.