Clienții OpenVPN nu se văd unii pe alții: subrețea sau net30?

Două defecte fără legătură produc aceeași reclamație. În primul, un client nu ajunge la altul nici măcar pe adresa tunelului, pentru că adresele nu sunt într-o singură subrețea sau serverul nu transmite traficul între parteneri. În al doilea, ping funcționează, iar lista de dispozitive a aplicației rămâne goală, pentru că descoperirea se bazează pe broadcast, pe care un tunel de nivel 3 nu îl poate transporta. Un singur ping le separă, iar remedierea fiecăreia nu seamănă deloc cu remedierea celeilalte.

Un singur ping desparte problema în două

Dintr-un client, faceți ping către adresa tunelului celuilalt client, nu către numele și nu către adresa lui LAN. Dacă eșuează, problema este transmiterea sau adresarea, iar descoperirea este irelevantă până când nu se remediază. Dacă reușește, transmiterea funcționează deja, iar ce lipsește este broadcast sau rezolvarea numelor.

ip addr show tun0

Citiți interfața clientului înainte de orice altceva, pentru că masca de rețea numește topologia. Un /24 sau altă mască de subrețea înseamnă un pool comun; un /30 cu adresă de partener înseamnă vechea așezare punct-la-punct, în care fiecare client are exact un vecin, serverul.

net30 față de subrețea, citit din partea clientului

Cu net30 serverul distribuie un bloc mic pe client, așa că nu există rută către adresa tunelului altui client decât dacă serverul o transmite. Cu subrețea, întregul pool este o rețea, fiecare client poate adresa oricare altul, iar serverul transmite între ei. De aceea o configurație de server poate părea sănătoasă în timp ce ping-urile între parteneri eșuează: nimic nu este stricat, clienții pur și simplu nu sunt într-o singură rețea. Clientul vede o legătură funcțională și o adresă de partener care nu răspunde, ceea ce se citește ca un firewall, dar este o schemă de adresare.

Schimbarea directivei este o editare pe partea serverului plus o repornire și se aplică la următoarea conexiune, nu la sesiunile deja deschise. Reconectați clienții înainte de a judeca schimbarea. Dacă un aparat regenerează configurația dintr-o interfață web, notați directiva, fișierul și data, și faceți editarea prin interfață când există, pentru că o reconstrucție va suprascrie o editare manuală la următoarea salvare.

client-to-client este o poartă separată

Chiar și într-o singură subrețea serverul aruncă pachetele care vin de la un client și sunt adresate altuia, dacă client-to-client nu este setat. Cuvântul-cheie transformă serverul într-un transmitător al traficului între parteneri, nu într-un punct final care doar îl acceptă. Este a doua condiție pe care oamenii o ratează după ce repară topologia.

Aceasta nu se extinde la broadcast. Setarea transmite unicast între clienți; nu transformă tunelul într-un segment comun și nicio cantitate din ea nu va livra o interogare de descoperire multicast fiecărui partener.

TUN față de TAP și ce poate transporta fiecare

Puntea unui dispozitiv tap în LAN aduce clienții la distanță în domeniul de broadcast al biroului, ceea ce rezolvă complet descoperirea. Prețul îl reprezintă platformele care nu implementează TAP, o punte care trebuie să existe pe server și un domeniu de eșec în care o furtună de broadcast pe cablul biroului ajunge la fiecare laptop de la distanță.

Pentru două sau trei stații de lucru care au nevoie de rezolvarea numelor, o intrare hosts sau o adresă unicast este mult mai ieftină decât o punte. Apelați la TAP când un protocol pe care nu îl puteți înlocui depinde de descoperirea de nivel 2, și nu mai devreme.

Clienți din aceeași subrețea fără punte

Atribuirea unei adrese din intervalul LAN nu pune clientul pe cablu. Serverul rutează între tunel și Ethernet, așa că ARP pentru acea adresă se oprește la interfața serverului, iar restul LAN-ului nu află niciodată unde locuiește.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP închide acel gol făcând serverul să răspundă în numele clientului. Pentru un interval, parpd administrează intrările pe măsură ce clienții vin și pleacă, în timp ce sysctl net.ipv4.conf.eth0.proxy_arp=1 răspunde pentru tot ce este rutat în altă parte, ceea ce este suficient de larg încât să creeze propriile surprize pe un segment aglomerat.

Indiferent de drumul ales, scoateți NAT între tunel și cablu. O regulă MASQUERADE ascunde exact întrebarea de adresare la care încercați să răspundeți. De asemenea, lasă următoarei persoane o topologie despre care nu poate raționa din partea clientului.

Înainte de a schimba ceva, capturați o încercare pe server cu tcpdump -ni tun0 și confirmați dacă pachetul partenerului ajunge măcar. Că ajunge și este aruncat indică client-to-client; că nu ajunge niciodată indică topologia sau rutarea. Manualul OpenVPN 2.6 documentează ambele cuvinte-cheie și topologia implicită, ceea ce merită comparat cu versiunea dumneavoastră înainte de a copia o linie dintr-o postare de forum.

• Interfața tun arată o mască de pool, nu o pereche de parteneri /30.
• Un ping direct către cealaltă adresă de tunel reușește înainte de a testa descoperirea.
• Configurația serverului include client-to-client ori de câte ori partenerii trebuie să schimbe pachete.
• Numiți protocolul de descoperire pe care îl testați în loc să spuneți că aplicația eșuează.
• Folosiți TAP doar dacă fiecare platformă de client din grup îl acceptă.
• Țineți NAT în afara traseului dintre tunel și LAN când contează accesibilitatea în aceeași subrețea.