Deschiderea portului VPN nu le dă clienților acces la LAN

Tunelul urcă, clientul se autentifică, dar LAN-ul din spatele gateway-ului rămâne invizibil. Regula care trebuia să repare asta permite portul VPN și funcționează exact așa cum este scrisă, pentru că acea regulă guvernează pachetele adresate gateway-ului însuși. Traficul clientului către un host din spatele gateway-ului are altă destinație și alt lanț. O autentificare reușită nu schimbă care dintre cele două lanțuri este consultat de kernel.

Două lanțuri, două destinații diferite

Soarta unui pachet este decisă de unde merge, nu de cum a ajuns. Traficul adresat unei adrese de pe gateway este livrat local și evaluat după regulile de intrare. Traficul pe care gateway-ul îl trimite mai departe este evaluat după regulile de forwarding. Aceeași interfață de tunel poate produce ambele tipuri de pachete, de aceea o singură regulă nu poate acoperi ambele sarcini.

Tot mitul într-o propoziție: a permite ascultătorul nu spune nimic despre a permite rețeaua din spatele lui. Sunt două decizii separate cu dovezi separate, iar un nume de interfață pe ambele nu le unește.

Ce permite de fapt regula ascultătorului

Pachetele ascultătorului se termină în procesul VPN, iar asta este ce face posibilă construirea tunelului. Pagina de administrare a gateway-ului și un răspuns de diagnostic local folosesc și calea de intrare proprie a hostului, de aceea un test către gateway reușește în timp ce tot ce este în spatele lui eșuează. Ambele rezultate sunt corecte și niciunul nu este despre LAN.

Când procesul decapsulează traficul clientului pentru altă destinație, pachetul intră pe calea de forwarding și are nevoie de permisiune acolo. Autentificarea reușită decide cine este clientul; nu decide unde poate merge. Cele două întrebări au proprietari, jurnale și mesaje de eroare diferite.

Testați de la un client, niciodată de la gateway

Un test generat pe gateway urmează calea de ieșire a hostului și poate reuși în timp ce calea de forwarding este închisă. Începeți testul de la client și urmăriți ambele capete ale fluxului.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Dacă cererea apare pe tun0 și nimic nu ajunge la destinație, pachetul este aruncat după sosire, ceea ce indică regulile de forwarding sau filtrarea proprie a destinației. Dacă pe tun0 nu apare nimic, clientul nici măcar nu o trimite în tunel, iar problema este rutarea pe client, nu politica pe gateway. Comparați cu o cerere care iese corect și nu întoarce nimic, care este cazul căii de întoarcere.

Forwarding-ul are nevoie de trei lucruri, nu de unul

Forwarding-ul din kernel trebuie să fie activ, o regulă de filtru trebuie să accepte fluxul, iar destinația trebuie să fie accesibilă cu o cale pentru întoarcerea răspunsului. Dacă lipsește unul din trei, tăcerea este aceeași din perspectiva clientului.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Citiți cele trei ieșiri împreună. Un zero în prima le face irelevante pe celelalte două, iar o politică implicită de eliminare în a doua aruncă pachetele clientului în timp ce traficul propriu al gateway-ului continuă să funcționeze. A treia ieșire arată de ce regula ascultătorului nu a fost niciodată problema.

Țineți cele două seturi de reguli separate în documentație

Scrieți regula ascultătorului și regula serviciului forwardat pe linii separate, cu proprietari și motive separate. Când portul VPN se schimbă sau este publicat un serviciu nou, acea separare împiedică o modificare să o lărgească în tăcere pe cealaltă.

În loc să tratați fiecare peer autentificat ca membru de încredere al LAN-ului, folosiți reguli înguste pentru intervalele de clienți și serviciile care au nevoie de ele. Notele despre forwarding ale StrongSwan descriu partea de rută de întoarcere și de traducere a aceleiași granițe, ceea ce este din nou o a treia decizie.

În sfârșit, țineți straturile drepte când un utilizator este respins. Dacă cererea ajunge la host și aplicația refuză contul, reparați permisiunea aplicației la acel strat; lărgirea forwarding-ului nu poate furniza acreditări pentru partajarea fișierelor și va lărgi accesul pentru toți ceilalți care se conectează cu succes.