Ruta aparatului OpenVPN: proprietarul configurației sau scriptul de pornire?
O rută de sucursală care supraviețuiește unei reporniri poate dispărea totuși după o salvare în GUI sau o actualizare de firmware. Comparați proprietarul configurației acceptat cu un script de corecții.
Adăugați o rută de sucursală, funcționează, iar apoi o actualizare de firmware sau o salvare din interfața web o elimină. Două corecții par la fel de rezonabile în acel moment: să puneți ruta în sursa de configurare acceptată a aparatului, sau să o adăugați la fișierul generat dintr-un script de pornire. Se comportă la fel o săptămână și diverg la a doua actualizare. Acest articol compară ce deține de fapt fiecare.
Cei doi candidați dețin lucruri diferite
Sursa de configurare acceptată este tot ceea ce aparatul tratează ca intrare: un câmp GUI, un profil importat, un director documentat pentru fiecare client, o bază de date de setări pe care o citește pachetul de administrare. Fișierul server.conf generat este ieșire. Editarea ieșirii funcționează până când generatorul rulează din nou, iar asta se întâmplă la salvare, la repornire și la actualizare.
Abordarea cu script aplică corecții pe acea ieșire după ce generatorul termină. Este o tehnică legitimă pentru un laborator și este valoarea implicită greșită pentru un birou de sucursală, pentru că face ruta dependentă de potrivirea textului în loc de un câmp documentat.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
Ce regenerează aparatul și când
Pachetele de administrare păstrează de obicei setările într-o bază de date sau într-un set de șabloane și generează configurația demonului la pornire. O salvare din interfața web rescrie adesea întregul fișier în loc să corecteze o linie. Dacă modificarea dumneavoastră trăia în acel fișier, acum a dispărut, și nimic nu înregistrează un avertisment, pentru că din perspectiva aparatului nu s-a pierdut nimic.
Învelișurile de pornire au un al doilea mod de eșec. Un grep pentru o directivă cu un anumit spațiere nu mai găsește potrivirea după o schimbare de șablon, iar scriptul nu face nimic în tăcere. Mai rău, o actualizare de firmware poate înlocui învelișul cu o versiune nouă, luând corecția cu ea. Atunci aveți o rută care a existat un an și a dispărut în timpul unei mentenanțe pe care nimeni nu a legat-o de rutare.
Ce trebuie să exprime proprietarul acceptat
Un prefix de sucursală are nevoie de trei afirmații, nu de una. Clientul trebuie să învețe ruta, serverul trebuie să știe care client autentificat deține prefixul, iar partea de sucursală trebuie să returneze traficul la adresa de tunel care i-a fost dată. În termeni OpenVPN asta înseamnă un route împins, un iroute corespunzător legat de client, și o cale de întoarcere de cealaltă parte.
Aici interfețele aparatelor induc în eroare. O casetă etichetată „permite clienților să acceseze LAN-ul serverului” descrie trafic către rețeaua proprie a serverului. Sucursala dumneavoastră este direcția opusă: o rețea în spatele unui client, accesibilă din partea serverului. Aceeași etichetă nu implică suport pentru asta, iar o directivă validă într-un fișier nu este o promisiune că pachetul o va păstra.
Când nu există niciun control acceptat
Uneori versiunea instalată nu poate într-adevăr să exprime o rută specifică unui peer. Atunci opțiunile cinstite sunt alt gateway pe care îl controlați, sau un mod site-la-site acceptat la ambele capete. Ambele capete trebuie să-l vorbească. O pagină de produs care spune site-la-site nu face un profil OpenVPN arbitrar interschimbabil cu tunelul altui protocol, iar forțarea acelei perechi produce de obicei un tunel pe jumătate conectat care arată bine într-o pagină de stare.
Alegeți opțiunea pe care o puteți descrie într-o propoziție celui care va moșteni rețeaua. Dacă răspunsul necesită menționarea unei căi de script și a unui model de text, designul este deja fragil.
Faceți intenția auditabilă
Înregistrați contractul în afara aparatului: identitatea efectivă a clientului, prefixul, gateway-ul de întoarcere și câmpul acceptat care le furnizează pe fiecare. Exportați configurația prin mecanismul acceptat pentru ca o reconstrucție să aibă o referință, și verificați serviciul după o reconectare, o repornire și o actualizare, nu doar după schimbare.
Comparați rezultatul generat cu acea înregistrare când se strică ceva, în loc să restaurați o linie neexplicată și să sperați.referința OpenVPN 2.6 este locul unde confirmați cum interacționează route și iroute înainte de a vă certa cu o interfață.
Listă de verificare pentru următoarea schimbare: numiți proprietarul, enunțați contractul în trei părți, exportați intenția și retestați după propriile evenimente din ciclul de viață al aparatului, nu după editarea dumneavoastră.