Clientul VPN rutat ajunge la server, dar nu la gazdele din LAN

Tunelul urcă, clientul trimite ping către serverul VPN, iar o partajare de pe o mașină aflată la un salt distanță nu răspunde niciodată. Nimic din configurația clientului nu explică asta, pentru că cererea a plecat într-adevăr de la client și a ajuns într-adevăr. Ce a eșuat este drumul înapoi, iar dispozitivul care a eșuat este de obicei gateway-ul LAN, nu gazda VPN. Urmărirea pachetului de răspuns explică toată această clasă de simptome.

Urmați răspunsul, nu cererea

Serverul VPN decriptează pachetul clientului și îl redirecționează către LAN, cu adresa clientului încă în câmpul sursă. Gazda destinație răspunde la acea adresă, iar acum propriul său tabel de rutare decide totul. Gateway-ul său implicit nu știe nimic despre bazinul tunelului, așa că răspunsul pleacă spre furnizorul de internet și este aruncat undeva pe acel drum.

La client simptomul este un timeout tăcut: niciun refuz, nicio resetare, doar nimic. Răsfoirea unei partajări se blochează, ping-ul raportează că nu există răspuns, iar jurnalele serverului arată sănătos pentru că serverul și-a făcut treaba.

Puneți ruta de întoarcere acolo unde se uită gazdele

Fiecare gazdă din LAN își întreabă gateway-ul implicit, așa că gateway-ul este singurul dispozitiv care trebuie să știe unde se află bazinul tunelului. Adăugați acolo o rută statică și fiecare gazdă moștenește calea corectă fără să fie atinsă.

Dacă gateway-ul distribuie propria adresă ca opțiune DHCP, distribuiți ruta în acel mod, astfel încât mașinile noi să o preia automat. Altfel ruta trăiește într-un singur fișier de configurare și dispare la următoarea reconstrucție.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

De ce NAT-ul de sursă pare să repare lucrurile

Mascarea bazinului de clienți în spatele adresei serverului VPN elimină problema prin eliminarea adresei clientului din pachet. Răspunsurile se întorc atunci la server, care știe deja cum să ajungă la tunel, și totul funcționează. Costul este că gazdele interne nu mai pot vedea cine este clientul, iar fiecare conexiune pare să vină de la o singură mașină.

Acest schimb este uneori corect, de exemplu când unui aparat al unui furnizor nu i se poate da o rută statică. Nu faceți regula mai largă decât bazinul actual, pentru că o regulă scrisă pentru un /24 nu mai potrivește în ziua în care bazinul este renumerotat într-un /16, iar primul semn este un grup de clienți noi care se conectează și nu ajung nicăieri.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Calea prin cloud necesită trei setări

Într-un VPC aceeași lipsă revine într-o altă formă, pentru că subrețeaua nu are nicio rută pentru intervalul clienților. Tabelul de rutare are nevoie de o intrare pentru bazinul tunelului care țintește interfața de rețea a instanței, iar interfața trebuie să aibă verificarea sursei și a destinației dezactivată, astfel încât platforma să accepte pachete a căror sursă nu este propria adresă. Grupurile de securitate și ACL-urile de rețea trebuie de asemenea să admită bazinul în ambele direcții.

Fiecare omisiune produce o defecțiune parțială distinctă. Omiteți intrarea din tabelul de rutare și instanțele private răspund într-o subrețea care nu poate duce răspunsul înapoi la bazin. Cu verificarea încă activă, platforma aruncă răspunsul după ce instanța l-a trimis deja. Fără regula grupului de securitate, cererea în sine nu ajunge niciodată, iar clientul vede timeout-ul cu un strat mai devreme.

Rulați verificările în această ordine

Confirmați redirecționarea și politica de filtrare înainte de a da vina pe rutare, pentru că o gazdă care nu va redirecționa eșuează în același mod tăcut. Apoi citiți setarea efectivă a căii inverse pe interfața care transportă tunelul, deoarece un filtru strict poate arunca răspunsuri care sosesc dintr-o direcție neașteptată.

Încheiați cu o captură făcută pe gazda din LAN în timp ce clientul o ping-uiește. O cerere care sosește fără un răspuns corespunzător dovedește calea de întoarcere, iar o cerere care nu sosește niciodată mută vina înapoi la server sau la tunel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Verificarea sursei și a destinației este documentată în ghidul interfeței de rețea elastice. Setați-o pe interfața care transportă efectiv traficul tunelului, nu pe un adaptor nelegat de aceeași instanță.