De ce clienții OpenVPN nu prind selectorii IPsec ai gateway-ului

Trimiteți un ping către un host din spatele tunelului IPsec aflat la distanță, din gateway, și acesta răspunde curat, așa că tunelul pare sănătos și tichetul merge mai departe. Apoi un client conectat încearcă același host și nu primește nimic înapoi. Acel ping nu a fost niciodată o dovadă pentru fluxul clientului, fiindcă a plecat cu adresa sursă proprie a gateway-ului și a corespuns unui alt selector IPsec. Înțelegerea motivului pentru care cele două cazuri diverg este cea mai mare parte a remedierii.

Pingul din gateway testează un flux pe care clientul tău nu îl folosește niciodată

Adresa sursă decide ce politică se aplică. Un pachet generat pe gateway pleacă cu o adresă din LAN-ul local sau din punctul final al tunelului, iar politica ce i se potrivește a fost scrisă exact pentru acel caz. Pachetul unui client ajunge pe interfața OpenVPN cu o adresă din pool-ul de clienți, care este un selector complet diferit.

De aceea defecțiunea arată ca o problemă de rutare când, de fapt, este o problemă de întindere a politicii. Accesibilitatea din gateway dovedește că partenerul este activ și că propunerile au fost negociate, și nu dovedește nimic despre dacă pool-ul este protejat.

Împingeți prefixul îndepărtat de care aplicația are nevoie cu adevărat

Luați perechea ilustrativă 10.8.0.0/24 pentru clienții conectați și 172.30.239.0/25 pentru rețeaua îndepărtată protejată. Ceea ce are nevoie un client este o rută către al doilea prefix, nu către LAN-ul gateway-ului și nu către o altă adresă de tunel. O rută împinsă în pool este ceea ce face clientul să predea acel trafic gateway-ului. Fără ea, pachetul nu ajunge niciodată la decizia de politică pe care o depanați.

Pe un server Community care acceptă rute împinse, directiva preia masca reală: push "route 172.30.239.0 255.255.255.128". Access Server configurează aceeași destinație prin setările de rețea privată sau de reguli de acces ale versiunii instalate, cu modul rutat sau tradus ales deliberat. Editarea lanțurilor de firewall generate în locul configurației proprietare este felul în care o instalare funcțională devine imposibil de reprodus.

După conectare, citiți tabela de rutare a clientului, nu intenția serverului. O rută care acoperă doar pool-ul înseamnă că împingerea nu a ajuns niciodată, iar o rută implicită prin tunel este mai largă decât această cerință și vă va surprinde mai târziu. Verificați masca și prefixul, fiindcă un /25 împins ca /24 trimite traficul adreselor vecine pe o cale care nu îl poate duce. Apoi confirmați că clientul a ales interfața tunelului pentru acea destinație.

Faceți selectorii să includă pool-ul de clienți

Pentru acces rutat care păstrează adresele clienților, politica IPsec trebuie să protejeze traficul dintre pool și prefixul îndepărtat. Selectorii scriși pentru LAN-ul propriu al gateway-ului admit pingul și aruncă cererea clientului, iar aceasta este exact asimetria care a început această investigație.

Inspectați politica negociată și propunerile configurate, de exemplu cu ipsec statusall pe strongSwan sau comanda de stare echivalentă pentru implementarea dvs. La IPsec bazat pe politici, ruta obișnuită poate indica o interfață fizică în timp ce traficul potrivit este încă criptat, așa că un dispozitiv de tunel lipsă nu dovedește nimic. Comparați perechile de selectori cu pool-ul și prefixul pe care le-ați notat.

NAT-ul de sursă generic de pe gateway poate rupe și el potrivirea. Dacă o regulă masquerade rescrie sursa clientului înainte de verificarea politicii, pachetul nu mai arată ca selectorul pe care l-ați scris. Acesta este un motiv pentru care o regulă masquerade largă este o remediere slabă pentru un al doilea VPN: schimbă ce politică se aplică și ce adresă înregistrează partea îndepărtată. Exceptați traficul pe care intenționați să îl rutați, sau traduceți-l deliberat și actualizați selectorii.

Alegeți rutarea sau traducerea cu intenție

Rutarea ține adresa clientului vizibilă pentru partea îndepărtată, deci jurnalele îndepărtate și regulile pe sursă rămân semnificative, și cere ca gateway-ul îndepărtat să cunoască calea de întoarcere către pool. Traducerea ascunde pool-ul în spatele unei singure adrese, ceea ce elimină problema rutei de întoarcere și distruge identitatea pe client.

Alegeți un singur design și scrieți-l, fiindcă cele două cer selectori diferiți și o ordine diferită a firewall-ului. Un masquerade aplicat pe jumătate ajunge între ele și nu satisface niciunul. Alegerea scrisă este și ceea ce îi permite următorului inginer să distingă un defect de o decizie deliberată.

Închideți bucla la forwardare și la răspuns

Gateway-ul trebuie să forwardeze protocolul și destinația pe care le aveți în minte, ceea ce înseamnă forwardare IP activă și un lanț de forwardare care permite perechea. Apoi partea îndepărtată trebuie să trimită răspunsurile înapoi pe calea IPsec, iar aceasta este o decizie de rutare pe gateway-ul lor, nu pe al dvs. Ambele jumătăți sunt configurație obișnuită, și ambele rămân ușor pe jumătate. Testați-le separat, ca o regulă de forwardare lipsă să nu fie confundată cu un tunel stricat.

Verificați cu o singură cerere reală de la client la aplicație, urmărind-o cum traversează interfața OpenVPN, decizia IPsec și hostul îndepărtat. Examinați răspunsul ca observație separată, fiindcă o cerere care sosește și un răspuns care nu se întoarce niciodată arată la fel din locul clientului. O cerere urmărită valorează mai mult decât oricâte pinguri din gateway.

Păstrați îngustă autorizarea destinației în timpul testării și confirmați că un client fără regulă nu poate ajunge la serviciu. O rută instalată plus o asociere stabilită nu este același lucru cu un acces acordat.