Reëls vir VPN op die roeteerder: pas die bron en die bestemming by mekaar
'n Reël vir VPN op die roeteerder het twee kante: die toestel wat verkeer stuur en die bestemming wat die tonnel moet gebruik. Besluit eers oor die snypunt en die terugval.
Winkelbladsye vir roeteerders noem VPN-roetering as een merkblokkie, en dié frase verberg drie verskillende vrae. Pas die reël by die toestel wat die verkeer stuur, by die bediener wat dit ontvang, of by albei? Wat gebeur met verkeer wat by nie een pas nie? En wanneer twee reëls oorvleuel, watter een wen? As jy die antwoord as 'n paar van bron en bestemming neerskryf, word 'n vae kenmerklys 'n toetsbare ontwerp.
Die kenmerknaam verberg twee eindpunte
'n Mediaspeler wat die tonnel moet gebruik, is 'n bron-passing. 'n Private kantoorprefix wat deur die tonnel bereikbaar moet wees, is 'n bestemming-passing. 'n Werkstasie wat die tonnel slegs vir een diens moet gebruik, is albei, en daardie snypunt is die geval wat die meeste verbruiker-fermware sleg hanteer.
Skryf die vereiste as 'n paar neer voordat jy produkte vergelyk. Die paar is wat jy later sal toets.
'n Produk met 'n toestellys of 'n globale bestemmingslys kan dalk nie «net hierdie toestel, net hierdie bestemmings» uitdruk nie. Die gaping is nie kosmeties nie: 'n globale bestemmingsreël stuur elke toestel se verkeer vir daardie werf deur die tonnel, en 'n toestelreël stuur al daardie toestel se verkeer. Nie een is die vereiste nie. Toets daardie geval met twee toestelle voordat jy die skerm vertrou.
Bou die reël as 'n snypunt
'n Tabel hou die ontwerp eerlik. Sit die scenario links, en noem dan die sender-passing en die teiken-passing afsonderlik:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
Die derde ry is die interessante een, want dit het albei helftes gelyk nodig. As die fermware net een as kan uitdruk, moet die vereiste in twee reëls gesplit of na 'n toestel geskuif word wat dit kan.
Hou die bron-identiteit stabiel. 'n DHCP-reservering, 'n toegewyde segment of 'n toestel-identiteitsmeganisme werk almal, maar 'n adres wat ná die verstryking van 'n lease verander, werk nie. Sluit IPv6 in, want een IPv4-adres identifiseer nie al 'n toestel se verkeer nie.
Prioriteit beslis die oorvleueling
Oorvleuelende reëls is normaal. 'n Breë toestelreël en 'n smal bestemmingsreël kan albei een stroom beskryf, en die gedokumenteerde prioriteitsorde beslis watter een wen. 'n Aantreklike instellingskerm vertel jou nie daardie orde nie.
Lees die handleiding vir die ordening en vir die geval sonder passing, en toets dan albei met verkeer wat jy kan waarneem:
ip rule show
ip route get 203.0.113.10As die dokumentasie nie die orde noem nie, aanvaar dat die smaller reël dalk nie wen nie en ontwerp daarom. Twee reëls wat nie kan bots nie, is makliker om te ondersteun as een slim reël met 'n ongedokumenteerde voorrang.
Domeinname het 'n opdateringsbeleid nodig
'n Bestemming wat as 'n domein geskryf word, voeg 'n onderhoudsprobleem by. Die roeteerder moet dit oplos, die kartering opdateer, veelvuldige adresse en subdomeine hanteer, en toepassing-DNS die hoof bied wat die verwagte oplosser omseil.
Om een opsoekresultaat in 'n IP-reël te kopieer, is 'n momentopname, nie 'n domeinbeleid nie.
Besluit hoe verouderd 'n antwoord mag wees voordat die reël verkeerd is, en wat die roeteerder doen wanneer oplossing misluk. 'n Reël wat die laas bekende adres hou, kan 'n diensmigrasie oorleef; 'n reël wat die inskrywing laat val, kan stilweg ophou tonnel. Enige van die twee gedrag is aanvaarbaar as dit langs die reël neergeskryf is.
Bepaal die onbeskikbare toestand
'n Roetevoorkeur dwing nie verkeer wat net deur die VPN mag gaan, af nie. Wanneer die tonnel af is, kan die roeteerder die stroom blokkeer, dit reguit stuur of 'n ander tonnel gebruik, en elke keuse het 'n ander foutprofiel.
Besluit watter een die vereiste nodig het, en verifieer dit dan deur die tonnel te stop en die stroom dop te hou:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10Verkeer wat by die roeteerder self ontstaan, is 'n aparte omvang. DNS-aanstuur, opdateringskontroles en monitering kan nuwe strome by die roeteerder self begin eerder as om die toestel se bron-passing te erf. Reken eksplisiet met daardie strome, anders verskyn hulle as onverklaarde lekke in die logboeke.