Tunelul complet ți-a ucis sesiunea SSH: fixează ruta de retur

Porniți un client OpenVPN pe mașina la care lucrați prin SSH, iar la mijlocul unei comenzi sesiunea îngheață. Tunelul raportează conectat, gazda poate ajunge la internet prin el, iar tastele dumneavoastră încă ajung în timp ce nimic nu se întoarce. Ce s-a schimbat nu este tunelul: este calea de retur pentru pachetele adresate dumneavoastră, care acum corespunde noii rute implicite și intră într-un tunel pe care gateway-ul remote nu îl va folosi pentru a ajunge la biroul dumneavoastră.

Ce instalează de fapt redirect-gateway

În forma sa def1, redirect-gateway adaugă 0.0.0.0/1 și 128.0.0.0/1 în loc să suprascrie ruta implicită. Cele două jumătăți acoperă întregul spațiu de adrese, rămânând ambele prefixe mai lungi decât 0.0.0.0/0, astfel încât orice destinație fără o potrivire mai specifică intră acum în tunel. Acesta este mecanismul de reținut, pentru că fiecare remediere de mai jos funcționează instalând o potrivire mai specifică.

Adresa dumneavoastră administrativă este una dintre acele destinații.

Serverul VPN redirecționează traficul clienților săi către internet. Nu are nicio rută pentru adresa publică de la care vă conectați și niciun motiv să trateze acele pachete altfel decât ca trafic venit de la un client, așa că le elimină. Între timp, cererea pe care ați trimis-o a ajuns totuși la gazdă, motiv pentru care sesiunea pare activă doar pe o singură parte.

ip route show table main | head -n 20
ip route get 198.51.100.23

Găsiți adresa sursă și calea dinaintea tunelului

Pe server, listați conexiunea SSH stabilită și notați adresa peer de la care a venit. Acea adresă este cea pe care trebuie să o acopere ruta de retur și nu este întotdeauna ceea ce credeți: un jump host, un gateway NAT sau un translator de operator poate substitui o altă sursă.

Apoi găsiți gateway-ul fizic și interfața care transportau traficul înainte de pornirea tunelului. În aranjamentul def1, ruta implicită este încă prezentă sub semidefaulturi, așa că informația este disponibilă, deși citirea cu ochiul a unui tabel de rutare lung invită la greșeli.

Notați ambele valori și numele interfeței împreună, pentru că ruta pe care urmează să o adăugați are nevoie de toate trei. Dacă gazda folosea o regulă de rutare bazată pe politici pentru a-și alege uplink-ul, o rută simplă poate să nu fie consultată deloc, iar această posibilitate schimbă remedierea.

Fixați o rută de gazdă care depășește semidefaulturile

O rută /32 este mai lungă decât oricare semidefault, așa că răspunsurile către adresa dumneavoastră o folosesc în preferința tunelului. Următorul hop este gateway-ul dinaintea tunelului, iar dispozitivul este interfața fizică, ceea ce menține pachetul pe calea pe care o folosea înainte de existența tunelului.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verificați printr-o căutare, nu inspectând tabelul: răspunsul trebuie să numească eth0 și gateway-ul, niciodată tun0.

OpenVPN adaugă deja o rută de gazdă către adresa serverului VPN din același motiv, așa că tiparul este cunoscut, iar adresa administrativă este pur și simplu o altă excepție. Nu apelați la route-nopull pentru a remedia acest lucru, pentru că aruncă rutele împinse de care tunelul are nevoie, inclusiv rețeaua remote și opțiunile DNS.

Faceți-o să supraviețuiască unei reconectări

O rută adăugată manual dispare când clientul se reconectează și își reinstalează propriile rute, ceea ce transformă o remediere într-o întrerupere recurentă. Atașați comanda la ceva care rulează după instalarea rutelor.

Un script route-up sau hook-ul pre-up al managerului de rețea funcționează amândouă, iar verificarea de încredere este o reconectare urmată de aceeași căutare.

Pe Windows, echivalentul este o rută persistentă adăugată cu -p, care supraviețuiește repornirilor, dar trebuie să indice în continuare gateway-ul corect după o schimbare de rețea. Indiferent de platformă, scrieți motivul lângă rută: următorul administrator trebuie să știe că există pentru a proteja o sesiune de administrare, nu pentru că designul rețelei o cerea.

Când o rută fixată nu este încă suficientă

Filtrarea pe calea inversă poate elimina un pachet care sosește pe o interfață și pleacă pe alta, exact ceea ce creează o rută fixată. Verificați valoarea efectivă rp_filter înainte de a dezactiva ceva global și preferați să remediați asimetria în loc să opriți verificarea. Setarea pe interfață este cea care se aplică, iar modul loose deseori doar înregistrează asimetria în loc să elimine pachetul. Citiți-le pe amândouă înainte de a concluziona că filtrul este vinovat.

Gazdele cu rutare bazată pe politici au nevoie de o regulă, precum și de o rută, pentru că baza de reguli selectează tabelul înainte ca ruta din el să fie consultată. O rută din tabelul principal este invizibilă pentru un flux care se potrivește cu o regulă ce indică alt tabel. Citiți regulile înainte de a adăuga ceva în main. Dacă o regulă acoperă deja traficul de administrare, excepția aparține tabelului acelei reguli.

Țineți o consolă out-of-band deschisă în timp ce testați și reverificați dintr-o a doua autentificare înainte de a o deconecta pe cea pe care o folosiți. O rută care trimite propriul trafic de administrare în tunel întrerupe conexiunea prin care o reparați. Revenirea înseamnă apoi o consolă serială sau o pornire de recuperare, un schimb prost pentru a sări peste un pas de verificare.