VPN și LAN-ul de acasă în același subrețea: urmează întâi ruta
Ambele adaptoare revendică 192.168.1.0/24 și doar o rută câștigă. Urmează lista de adaptoare, ruta câștigătoare și drumul de întoarcere înainte de a renumerota sau de a da vina pe DNS.
Te conectezi la VPN-ul biroului, pictograma din tavă devine verde, intranetul se încarcă, iar imprimanta de la doi metri încetează să răspundă. Partajarea care funcționa dimineață expiră pe același calculator, și niciun jurnal nu menționează o imprimantă. Reflexul este DNS, pentru că un nume care nu se rezolvă arată ca un nume care nu există, dar problema este adresa: două adaptoare revendică acum 192.168.1.0/24 și doar o rută poate câștiga acel prefix. Parcurge-o în această ordine și vei vedea ce adaptor l-a luat înainte să schimbi ceva.
Începe cu simptomul, nu cu tunelul
Indiciul este amploarea. Dacă intranetul funcționează și fiecare dispozitiv local eșuează, tunelul este sănătos și calea locală nu. Dacă dispozitivele locale funcționează și intranetul eșuează, invers. Dacă totul funcționează în afară de un host, te uiți la o singură adresă care există pe ambele părți.
Notează o adresă locală și una la distanță înainte să atingi o setare. „Imprimanta” nu poate fi testată; 192.168.1.40 poate. Acel singur pas previne cea mai obișnuită oră pierdută la această problemă, adică rescrierea setărilor DNS pentru o decizie de rutare.
Pasul 1: vezi ambele adaptoare revendicând prefixul
Deschide Conexiuni de rețea (ncpa.cpl) și citește cele două adaptoare unul lângă altul. Adaptorul Ethernet arată 192.168.1.50/24 cu poartă 192.168.1.1. Adaptorul VPN arată 192.168.1.201/24, trimis de server. Ambele sunt legitime, ambele cred că prefixul este on-link, iar stiva va păstra o singură rută pentru el.
Get-NetIPAddress -AddressFamily IPv4 listează adresele, iar Get-NetIPInterface | Sort-Object InterfaceMetric arată ordinea în care stiva le va folosi. Acea coloană de metrică este decizia pe care urmează să o citești, așa că notează numerele în loc să încerci să le ții minte.
Infirmă ieftin teoria DNS: Resolve-DnsName printer.office.lan returnează aceeași adresă ca ieri. Numele s-a rezolvat; apoi pachetul a ieșit prin adaptorul greșit. Două minute aici economisesc o după-amiază în setările resolverului.
Pasul 2: citește ruta care a câștigat de fapt
Find-NetRoute -RemoteIPAddress 192.168.1.40 tipărește interfața, următorul salt și sursa pe care stiva le-ar folosi pentru acea adresă. Tratează această ieșire ca răspunsul, nu ca indiciu. route print -4 dă tot tabelul când vrei să vezi ce intrare a pierdut și cu cât.
Specificitatea învinge intenția. Un 192.168.0.0/25 trimis învinge un 192.168.0.0/24 local pentru că prefixul este mai lung, deci 192.168.0.0 până la 192.168.0.127 ies prin tunel, iar jumătatea superioară rămâne locală. Disparția unei jumătăți de LAN fără mesaj de eroare este comportamentul corect pentru acel tabel.
tracert -d 192.168.1.40 confirmă asta din afara tabelului: dacă primul salt este o adresă de tunel în locul routerului tău, ruta este toată povestea. Pe Linux aceeași întrebare este ip route get 192.168.1.40, care tipărește adresa sursă și dispozitivul pe o linie. Când răspunsul numește tun0, oprește-te din privit browserul.
Pasul 3: verifică întoarcerea înainte de a da vina pe client
O rută corectă înainte eșuează totuși dacă partea îndepărtată nu poate răspunde. Când se ajunge la LAN-ul unui client prin tunel, poarta acelui LAN trebuie să știe unde locuiește pool-ul tunelului: ip route add 10.8.0.0/24 via 192.168.1.12 pe acel router, și push „route 192.168.1.0 255.255.255.0” de la server ca să știe clienții drumul de întoarcere.
Fără prima intrare, răspunsul părăsește ținta spre poarta sa implicită, care transmite o adresă privată furnizorului și o aruncă. Simptomul este unidirecțional și ușor de citit greșit: cererile apar pe tun0, răspunsurile niciodată.
O regulă masquerade pe hostul VPN elimină nevoia acelei rute statice: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Ascunde și adresele sursă reale, ceea ce face fiecare întrebare ulterioară despre jurnale mai dificilă. Un host țintă cu poarta implicită greșită produce aceeași tăcere, cu o redirecționare ICMP în cel mai bun caz și o gaură neagră în cazul normal, motiv pentru care captura aparține ambelor capete.
Pasul 4: alege o reparație cu care poți trăi
Se folosesc cinci reparații pentru asta, și ele nu sunt interschimbabile. Alege după ce trebuie să rămână accesibil în același timp, nu după care comandă este mai scurtă.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Metricile sunt opțiunea ieftină și cea la care lumea recurge prima. Schimbarea se aplică interfeței, deci funcționează cât timp tunelul este sus, și își are locul într-un script lângă client, nu într-un shell pe care îl vei uita. Nu poate oferi acces simultan la aceeași adresă în două rețele, și exact această limită trimite toți ceilalți în josul tabelului.
Renumerotarea LAN-ului de acasă în 10.10.0.0/24 este soluția curată: o reînnoire a bailului DHCP plus rezervările, cozile de imprimare și adresele codificate care menționează intervalul vechi. Renumerotarea părții biroului nu este de obicei decizia ta. IPv6 elimină complet coliziunea când ambele rețele îl suportă, folosind un prefix local unic din fd00::/8 în loc de ceva memorabil, dar testează aplicația prin TCP, nu cu ping, pentru că ICMP poate funcționa în timp ce serviciul nu.
Opțiunea de traducere proprie a OpenVPN este ultima soluție, trimisă de la server într-o intrare de director specifică clientului. Ia patru parametri după numele opțiunii — direcție, rețea, mască și alias — iar aliasul nu este opțional: push "route 192.168.2.0 255.255.255.0" și push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Rețeaua și masca sunt intervalul pe care clientul îl vede (192.168.2.0/24), aliasul este intervalul real al biroului pe partea serverului (192.168.1.0/24), iar ruta trimisă face acel interval vizibil accesibil. Biroul apare apoi pentru acel client sub 192.168.2.x. Documentează maparea în profil, altfel următoarea persoană o va depana ca defect de rutare.
Publicarea unui singur serviciu este versiunea îngustă a traducerii și nu are nevoie deloc de opțiunea OpenVPN. O regulă DNAT pe hostul VPN republică un singur port, așa că LAN-ul își păstrează adresele și ajunge la serviciu la adresa de host pe care o știe deja. Costul este cel obișnuit: serviciul vede hostul VPN ca sursă, deci jurnalele per client și căutările inverse nu mai înseamnă nimic. Asta acoperă o coadă de imprimare sau o pagină de administrare, nu hosturi de ambele părți care se ating.
Ce nu va funcționa în continuare și ce să consemnezi
Broadcast-ul nu traversează un tunel rutat. DLNA, UPnP, navigarea NetBIOS și Wake-on-LAN depind de broadcast sau multicast pe care un dispozitiv tun nu îl transportă, deci nicio rută nu repară descoperirea. Puntea cu dev tap extinde segmentul, și odată cu el broadcast-urile DHCP, ARP și orice alt pachet de descoperire; preferă o rută de host unicast precum route 192.168.2.1 255.255.255.255 pentru adresa din partea LAN a unui router îndepărtat.
Două routere care folosesc ambele 192.168.1.1 pe același drum fac parte din aceeași familie de probleme: adresa locală câștigă mereu, așa că pagina routerului îndepărtat rămâne inaccesibilă până când o LAN se mută. Adăugarea unui al doilea adaptor nu schimbă nimic în niciunul dintre cazuri.
Notează dovezile înainte de a edita ceva: ip route get sau Find-NetRoute, ping -c 3 la adresa respectivă, un traceroute, și tcpdump -ni tun0 icmp pe client, apoi tabelul de rutare și contoarele NAT pe server. Un ping care funcționează într-un sens și moare în celălalt indică drumul de întoarcere, nu tunelul, și exact această distincție decide care dintre reparațiile de mai sus îți trebuie cu adevărat.