OpenVPN tot împinge rute vechi? Verificați ce a încărcat

Adăugați o rută, reporniți serviciul, vă reconectați, iar tabelul clientului arată exact ca înainte. Pot fi adevărate două lucruri diferite: serverul nu a încărcat niciodată modificarea dumneavoastră sau clientul nu a instalat niciodată ce a primit. Nu au nimic în comun în afară de simptom, așa că primul pas este să aflați care dintre cele două cazuri îl aveți.

Comparația de mai jos merge de la proces spre exterior, deoarece procesul este singura autoritate cu privire la fișierul care este în vigoare.

Fișierul pe care l-ați editat și fișierul pe care îl citește procesul

Începeți cu unit-ul și cu linia de comandă pe care a produs-o. Pe un gazdă systemd, systemctl cat openvpn@server tipărește linia ExecStart, iar un unit de instanță își derivă de obicei calea de configurare din numele instanței, așa că un demon pornit ca openvpn@office citește un alt fișier decât unul pornit ca openvpn@server. Comparați asta cu argv-ul procesului care rulează. Un instrument de gestionare a configurației adaugă o altă cale de a pierde modificarea: poate scrie un fișier corect într-o locație pe care unit-ul nu o menționează niciodată, iar atunci o implementare reușită pare că nu a făcut nimic.

Marcajele de timp rezolvă repede problema: dacă fișierul este mai nou decât ora de pornire a procesului, procesul nu l-a putut citi. Firmware-ul routerului adaugă un al treilea caz, deoarece multe modele își țin setările în flash și reconstruiesc configurația la pornire, ceea ce face ca editarea unui fișier pe disc să fie cu totul stratul greșit.

Ce împinge serverul și ce instalează clientul

O rută împinsă trebuie să treacă de două filtre. Pe server trebuie să fie în configurația încărcată, nu într-un bloc comentat sau într-un fișier specific clientului al cărui nume nu se potrivește. Pe client, pull trebuie să fie activat și niciun pull-filter nu trebuie să arunce opțiunea. Conectați-vă cu verbosity 4 și citiți opțiunile împinse pe care le raportează clientul: dacă ruta apare în acea listă, serverul și-a făcut treaba, iar clientul alege să nu o instaleze.

Fișierele specifice clientului sunt o sursă frecventă de confuzie. Un fișier numit după common name-ul certificatului împinge opțiuni doar către acel client, iar o diferență de un caracter oprește împingerea în tăcere, fără eroare de nicio parte. Serverul înregistrează common name-ul pe care l-a văzut la conectare, așa că comparați acea valoare cu numele fișierului, nu cu ceea ce credeți că este numele clientului.

Prefixul împins și ruta de întoarcere sunt probleme diferite

Un client care ignoră intenționat redirect-gateway pentru a-și păstra calea locală către internet creează o a doua lipsă, fără legătură. Sondele serverului ajung la adresa tunelului, dar răspunsurile nu ajung niciodată, pentru că un răspuns adresat IP-ului tunelului serverului este rutat prin gateway-ul implicit obișnuit al clientului. Ruta de subrețea împinsă nu este vinovată aici; ceea ce lipsește este o rută care trimite traficul pentru rețeaua tunelului serverului înapoi prin dispozitivul de tunel.

Adăugarea acelei rute pe client repară răspunsurile la sondele inițiate de server. Nu înlocuiește ruta de subrețea împinsă, și nici invers nu este adevărat, pentru că cele două descriu direcții opuse de deplasare.

Comparați tabelele la ambele capete

După orice modificare, reconectați-vă și citiți tabelul clientului pentru prefixul împins și pentru dispozitivul de tunel. Apoi testați în ambele direcții: de la client la un gazdă din subrețeaua împinsă și de la acea gazdă înapoi la client. O rută care există dar nu transportă trafic înseamnă unul din trei lucruri: partea îndepărtată nu redirecționează, un firewall aruncă fluxul sau răspunsul nu are cale de întoarcere.

Țineți trei identificatori împreună: calea de configurare, numele unit-ului sau al instanței și identitatea clientului cu care ați testat.

Aceștia trei transformă următorul incident într-o verificare de cinci minute în loc de o nouă investigație, și exact de ei are nevoie un coleg când tunelul devine problema altcuiva.

O problemă de rute care supraviețuiește unei reporniri nu este adesea deloc o problemă de rutare; defectul se află mai sus de tabelul pe care îl citiți mereu.