Donu al LAN-gastigantoj VPN-revenan itineron per DHCP-opcio 121

Foraj VPN-klientoj konektiĝas, la LAN-servilo respondas, kaj la respondo eliras tra la ordinara interreta enkursigilo kaj mortas tie. Unu servilo povas esti riparita per statika itinero, sed tuta subreto da ili estas pli bone traktata tie, kie ili jam ricevas sian retan agordon. DHCPv4-opcio 121 disdonas ĝuste tiajn celitinerojn, kaj ĝi estas la parto, kiun homoj kutime fuŝas tuj kiam ili forgesas la defaŭlton. La simptomo estas unudirekta trafiko: petoj alvenas kaj respondoj malaperas.

Unue nomu la tri adresojn

Prenu konkretan LAN: 192.168.50.0/24 kun la normala defaŭlta enkursigilo ĉe 192.168.50.1 kaj aparta VPN-pordego ĉe 192.168.50.2. Aŭtentigitaj foraj klientoj okupas 10.90.0.0/24.

La itinero, kiun bezonas ĉiu partoprenanta gastiganto, estas 10.90.0.0/24 via 192.168.50.2. La celo estas la klienta provizo, kaj la sekva salto estas la LAN-adreso de la pordego, ne ĝia tunela adreso.

Kodigu ĝin kiel senklasan statikan itineron

Opcio 121 portas parojn de prefikso kaj sekva salto, kaj RFC 3442 difinas kaj la kodadon kaj la klientan konduton, kiu sekvas. Por ekzistanta dnsmasq-instalaĵo, kiu servas nur ĉi tiun ilustran LAN, la formo de la agordo estas:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Tio estas fragmento, ne nova DHCP-servo. Sur servilo traktanta plurajn segmentojn, limigu la opcion per la etikedoj aŭ reta politiko, kiujn vi jam uzas. Tenu la antaŭan agordon proksime, ĉar malfari tion signifas alian luadrenovigon, ne restarigon.

Ne perdu la defaŭltan itineron

Jen la kaptilo. Kliento, kiu ricevas opcion 121, devas ignori la ordinaran Router-opcion, do anonci nur la itineron de la VPN-provizo povas lasi tiun gastiganton tute sen defaŭlta itinero. La maŝino ankoraŭ aspektas agordita kaj silente perdas la interreton. Uzantoj priskribas tion kiel reton malsupren, dum ĉiu interfaco estas supre.

Inkluzivu la celatan defaŭlton en la sama listo, kiel faras la fragmento supre. Tenu ankaŭ la ordinaran Router-opcion, por klientoj, kiuj ne efektivigas senklasajn itinerojn; la propra opciotraktado de la servilo decidas, kio iras al kiu.

Kontrolu, kion la kliento akceptos

Gastiganto kun permane atribuita adreso neniam kaptas tion, ĉar ĝi ne petas luon. Klienta subteno ankaŭ varias, do testu sur la operaciumo, kiun vi efektive uzas, anstataŭ supozi, ke ĉiu aparato respektas opcion 121. Konfirmu kun tiuj, kiuj posedas tiujn servilojn, kiuj estas statike adresitaj. Tiuj gastigantoj bezonas proprajn itinerojn, alie ili simple ne partoprenos.

Administrataj DHCP-servoj estas alia limo. Kelkaj nubaj retoj ne lasas administrantojn publikigi arbitrajn opciojn, kaj konkurenca DHCP-servilo en la sama segmento estas pli malbona ol neniu opcio entute.

Kontrolu la luon, poste la serĉon

Petu la DHCP-posedanton apliki la ŝanĝon, poste renovigu la luon sur kliento. Ekzistantaj luoj tenas la malnovan agordon ĝis ili renoviĝos, do tujaj rezultoj ne estas garantiitaj.

Sur Linux-kliento, legu la faktajn itinerojn kaj konfirmu ambaŭ rikordojn:

ip -4 route
ip -4 route get 10.90.0.23

La kunteksta serĉo devus montri la itineron de la provizo tra 192.168.50.2 kaj la defaŭlton tra 192.168.50.1. Se la defaŭlto mankas, vi reproduktis la kaptilon supre.

Poste testu la realan interŝanĝon

Itinera disdono ne estas la tuta vojo. La aparta pordego ankoraŭ bezonas plusendadon, posedon de foraj samtavoloj kaj alirpolitikon, kiu permesas la servilon, kaj DHCP aŭtentigas neniun.

Fine, tenu forigplanon. Lernita statika itinero ne retiriĝas mem, kiam la VPN falas, do kaduka sekva salto povas igi tiun prefikson nigra truo longe post kiam la tunelo malaperis.