Prefix public prin OpenVPN: repară calea de întoarcere

Privește tunelul cum urcă și clientul făcând ping către cealaltă parte, apoi o adresă publică ce aparține în spatele VPN-ului răspunde din alt loc, sau nu răspunde deloc. Acest simptom de obicei nu are nicio legătură cu cifrul sau cu certificatele. Un prefix rutat de furnizor este livrat ca rută IP, iar transportarea lui prin OpenVPN înseamnă reproducerea acelei rute pe două niveluri și păstrarea adresei sursă pe calea de întoarcere. Nu este nevoie să punem WAN-ul în punte, iar adăugarea adresei la o interfață nu creează ruta superioară.

Prefixul trebuie mai întâi rutat către tine

Întreabă furnizorul cum este livrat blocul. Un prefix rutat către adresa principală a serverului tău este altceva decât adrese pe care furnizorul se așteaptă să le atingă direct pe un segment WAN. Doar primul model funcționează cu designul de aici.

Dacă furnizorul rutează 198.51.100.64/28 către serverul tău de intrare, pachetele pentru acel interval ajung la server și se opresc acolo, dacă nu le transmite mai departe. Dacă furnizorul pune în punte intervalul pe uplink-ul tău, serverul trebuie să răspundă la ARP pentru el, ceea ce este altă problemă.

Testează modelul de livrare înainte de a atinge OpenVPN: din exterior, fă ping către o adresă din bloc și vezi ce interfață o primește. Dacă nu sosește nimic, nicio configurare de tunel nu va ajuta. Dacă adresa răspunde direct pe WAN, furnizorul pune în punte în loc să ruteze, iar designul de mai jos nu se aplică.

Două niveluri de rutare: ruta din kernel și iroute

OpenVPN are nevoie de prefix în două locuri. Kernelul trebuie să știe că prefixul aparține dispozitivului tunelului, astfel încât pachetele transmise să intre în OpenVPN în locul rutei implicite. OpenVPN trebuie să știe și care client autentificat deține prefixul, iar aceea este intrarea iroute din directorul specific clientului.

Ruta din partea serverului arată astfel, iar prefixul și masca trebuie să corespundă alocării:

ip route add 198.51.100.64/28 dev tun0

Configurația specifică clientului atribuie proprietatea. Pune-o în fișierul CCD numit după numele comun al certificatului clientului și confirmă că acel director este cel pe care serverul îl citește efectiv:

iroute 198.51.100.64 255.255.255.240

Documentația OpenVPN despre rețele rutate descrie ambele niveluri și de ce sunt separate. O rută din kernel fără iroute trimite pachete în tunel fără proprietar, iar OpenVPN le aruncă. Un iroute fără ruta din kernel lasă pachetele pe calea implicită a serverului. Ambele greșeli arată din partea clientului ca un tunel stricat.

Unde locuiește adresa serviciului

Prefixul delegat nu este același lucru cu adresele proprii ale tunelului. Numerotează legătura din spațiul privat dacă vrei, și așază adresa publică a serviciului acolo unde serviciul rulează efectiv.

Pe un client Linux care termină serviciul local, o singură adresă de gazdă este suficientă:

ip address add 198.51.100.70/32 dev lo

Dacă prefixul este rutat mai departe către un host VM sau alt LAN, configurează în schimb acea cale descendentă și ruta ei de întoarcere. Atribuirea fiecărei adrese din bloc clientului VPN nu este necesară și creează conflicte mai târziu.

Păstrează sursa publică pe calea de întoarcere

Un răspuns din prefixul delegat trebuie să iasă prin tunel și să ajungă la ruta furnizorului. Dacă gazda îndepărtată îl trimite prin propriul ISP, adresa sursă pare falsificată, iar furnizorul sau destinația îl aruncă. Soluția este o regulă bazată pe sursă sau un tabel de rutare dedicat, nu un NAT mai larg. Fără ea, serviciul funcționează de la partenerul tunelului și eșuează din orice alt loc.

Pe serverul de intrare, o regulă masquerade largă este vinovatul obișnuit. Rescrie sursa publică în adresa principală a serverului, iar clientul nu o vede niciodată pe cea reală:

iptables -t nat -S POSTROUTING

Limitează NAT-ul la clienții VPN privați care au nevoie de el și lasă prefixul delegat netradus. Apoi confirmă că serverul transmite prefixul, pentru că un lanț de transmitere cu refuz implicit îl aruncă în tăcere.

Verifică ambele direcții înainte de a te baza pe el

Verificarea înseamnă patru observații, nu una. Confirmă că ruta furnizorului sosește, kernelul trimite prefixul în tunel, OpenVPN îl atribuie clientului corect și răspunsul se întoarce cu sursa publică intactă. Fiecare observație are comanda ei, așa că o defecțiune indică un strat, nu întregul design. Rulează-le în această ordine după fiecare modificare de configurație.

Întreabă kernelul ce cale ia o adresă delegată și urmărește tunelul în timp ce rulează o cerere:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrarea căii inverse poate anula o rută corectă. Verifică setarea efectivă pe tunel și pe uplink și ține minte că modul strict respinge traficul a cărui sursă nu corespunde interfeței pe care a sosit:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

În final, testează cazul de eșec. Oprește tunelul și confirmă că prefixul public nu se scurge prin uplink-ul obișnuit. Restabilirea VPN-ului ar trebui să readucă serviciul fără a lărgi porturile pe care gazda le expune.