Un gateway VPN are nevoie de redirecționare IP: ce trebuie verificat

Clientul dumneavoastră poate face ping la adresa gatewayului în timp ce toate resursele din spatele lui rămân inaccesibile. Această pereche de observații descrie un host care vorbește cu dumneavoastră și un router care nu rutează, adică roluri diferite pe aceeași mașină. Redirecționarea este comutatorul dintre ele.

Cele două roluri sunt independente, la fel și cele două familii de adrese.

Răspunsul pe propria adresă nu dovedește nimic

Când un pachet este adresat gatewayului însuși, stiva locală îl consumă și nu se ia nicio decizie de redirecționare. De aceea un ping reușit la adresa tunelului sau la o interfață de administrare vă spune că demonul este viu și tunelul este ridicat, dar nu spune nimic despre traficul destinat unei rețele din spatele cutiei. Kernelul consultă calea sa de redirecționare doar pentru pachetele care nu îi sunt adresate.

Citiți cerința ca pe un rol, nu ca pe o setare: acest host trebuie să mute pachete între două interfețe. Un laptop care trebuie doar să ajungă la o rețea la distanță nu preia niciodată acest rol, iar un punct final site-la-site îl preia întotdeauna. Citirea cerinței astfel explică de ce o configurație de client funcțională eșuează când este mutată pe un gateway.

Aceeași frază se aplică firewallului din fața deciziei de redirecționare, care are propria politică despre ce poate fi redirecționat.

Verificați separat fiecare familie de adrese

Redirecționarea IPv4 este un comutator, iar redirecționarea IPv6 este altul, cu propriul comportament pe fiecare interfață. Activarea primului nu spune nimic despre al doilea, iar un client cu stivă dublă poate ajunge la jumătate dintr-o rețea în timp ce restul rămâne întunecat. Doi clienți din familii diferite pot, prin urmare, să nu fie de acord cu privire la același gateway. Întrebați ce familie a folosit clientul care eșuează înainte de a modifica oricare dintre setări. Confirmați ambele înainte de a concluziona că proiectarea rutării este greșită.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

În multe distribuții, valoarea pe care o citiți în timpul execuției a fost pusă acolo de un serviciu sau de un fișier de configurare, așa că o modificare făcută cu o comandă unică poate dispărea la repornire. Găsiți fișierul care deține setarea înainte de a edita valoarea de execuție.

Redirecționarea este una dintre cele patru cerințe

Un flux redirecționat funcțional are nevoie de patru lucruri simultan: clientul trebuie să știe că destinația este în spatele tunelului, gatewayul trebuie să aibă o rută înainte, răspunsurile trebuie să aibă o cale de întoarcere, iar firewallul trebuie să permită traficul. Traducerea sursei face parte din această proiectare ca opțiune, nu ca regulă, pentru că o rețea rutată privată cu căi simetrice nu are nevoie de ea, iar una asimetrică de obicei are. Fiecare dintre cele patru eșuează independent, motiv pentru care repararea uneia mută rar simptomul. Scrieți toate patru înainte de a schimba vreuna.

Platformele cloud adaugă o a cincea considerație. Unele impun verificări de sursă și destinație pe instanțe, ceea ce aruncă pachetele redirecționate indiferent de modul în care este configurat kernelul invitatului. Documentația de rețea a platformei înseși este autoritatea acolo, nu ieșirea sysctl din VM.

Testați de la client, nu de la gateway

Un test rulat în shellul gatewayului însuși nu parcurge nicio parte din calea de redirecționare pe care tocmai ați activat-o. Generați traficul de la clientul care are problema și confirmați că ajunge la ceva din spatele gatewayului, nu la gatewayul însuși. Acesta este singurul test care exersează rolul pe care l-ați schimbat.

Țineți regulile de ascultare și regulile de redirecționare separate în minte și în jurnalul modificărilor. Deschiderea portului VPN admite clienții la serviciu; nu le acordă nimic în rețeaua din spate, iar cele două arată identic într-o listă de firewall care a crescut de-a lungul anilor.

Dacă pachetele sosesc, iar serviciul respinge apoi utilizatorul, ați trecut dincolo de rețea. Continuați cu autorizarea aplicației în loc să lărgi din nou politica de redirecționare.