OpenVPN: local față de adresa tunelului, două socketuri diferite

Clientul refuză să pornească și se plânge că nu poate lega o adresă locală, iar remedierea evidentă pare să fie îndreptarea lui spre adresa de tunel pe care se așteaptă să o primească. Asta nu poate funcționa, iar motivul merită înțeles: înainte ca tunelul să existe nu există adresă interioară, iar socketul care contactează serverul trebuie să existe mai întâi. Sunt implicate două adrese diferite, și doar una dintre ele poate fi aleasă local.

Eroarea de bind numește o adresă locală

Când OpenVPN raportează că nu poate lega o adresă locală, vorbește despre socketul de transport: punctul final UDP sau TCP care duce conexiunea criptată către peer.

O directivă local explicită cere daemonului să lege acel socket de o adresă locală anume. Adresa trebuie să existe în spațiul de nume de rețea în care rulează procesul și trebuie să poată fi atribuită în momentul în care clientul pornește.

O adresă publică tradusă la un router sau la marginea unui cloud nu este o adresă locală pe care daemonul o poate lega, chiar dacă este adresa pe care o vede serverul. Această distincție explică de ce un profil funcționează acasă și eșuează pe o instanță din cloud. Explică și de ce adăugarea adresei publice la o interfață loopback nu ajută, fiindcă transportul ar porni atunci dintr-o adresă către care rețeaua nu poate rută înapoi. Citiți lista de interfețe înainte de a edita profilul.

Ce selectează de fapt local și remote

remote numește peerul de contactat. local leagă capătul apropiat al aceluiași socket. nobind lasă sistemul de operare să aleagă atât adresa locală, cât și portul, motiv pentru care clienții din spatele routerelor de acasă funcționează de obicei fără niciuna dintre directive.

Niciuna dintre directive nu are legătură cu adresa din interiorul tunelului.

Într-un container sau într-un spațiu de nume de rețea se aplică aceeași regulă cu limite mai strânse: adresele gazdei nu sunt prezente înăuntru, așa că o linie local copiată din configurația gazdei eșuează dintr-un motiv complet diferit decât ar face-o o adresă greșită.

ip -brief address show
ip route get 203.0.113.10

Adresa interioară vine de la server

Adresa din interiorul tunelului este negociată sau atribuită după ce canalul de control este stabilit. Cu un pool dinamic serverul decide la momentul conectării, iar cu o configurație specifică clientului poate fi fixă pentru fiecare identitate.

Scrierea local cu o adresă interioară nu cere serverului să aloce acea adresă. În cel mai bun caz bindul eșuează; în cel mai rău caz clientul găsește o adresă de gazdă fără legătură, cu aceeași valoare, și începe să o folosească pentru transport.

Interfețele de citit sunt și ele diferite. Parametrii ifconfig și configurația poolului descriu interiorul, în timp ce remote, local, proto și nobind descriu exteriorul. Ținerea celor două liste separate explică aproape fiecare exemplu confuz pe care îl veți găsi pe un forum. De aceea manualul OpenVPN 2.6 le documentează în secțiuni separate.

Capcana: un tunel complet care își capturează propriul transport

Odată ce tunelul este activ și transportă ruta implicită, pachetele care îl susțin nu trebuie rutate în el. Este o problemă de rutare și nu de adresare, iar daemonul o rezolvă instalând o rută mai specifică către adresa serverului prin gatewayul original.

Dacă fixați transportul pe o adresă locală anume și mai târziu schimbați calea pe care o folosește acea adresă, conexiunea exterioară poate pierde drumul în timp ce interiorul rămâne configurat. Tunelul continuă să raporteze conectat pentru că interiorul este în regulă. Doar transportul este rupt, de aceea jurnalele se citesc ca niște contradicții.

Simptomele arată atunci ca un tunel care se conectează și îngheață, sau ca unul care se reconectează în buclă fără o eroare utilă. Verificați ruta către adresa peerului înainte de a verifica ceva în interiorul tunelului și confirmați că adresa locală pe care ați legat-o aparține încă interfeței așteptate.

Un obicei care previne confuzia

Citiți fiecare adresă dintr-un profil și decideți cărei straturi îi aparține înainte de a o edita.

Dacă numește capătul îndepărtat al transportului sau leagă capătul apropiat al acestuia, este o adresă exterioară și trebuie să existe înainte de pornire. Dacă descrie ce se întâmplă în interiorul tunelului, vine de la server sau din topologie, iar nicio directivă locală nu o poate înlocui.

Scrieți cele două liste în notele de implementare de lângă profil. Următoarea sesiune de depanare începe atunci cu stratul, nu cu o presupunere.