De ce ordinea adaptoarelor nu decide ruta VPN a laboratorului

Faptul că adaptorul 1 este primul în lista hipervizorului este doar o ordine de afișare, iar tabela de rutare a invitatului nu o citește. Ce decide calea sunt prefixul, metrica și orice regulă de politică ce se aplică înaintea ambelor. De aceea, adăugarea unui adaptor punte la o VM de laborator poate crea o a doua rută implicită, în timp ce vechea interfață NAT apare în continuare ca prezentă și numerotată a doua. Rezultatul este o VM care uneori folosește tunelul și uneori nu, fără nicio modificare de configurație care să explice asta.

Trei condiții decid calea

Cele trei condiții sunt care prefix este mai specific, ce fac metricile atunci când prefixele sunt egale și ce reguli a aplicat invitatul după modificarea hardware. La fiecare se poate răspunde cu o singură comandă, iar niciuna nu implică numerotarea hipervizorului.

Exact acel ultim punct este decizia: dacă nu puteți spune care prefix câștigă pentru adresa proprie a punctului final VPN, nu aveți o politică de rutare, aveți o topologie care funcționează azi din întâmplare.

Prima condiție: care prefix câștigă

O rută către 10.8.0.0/24 învinge o rută implicită pentru o adresă din interiorul ei, indiferent de metrici și de ordinea adaptoarelor. De aceea un client VPN care instalează o rută specifică continuă să funcționeze chiar și când apare un al doilea adaptor cu metrică mai mică: specificitatea câștigă înainte de a se lua în calcul costul. Verificați cu ip route show tabela pe care credeți că o folosiți, și cu ip route get 203.0.113.9 răspunsul pe care nucleul l-ar da efectiv pentru o destinație anume.

Adresa proprie a punctului final este testul care contează cel mai mult. Dacă adresa serverului VPN se rezolvă printr-un adaptor punte adăugat recent, tunelul poate să nu se stabilească niciodată, sau să se stabilească și apoi să-și piardă propria cale de transport. Întrebați exact acea adresă în loc să presupuneți că interfața tunelului este răspunsul.

A doua condiție: ce face metrica și ce nu face

Rolul ei este mai îngust decât se așteaptă majoritatea. Metricile departajează rute către același prefix; nu permit unei rute mai largi să învingă una mai specifică. La egalitate se preferă numărul mai mic, iar sistemele de operare diferite numără în direcții opuse, de aceea sfaturile copiate între Linux și Windows se contrazic adesea.

În invitat, ip route show afișează metrica lângă fiecare rută, iar Get-NetRoute în Windows afișează un InterfaceMetric plus o metrică de rută. Citiți ambele, pentru că preferința efectivă poate fi o sumă și nu un singur câmp. Dacă există două rute implicite, acesta este rezultatul: invitatul are două ieșiri, iar care câștigă este funcție de numere pe care o modificare hardware le poate schimba.

A treia condiție: ce a aplicat de fapt invitatul

Configurația nu este același lucru cu starea aplicată. Numele interfețelor nu sunt stabile la modificările hardware pe fiecare platformă, iar o configurație care se potrivea după nume poate acum să nu se aplice la nimic.

Verificați starea aplicată, nu pe cea intenționată. ip -br link arată interfețele care există acum, iar pe un host cu NetworkManager nmcli connection show arată ce profil este legat de ce dispozitiv. Un profil care nu s-a putut lega lasă interfața activă fără adresare, ceea ce arată ca o problemă de rutare și este o problemă de denumire. Instantaneele restaurate agravează asta, pentru că starea salvată a invitatului poate referi identități de adaptor pe care noul hardware nu le mai oferă.

Păstrați topologia laboratorului reproductibilă

Salvați conexiunile de rețea virtuală intenționate alături de configurația invitatului, astfel încât maparea de la rol la adaptor să fie scrisă, nu dedusă dintr-o poziție din listă.

De obicei patru roluri sunt suficiente pentru a fi numite: legătură privată, administrare, transport exterior și tunel. Fiecare ar trebui să corespundă unui anumit adaptor și unei anumite interfețe a invitatului, într-un fișier.

Apoi testați aplicația reală după o modificare hardware, o repornire sau un instantaneu restaurat, și includeți ruta către punctul final VPN în acel test. Dacă o VM de gateway trebuie să fie singura ieșire, verificați că VM-ul de test nu are o a doua rută implicită nedorită, pentru că un adaptor punte adaugă exact o a doua rută implicită. Testați din invitat, nu din consola hipervizorului, deoarece cele două pot să nu fie de acord cu privire la care interfață este care.

Documentația de rețea a VirtualBox descrie modurile adaptoarelor și la ce se conectează fiecare, iar aceea este partea care merită citită înainte de a adăuga unul al doilea. Un laborator care identifică ce adaptor deservește fiecare rol face o schimbare de rută explicabilă. Un laborator care se bazează pe numerotarea hipervizorului transformă fiecare schimbare într-un experiment.