Gee LAN-gashere 'n VPN-terugroete met DHCP-opsie 121
'n Gedeelde LAN kan die roete na jou VPN-kliëntpoel uit DHCP leer. Kodeer dit met opsie 121 en hou die verstekroete in dieselfde lys.
Afgeleë VPN-kliënte verbind, die LAN-bediener antwoord, en die antwoord verlaat die netwerk deur die gewone internetroeteerder en sterf daar. Een bediener kan met 'n statiese roete reggemaak word, maar 'n hele subnet daarvan word beter hanteer waar hulle reeds hul netwerkkonfigurasie kry. DHCPv4-opsie 121 versprei presies daardie soort bestemmingsroete, en dit is die deel wat mense gewoonlik verkeerd kry sodra hulle die verstek vergeet. Die simptoom is eenrigtingverkeer: versoeke kom aan en antwoorde verdwyn.
Noem eers die drie adresse
Neem 'n konkrete LAN: 192.168.50.0/24 met die gewone verstekroeteerder by 192.168.50.1 en 'n aparte VPN-gateway by 192.168.50.2. Gemagtigde afgeleë kliënte beset 10.90.0.0/24.
Die roete wat elke deelnemende gasheer nodig het, is 10.90.0.0/24 via 192.168.50.2. Die bestemming is die kliëntpoel, en die volgende sprong is die gateway se LAN-adres eerder as sy tonneladres.
Kodeer dit as 'n klasselose statiese roete
Opsie 121 dra voorvoegsel- en volgende-sprong-pare, en RFC 3442 definieer beide die enkodering en die kliëntgedrag wat daarop volg. Vir 'n bestaande dnsmasq-instansie wat net hierdie illustratiewe LAN bedien, is die konfigurasievorm:
dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1
Dit is 'n fragment, nie 'n nuwe DHCP-diens nie. Op 'n bediener wat verskeie segmente hanteer, beperk die opsie met die etikette of netwerkbeleid wat jy reeds gebruik. Hou die vorige konfigurasie byderhand, want om dit terug te rol beteken nog 'n huurhernuwing, nie 'n herbegin nie.
Moenie die verstekroete verloor nie
Dit is die lokval. 'n Kliënt wat opsie 121 ontvang, moet die gewone Router-opsie ignoreer, so om net die VPN-poelroete te adverteer kan die gasheer heeltemal sonder 'n verstekroete laat. Die masjien lyk steeds opgestel en verloor stilweg die internet. Gebruikers beskryf dit as dat die netwerk af is terwyl elke koppelvlak op is.
Sluit die beoogde verstek in dieselfde lys in, soos die fragment hierbo doen. Hou ook die gewone Router-opsie in plek, vir kliënte wat nie klasselose roetes implementeer nie; die bediener se eie opsiehanteering besluit wat aan wie gestuur word.
Kyk wat die kliënt sal aanvaar
'n Gasheer met 'n handmatige adres tel dit nooit op nie, want hy vra nie vir 'n huur nie. Kliëntondersteuning wissel ook, so toets op die bedryfstelsel wat jy werklik gebruik eerder as om te aanvaar elke toestel eerbiedig opsie 121. Bevestig by wie ook al daardie bedieners besit watter daarvan staties geadresseer is. Daardie gashere het hul eie roete-inskrywings nodig of hulle sal eenvoudig nie deelneem nie.
Bestuurde DHCP-dienste is nog 'n beperking. Sommige wolknetwerke laat administrateurs nie arbitrêre opsies publiseer nie, en 'n mededingende DHCP-bediener op dieselfde segment is erger as geen opsie nie.
Verifieer die huur, dan die opsoek
Laat die DHCP-eienaar die verandering toepas en hernu dan die huur op 'n kliënt. Bestaande hure hou die ou konfigurasie totdat hulle hernu word, so onmiddellike resultate is nie gewaarborg nie.
Op 'n Linux-kliënt, lees die werklike roetes en bevestig albei inskrywings:
ip -4 route
ip -4 route get 10.90.0.23
Die kontekstuele opsoek behoort die poelroete deur 192.168.50.2 en die verstek deur 192.168.50.1 te wys. As die verstek ontbreek, het jy die lokval hierbo gereproduseer.
Toets dan die werklike uitruiling
Roeteverspreiding is nie die hele pad nie. Die aparte gateway het steeds aanstuur, eienaarskap van afgeleë eweknieë en 'n toegangsbeleid nodig wat die bediener toelaat, en DHCP verifieer niemand nie.
Laastens, hou 'n verwyderingsplan. 'n Geleerde statiese roete trek homself nie terug wanneer die VPN afgaan nie, so 'n verouderde volgende sprong kan daardie voorvoegsel lank nadat die tonnel weg is in 'n swartgat laat beland.