OpenVPN include o contramăsură pentru această problemă foarte populară. Practic este un NAT static unu-la-unu. Este activat cu ajutorul --client-nat opțiune:
--client-nat args
Această opțiune de client care poate fi introdusă setează un NAT unu-la-unu fără stat
reglementează adresele de pachete (nu porturi) și este util în cazuri
unde rutele sau setările ifconfig trimise către client ar fi
creați un conflict de numerotare IP.
Exemple:
client-nat snat 192.168.0.0/255.255.0.0
client-nat dnat 10.64.0.0/255.255.0.0
rețea/mască de rețea (de exemplu 192.168.0.0/255.255.0.0) definește
viziunea locală a unei resurse din perspectiva clientului, în timp ce
alias/mască de rețea (de exemplu 10.64.0.0/255.255.0.0) definește
vedere la distanță din perspectiva serverului.
Utilizați snat (sursă NAT) pentru resursele deținute de client și
dnat (NAT de destinație) pentru resursele de la distanță.
Setați --verbul 6 pentru informațiile de depanare care arată transformarea lui
adrese src/dest în pachete.
Adăugați următoarele la fișierul de configurare OpenVPN client afectat:
client-nat dnat 10.64.0.0/255.255.0.0
client-nat snat 10.64.0.0/255.255.0.0
Și încercați să vă conectați la de ex. 10.64.1.42 în loc de 192.168.1.42.
Observați în timp ce acest lucru Mai ajutor, cu siguranță veți avea nevoie de ceva depanare (utilizați verbul 6 în fișierul de configurare sau pe canalul de management).De asemenea, amintiți-vă că orice asemenea lucru este predispus la erori, deoarece vă face rețeaua mai puțin clară și necesită mai multă concentrare pentru a înțelege ce se întâmplă și cum să remediați problemele. Și va crea, la rândul său, alte probleme cu IPSec sau SIP sau alte protocoale complexe; acest lucru este inevitabil.
Pentru a remedia acest lucru fără a introduce opțiuni de configurare tulbure, urmați sugestia lui Esa Jokinen acolo sus. O voi vorbi într-un mod mai larg: deoarece 192.168.0.x și 192.168.1.x s-au întâmplat să fie implicit pe o varietate gigantică de dispozitive de acasă, nu utilizați niciodată acele rețele pentru birou, și, de asemenea, probabil 192.168.88.x ar trebui incluse și în lista de oprire, deoarece este implicit pentru dispozitivele Mikrotik, care sunt și ele destul de populare.
Renumerotarea rețelei de birouri pentru a nu folosi niciodată acele subrețele va avea ca rezultat cel mai curat design general al rețelei. (Și această idee se extinde chiar și la alte experiențe de rețea, de exemplu, nu utilizați niciodată ID-ul VLAN implicit 1 și așa mai departe.)
Cea mai ușoară și mai confuză soluție va fi următoarea soluție. Nu poți doar apăsați „route 192.168.1.0 255.255.255.0”, deoarece veți pierde accesul la toate resursele locale. Dar încă poți împinge rutele către adrese individuale în subrețea. De exemplu, dacă sunt afectați mulți clienți, adăugați următoarea linie în configurația serverului:
apăsați „route 192.168.1.42”
(masca lui 255.255.255.255 este asumat). Singurul caz în care acest lucru nu ar funcționa este dacă adresa clientului țintă din rețeaua de domiciliu este 192.168.1.42; in acest caz nimic nu va ajuta. Apoi reporniți serverul. Dacă doar câțiva clienți sunt afectați, puteți sări peste repornirea serverului (ceea ce implică întrerupere), adăugați traseul 192.168.1.42 la configurațiile clienților afectați și forțați-i să se reconecteze.
