OpenVPN-Cliente gesinn sech net géigesäiteg: Subnetz oder net30?

Zwee onofhängeg Feeler produzéieren déi selwecht Beschwéierde. Am éischten erreecht ee Client en aneren och net iwwer d'Tunneladress, well d'Adressen net an engem eenzegen Subnetz sinn oder de Server de Verkéier tëscht Peeren net weiderleet. Am zweeten funktionéiert ping awer d'Apparaterlëscht vun der Applikatioun bleift eidel, well d'Entdeckung op Broadcast berout, deen en Tunnel vun der Schicht 3 net ka droen. Een eenzegen Ping trennt se, an d'Reparatur vun all eenzelem gläicht net wéineg un där vum aneren.

Ee Ping deelt de Problem an zwee

Vun engem Client aus pingt d'Tunneladress vum aneren, net säin Numm an net seng LAN-Adress. Wann dat feelt, ass d'Weiderleeden oder d'Adresséierung de Problem an d'Entdeckung ass irrelevant bis et reparéiert ass. Wann et geléngt, funktionéiert d'Weiderleede schonn an déi reschtlech Lück ass Broadcast oder Nummopléisung.

ip addr show tun0

Liest d'Interface vum Client virun allem aneren, well d'Netzmaske d'Topologie nennt. Eng /24 oder eng aner Subnetzmaske heescht en gedeelte Pool; eng /30 mat enger Peeradress heescht déi méi al Punkt-zu-Punkt-Layout, wou all Client genee een Noper huet, de Server.

net30 géint Subnetz, vun der Clientsäit gelies

Mat net30 verdeelt de Server e klengen Block pro Client, dofir gëtt et keng Route op d'Tunneladress vun engem anere Client, ausser de Server leet se weider. Mat Subnetz ass de ganze Pool een Netz, all Client kann all aneren adresséieren, an de Server leet tëscht hinnen weider. Dofir kann eng Serverkonfiguratioun gesond ausgesinn, wärend d'Pinge tëscht de Peeren feelen: näischt ass futti, d'Cliente sinn einfach net an engem Netz. De Client gesäit eng funktionéierend Verbindung an eng Peeradress déi net äntwert, wat wéi eng Firewall kléngt awer eng Adresséierungslayout ass.

D'Direktiv ëmschalten ass eng Ännerung op der Serversäit plus en Neistart, an se gëllt fir déi nächst Verbindung an net fir Sitzungen déi schonn op sinn. Verbënnt d'Cliente nei ier dir d'Ännerung beurteelt. Wann en Apparat d'Konfiguratioun aus enger Webschnëttstell nei generéiert, notéiert d'Direktiv, d'Datei an den Datum, a maacht d'Ännerung iwwer d'Schnëttstell wann eng do ass, well eng Neierstellung eng händlech Ännerung beim nächsten Späicheren iwwerschreift.

client-to-client ass eng separat Paart

Och bannent engem eenzegen Subnetz verwërft de Server Paketen déi vun engem Client kommen an un en aneren adresséiert sinn, ausser client-to-client ass gesat. Dat Schlësselwuert mécht de Server zu engem Weiderleeder fir Peer-Verkéier amplaz engem Endpunkt deen en nëmmen unhëlt. Et ass déi zweet Bedingung déi d'Leit no der Reparatur vun der Topologie iwwersinn.

Dëst erstreckt sech net op Broadcast. D'Astellunge leet Unicast tëscht de Cliente weider; et mécht den Tunnel net zu engem gedeelte Segment, an et wäert egal wéi vill dovun eng Multicast-Entdeckungsufro net un all Peer liwweren.

TUN géint TAP, a wat all eenzel ka droen

En tap-Apparat an d'LAN ze brécken setzt ewech Cliente an d'Broadcast-Domän vum Büro, wat d'Entdeckung komplett löst. De Präis sinn d'Plattformen déi TAP net ëmsetzen, eng Bréck déi um Server muss sinn, an eng Feelerdomän wou e Broadcaststuerm um Bürokabel all ewech Laptop erreecht.

Fir zwou oder dräi Aarbechtsstatiounen déi Nummopléisung brauchen, ass en hosts-Agang oder eng Unicastadress vill méi bëlleg wéi eng Bréck. Gräift op TAP zeréck wann e Protokoll deen dir net kënnt ersetzen op Entdeckung op Schicht 2 ugewise ass, an net virdru.

Cliente vum selwechten Subnetz ouni Bréck

Eng Adress aus dem LAN-Beräich ze ginn setzt de Client net op de Kabel. De Server routet tëscht Tunnel an Ethernet, dofir hält d'ARP fir déi Adress um Interface vum Server op an de Rescht vum LAN léiert ni wou se wunnt.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP schléisst déi Lück andeems de Server am Numm vum Client äntwert. Fir e Beräich verwalte parpd d'Agäng wärend d'Cliente kommen an goen, wärend de sysctl net.ipv4.conf.eth0.proxy_arp=1 fir alles äntwert wat soss wouhin geroutet gëtt, wat breet genuch ass fir seng eege Iwwerraschungen op engem beschäftegte Segment ze schafen.

Wéi ee Wee dir och wielt, huelt NAT tëscht dem Tunnel an dem Kabel eraus. Eng MASQUERADE-Reeg verstoppt genee d'Adresséierungsfro déi dir probéiert ze beäntweren. Se léisst der nächster Persoun och eng Topologie déi se vun der Clientsäit aus net kann duerchdenken.

Ier dir eppes ännert, fänkt eng Versuch um Server mat tcpdump -ni tun0 a bestätegt ob de Peerpaket iwwerhaapt ukënnt. Ukommen a verwerfen deit op client-to-client; ni ukënnt deit op Topologie oder Routing. Den OpenVPN-2.6-Handbuch dokumentéiert déi zwou Schlësselwierder an d'Standardtopologie, wat et wäert ass et mat ärer Versioun ze vergläichen ier dir eng Linn aus engem Forumspost kopéiert.

• D'tun-Interface weist eng Poolmask anstatt eng /30-Peerkoppel.
• E direkte Ping op déi aner Tunneladress geléngt ier dir d'Entdeckung testt.
• D'Serverkonfiguratioun enthält client-to-client wann ëmmer Peeren Paketen austausche mussen.
• Nennt de Protokoll vun der Entdeckung deen dir testt amplaz ze soen d'App feele géif.
• Benotzt TAP nëmmen wann all Clientplattform an der Grupp et ënnerstëtzt.
• Halt NAT aus dem Wee tëscht Tunnel an LAN wann d'Erreechbarkeet bannent dem selwechten Subnetz wichteg ass.