Publicarea porturilor Docker și sursele VPN: două potriviri pe care le ratezi

Regula spune să permiți adresa serverului VPN către serviciul publicat, iar conexiunea tot cade. Acest rezultat este obișnuit și nu este o eroare a Docker. Două potriviri separate sunt greșite: sursa pe care ai scris-o poate să nu fie sursa pe care o primește gazda, iar portul pe care l-ai scris poate să nu fie portul pe care îl vede filtrul. Corectarea ambelor cere să te uiți la traseul pachetului, nu la diagrama serviciului.

Mitul: permite serverul VPN și ai terminat

Un VPN rutat poate păstra adresa tunelului clientului până la gazda Docker. O poartă care face traducere de sursă poate înlocui acea adresă cu a sa. Ambele proiecte sunt legitime și produc surse diferite pentru aceeași acțiune a utilizatorului.

Așadar sintagma IP-ul serverului VPN descrie o presupunere, nu o observație. Până când știi care dintre cele două proiecte este în fața ta, regula este o bănuială.

Sursă: pool de clienți sau poartă tradusă

Verifică patru lucruri în ordine. Primul, pool-ul de adrese pentru clienți, de exemplu 10.90.0.0/24. Al doilea, dacă poarta traduce acel pool înainte de a ajunge la gazdă. Al treilea, sursa pe care gazda o observă într-adevăr pentru o conexiune nouă. Al patrulea, dacă autentificarea aplicației distinge utilizatorii individuali, fiindcă o adresă tradusă partajată nu poate.

Dacă pool-ul este păstrat, o regulă care se potrivește doar cu adresa publică a porții ratează fiecare client. Dacă poarta traduce intenționat, permiterea adresei traduse admite fiecare utilizator din spatele ei, ceea ce poate fi acceptabil pentru un serviciu cu autentificare proprie și inacceptabil pentru orice altceva.

Port: DNAT schimbă numărul pe care îl potrivești

La publicarea obișnuită prin punte Linux cu iptables din Docker, o mapare a gazdei de la 8443 la portul 443 al containerului este tradusă înainte de a rula filtrul de redirecționare. Pachetul ajunge la filtru cu port de destinație 443. O regulă care se potrivește cu 8443 în acel punct nu se activează niciodată, chiar dacă 8443 este ce a tastat clientul.

Portul publicat există în continuare în urmărirea conexiunilor, de aceea destinația originală poate fi potrivită acolo când chiar ai nevoie de ea.

Decide care număr exprimă intenția. Potrivește portul containerului de după DNAT când regula protejează serviciul din interiorul containerului. Potrivește destinația originală cu opțiunea conntrack când regula trebuie să descrie ce a cerut clientul, și acceptă costul suplimentar de potrivire și grija pentru ordinea regulilor care vin cu el.

Lanț: DOCKER-USER, nu INPUT

Ghidul iptables al Docker pune politica de redirecționare a utilizatorului în lanțul DOCKER-USER, care este evaluat înaintea regulilor proprii de redirecționare ale Docker. O regulă copiată dintr-un serviciu al gazdei în lanțul INPUT filtrează traficul adresat gazdei, nu traficul redirecționat către un container. Această greșeală produce o regulă care pare corectă și nu are niciun efect asupra traseului containerului.

Ține intervalul sursă, portul de destinație efectiv, protocolul și interfața de intrare împreună în aceeași regulă. O permisiune doar pe sursă pentru fiecare destinație redirecționată este mai largă decât permiterea unui singur serviciu publicat.

Verifică cu conexiuni noi

Testează ambele direcții cu conexiuni noi: un client VPN permis și o sursă care trebuie să rămână respinsă. Starea conexiunii existente poate ține o sesiune în viață după ce politica se schimbă, așa că o conexiune veche nu dovedește nimic despre regula nouă. Apoi verifică traseul răspunsului, fiindcă containerul tot trebuie să ruteze înapoi către sursa pe care o vede.

Ordinea lanțurilor și comportamentul de traducere a porturilor din spatele acestor verificări sunt documentate în ghidul iptables al Docker. Citește-l înainte de a copia o rețetă și confirmă ce backend folosește Docker-ul instalat, fiindcă backend-ul nftables integrează politica diferit.