Următorul salt într-o rută VPN: de ce poarta trebuie să fie accesibilă local

O rută către o rețea VPN poartă două adrese ușor de confundat: prefixul de destinație pe care pachetul încearcă să îl atingă și următorul salt care îl va muta un pas mai aproape. Pe o gazdă LAN, acel următor salt trebuie să fie un router la care chiar puteți ajunge pe aceeași legătură. Adresa VPN îndepărtată nu este un următor salt, oricât de bine s-ar potrivi cu destinația pe care o aveți în minte.

Acest ghid acoperă cazul obișnuit: un laptop pe 192.168.20.0/24, o poartă VPN cu adresa LAN 192.168.20.5 și o rețea îndepărtată 10.70.0.0/24 în spatele acelei porți. Toate comenzile de mai jos presupun că sunteți pe laptop, dacă nu se specifică altfel.

Două adrese, o rută

Intrarea dorită este 10.70.0.0/24 via 192.168.20.5. Prefixul spune unde merge pachetul; adresa via spune cine îl duce acolo. Nucleul refuză să instaleze o rută a cărei poartă nu o poate atinge prin interfața pe care o numiți, iar acel refuz este tot rostul: un următor salt care are nevoie de tunel ca să fie accesibil nu poate fi următorul salt care construiește tunelul.

Așadar prima verificare nu este «funcționează poarta», ci «este poarta pe această legătură». Subrețeaua proprie a laptopului, intrarea sa ARP sau de vecin și interfața din rută trebuie să fie toate de acord. O adresă care există doar în interiorul 10.70.0.0/24 poate fi destinația unei a doua rute, dar niciodată via primeia.

La ce obligă următorul salt poarta

Instalarea rutei pe laptop decide doar prima predare. Apoi poarta are nevoie de propria cale: redirecționare activată, o rută de tunel către 10.70.0.0/24 și orice politică de acces care stabilește cine o poate folosi. Pe Linux aceasta este net.ipv4.ip_forward=1 plus o rută de tunel; un paravan de foc din față are nevoie de o regulă care permite fluxul redirecționat.

Direcția de întoarcere este partea pe care oamenii o uită. Partea îndepărtată trebuie să aibă o rută înapoi către 192.168.20.0/24, sau proiectarea trebuie să traducă sursa laptopului în ceva ce partea îndepărtată cunoaște. Un ping care funcționează de pe poartă dovedește că poarta atinge rețeaua îndepărtată; nu spune nimic despre dacă pachetele laptopului supraviețuiesc drumului de întoarcere.

Verificați căutarea de pe gazda care trimite

Întrebați nucleul ce următor salt ar alege și citiți interfața din răspuns:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Dacă căutarea raportează poarta și interfața LAN, primul tronson este configurat cum s-a intenționat. Dacă raportează dispozitivul de tunel, ceva mai devreme în tabel este mai specific și câștigă. Dacă ruta nu se instalează deloc, nucleul vă spune că poarta nu este accesibilă, iar acel mesaj este mai util decât orice captură de pachete.

Apoi repetați testul din locul potrivit. O cerere creată pe poartă folosește adresa de sursă proprie a porții, ceea ce poate ascunde o rută de întoarcere lipsă sau o politică ce permite doar anumite surse. Manualul ip-route separă destinația, poarta și suprascrierea onlink, iar suprascrierea merită înțeleasă înainte de a o folosi.

Nu folosiți onlink pentru a simula accesibilitatea

onlink îi spune nucleului să sară peste verificarea accesibilității unei porți și să trimită totuși acolo. Nu creează o cale, nu rezolvă ARP pentru o adresă care nu există și nu face un router îndepărtat să răspundă pe segmentul dumneavoastră Ethernet. Este legitim pentru porți care răspund dar nu se află într-o subrețea conectată și este o capcană atunci când este folosit pentru a înăbuși o eroare pe care nu ați explicat-o.

Dacă ruta se instalează doar cu onlink, următoarea întrebare este de ce poarta nu este unde credeți. Un VLAN greșit, o a doua adresă pe interfața greșită sau o greșeală de tastare în ultimul octet produc toate acest lucru, iar fiecare dintre ele strică și calea de întoarcere de îndată ce traficul începe să curgă.

Tunelurile punct-la-punct nu sunt Ethernet

Un dispozitiv de tunel nu face ARP și adesea nu are o subrețea semnificativă de vecini. Rutele sale arată frecvent ca 10.70.0.0/24 dev tun0, fără niciun via, pentru că partenerul este singurul alt capăt. Copierea unui via în stil LAN în acel tabel produce o rută pe care nucleul o poate respinge sau, mai rău, una care indică o adresă la care partenerul nu răspunde niciodată.

Țineți cele două modele separate în ghid: o rută LAN are o poartă accesibilă, o rută de tunel are o interfață și un partener. WireGuard, OpenVPN și IPsec expun forme ușor diferite, așa că notați forma pe care ați folosit-o efectiv în loc să generalizați de pe o singură gazdă.

Adăugați, confirmați, reveniți

Întreaga schimbare este trei comenzi și o verificare, și ar trebui scrisă în această ordine:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confirmați calea, confirmați o destinație, apoi țineți linia de ștergere pregătită în caz că schimbarea face gazda inaccesibilă într-un mod pe care nu l-ați prevăzut. Dacă ruta trebuie să supraviețuiască unei reporniri, puneți-o în configurația de rețea a gazdei și nu într-un profil de shell, și testați repornirea înainte de a vă baza pe ea. O rută care există doar în shell-ul care a adăugat-o este o rută pe care o veți depana de două ori.