Oferiți gazdelor din LAN o rută de întoarcere VPN cu opțiunea 121 DHCP

Clienții VPN la distanță se conectează, serverul LAN răspunde, iar răspunsul iese prin routerul obișnuit de internet și moare acolo. Un server poate fi reparat cu o rută statică, dar un întreg subnet din ele este mai bine tratat acolo unde primesc deja configurația de rețea. Opțiunea 121 din DHCPv4 distribuie exact acest tip de rută de destinație, și este partea pe care oamenii o greșesc de obicei în momentul în care uită ruta implicită. Simptomul este trafic într-o singură direcție: cererile ajung și răspunsurile dispar.

Numiți mai întâi cele trei adrese

Luați un LAN concret: 192.168.50.0/24 cu routerul implicit obișnuit la 192.168.50.1 și un gateway VPN separat la 192.168.50.2. Clienții la distanță autentificați ocupă 10.90.0.0/24.

Ruta de care are nevoie fiecare gazdă participantă este 10.90.0.0/24 via 192.168.50.2. Destinația este pool-ul de clienți, iar următorul salt este adresa LAN a gateway-ului, nu adresa lui de tunel.

Codificați-o ca rută statică fără clase

Opțiunea 121 transportă perechi de prefix și următorul salt, iar RFC 3442 definește atât codificarea, cât și comportamentul clientului care decurge din ea. Pentru o instanță dnsmasq existentă care deservește doar acest LAN ilustrativ, forma configurației este:

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

Acesta este un fragment, nu un serviciu DHCP nou. Pe un server care deservește mai multe segmente, limitați opțiunea cu etichetele sau politica de rețea pe care le folosiți deja. Țineți configurația anterioară la îndemână, pentru că revenirea înseamnă o altă reînnoire a bailului, nu o repornire.

Nu pierdeți ruta implicită

Aceasta este capcana. Un client care primește opțiunea 121 trebuie să ignore opțiunea Router obișnuită, așa că anunțarea doar a rutei pool-ului VPN poate lăsa acea gazdă complet fără rută implicită. Mașina încă pare configurată și pierde în tăcere internetul. Utilizatorii descriu asta ca rețeaua căzută în timp ce toate interfețele sunt active.

Includeți ruta implicită dorită în aceeași listă, așa cum face fragmentul de mai sus. Păstrați și opțiunea Router obișnuită pentru clienții care nu implementează rute fără clase; procesarea opțiunilor de către server decide ce se trimite cui.

Verificați ce va accepta clientul

O gazdă cu adresă setată manual nu prinde niciodată asta, pentru că nu cere un bail. Suportul clienților variază și el, așa că testați pe sistemul de operare pe care îl rulați cu adevărat în loc să presupuneți că fiecare dispozitiv respectă opțiunea 121. Confirmați cu proprietarii acelor servere care dintre ele au adresă statică. Acele gazde au nevoie de propriile intrări de rută, altfel pur și simplu nu vor participa.

Serviciile DHCP gestionate sunt o altă limită. Unele rețele cloud nu le permit administratorilor să publice opțiuni arbitrare, iar un server DHCP concurent în același segment este mai rău decât nicio opțiune.

Verificați bailul, apoi căutarea

Rugați proprietarul DHCP să aplice schimbarea, apoi reînnoiți bailul pe un client. Bailurile existente păstrează configurația veche până la reînnoire, așa că rezultatele imediate nu sunt garantate.

Pe un client Linux, citiți rutele reale și confirmați ambele intrări:

ip -4 route
ip -4 route get 10.90.0.23

Căutarea contextuală ar trebui să arate ruta pool-ului prin 192.168.50.2 și ruta implicită prin 192.168.50.1. Dacă ruta implicită lipsește, ați reprodus capcana de mai sus.

Apoi testați schimbul real

Distribuirea rutelor nu este tot drumul. Gateway-ul separat are încă nevoie de forwarding, de proprietatea asupra partenerilor la distanță și de o politică de acces care permite serverul, iar DHCP nu autentifică pe nimeni.

În final, păstrați un plan de eliminare. O rută statică învățată nu se retrage singură când VPN-ul cade, așa că un următor salt învechit poate transforma acel prefix într-o gaură neagră mult după ce tunelul a dispărut.