De ce un server din spatele unui client VPN răspunde prin tunel

Conexiunile de intrare către un host care rulează și un client VPN eșuează într-un mod foarte specific: handshake-ul ajunge, daemonul răspunde, iar clientul nu primește nimic înapoi. Nimic nu blochează portul. Răspunsul a plecat prin tunel, pentru că tunelul deține ruta implicită și kernelul rutează răspunsurile după destinație, nu după memoria locului de unde a venit cererea. Acea singură omisiune explică fiecare simptom care urmează.

Răspunsul este rutat, nu reținut

Un client VPN care instalează o rută implicită adaugă o intrare care depășește gateway-ul LAN, fie prin metrică, fie împărțind spațiul în două jumătăți mai precise. Pachetele de ieșire aleg acum interfața tunelului. Kernelul nu întreabă niciodată de unde a sosit inițial pachetul căruia i se răspunde. Acea singură omisiune explică fiecare simptom care urmează.

Direcția înainte este rutată după destinație, iar cea de întoarcere la fel. Răspunsul este adresat unui client public, pe care tunelul îl va transporta bucuros. Capătul îndepărtat primește un pachet a cărui sursă nu îi aparține, îl aruncă, iar clientul original așteaptă până expiră timpul.

Filtrarea strictă a căii inverse poate elimina pachetul de intrare înainte ca daemonul să îl citească. Verificați mai întâi acel contor, pentru că o eliminare de filtru și o eroare de rutare arată identic din exterior.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Prima comandă arată care rută implicită câștigă acum. A doua raportează dacă filtrarea strictă se aplică global sau pe interfață, iar a treia arată orice regulă din lanțul de redirecționare care ar putea fi implicată.

Trei moduri de a păstra calea de întoarcere

Excluderea destinației serviciului din tunel este cea mai îngustă opțiune. O rută de host îndreptată spre gateway-ul LAN, plus un daemon legat de adresa fizică în loc de toate adresele, ține acel singur flux în afara tunelului. Schimbarea este locală și ușor de anulat.

Rutarea pe politici este răspunsul general. O regulă bazată pe adresa sursă sau pe un marcaj de firewall alege o tabelă a cărei rută implicită indică gateway-ul WAN, în timp ce conexiunile proprii ale hostului continuă să folosească tunelul. Păstrați prioritatea explicită pentru ca regula să nu fie umbrită mai târziu.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Primele două comenzi construiesc calea alternativă pentru răspunsurile cu sursa în adresa publică. A treia întreabă kernelul ce cale ar lua exact acea sursă și destinație, și astfel confirmați că regula are vreun efect.

Traducerea sursei este a treia opțiune și singura care supraviețuiește în fața unui router care face deja NAT în fața serviciului. Răspunsul trebuie să se întoarcă la acel router, iar mascarea către interfața WAN realizează asta ascunzând clientul din jurnalele serviciului. Înlocuirea manuală a rutei implicite după conectare este o diagnoză, pentru că clientul rescrie tabela la următoarea reconectare.

Când cutia rutează și pentru un LAN

Aceeași defecțiune apare cu un salt mai departe când hostul rutează pentru dispozitivele din spatele său. O conexiune de intrare este redirecționată către un dispozitiv intern a cărui singură cale de întoarcere este tunelul, iar răspunsul ajunge la clientul extern de la adresa furnizorului. Dispozitivul intern funcționează corect tot timpul.

Urmărirea conexiunilor vede atunci un răspuns pentru un flux pe care nu l-a înregistrat niciodată și îl elimină. Traducerea destinației livrează conexiunea de intrare dispozitivului, iar traducerea sursei face răspunsul să pară că vine de la routerul însuși.

O rută de politică ce ține portul redirecționat pe WAN în timp ce traficul propriu al routerului folosește tunelul este echivalentul mai curat. Fără traducerea sursei răspunsul este adresat clientului extern, iar dispozitivul intern nu are deloc rută către acea adresă.

Trei sondaje care separă cauzele

Rulați trei sondaje: o conexiune către cutie din internet, o conexiune din ea către un host public și o căutare de nume. Când primele două nu sunt de acord, calea de întoarcere este vinovată. Când numele eșuează în ambele sensuri, resolverul este altă defecțiune care doar împarte tunelul.

Remediați mai întâi problema rutării, apoi uitați-vă la nume. Amestecarea celor două este modul în care un server funcțional este învinuit pentru un resolver stricat.

Notați ce interfață numește excepția și țineți configurația sub control de versiuni. O regulă scrisă împotriva unei interfețe redenumite după o actualizare trece astăzi și eșuează după următoarea repornire.