Serverul web dispare când clientul VPN se conectează

Un serviciu care dispare în momentul în care se conectează un client VPN nu este de obicei blocat, ci răspunde prin interfața greșită. Cererea ajunge pe placa de rețea fizică, daemonul scrie un răspuns, iar tabela de rutare predă acel răspuns tunelului, deoarece tunelul a preluat ruta implicită. Clientul distant nu vede niciodată un răspuns la o conexiune pe care a deschis-o, așa că așteaptă și apoi raportează un timp de expirare. Nicio regulă de firewall nu este implicată nicăieri în acea secvență.

Simptomul: cereri înăuntru, răspunsuri afară pe ușa greșită

Indiciul este o conexiune de intrare care eșuează în timp ce tot restul de pe gazdă funcționează. Un alt indiciu este o gazdă accesibilă din LAN, dar nu din internet, sau una care funcționează până când tunelul se reconectează și apoi se oprește. În fiecare caz direcția de dus se comporta bine, iar cea de întoarcere nu, ceea ce indică o asimetrie de rutare și nu o politică.

Confirmați observând unde merge răspunsul, nu observând cum sosește cererea.

Capturați simultan pe interfața fizică și pe dispozitivul tunelului. Dacă cererea apare pe interfața fizică, iar răspunsul pe tunel, diagnosticul este încheiat. Un răspuns care nu apare nicăieri înseamnă că serviciul nu a acceptat niciodată conexiunea, ceea ce este o investigație separată cu o cauză separată.

Două rute implicite și o singură decizie de rutare

Un client care instalează o rută implicită adaugă o a doua intrare cu o metrică mai bună decât cea a gateway-ului LAN. Unii clienți instalează în schimb două rute de jumătate de interval, care acoperă același spațiu mai specific și câștigă căutarea în același mod. Ambele tehnici lasă pachetele obișnuite de ieșire să aleagă interfața tunelului.

Această alegere se face doar după destinație. Nucleul nu întreabă de unde a venit un pachet decât dacă o regulă de politică îi poruncește. Așa că răspunsul către o adresă publică de client este predat tunelului, al cărui capăt îndepărtat primește un pachet cu o adresă sursă pe care nu o deține și îl aruncă sau îl trimite mai departe undeva inutil. În Linux, filtrarea strictă a căii inverse poate, de asemenea, să arunce cererea originală înainte ca serviciul dumneavoastră să o vadă, ceea ce din exterior arată identic. Ambele simptome provin din aceeași asociere lipsă între un flux de intrare și răspunsul lui.

Tunelul se comportă corect tot timpul. I s-a spus să transporte ruta implicită și face exact asta.

Reparați calea de întoarcere fără a rupe tunelul

Există trei forme durabile de reparare, iar alegerea depinde de cât din traficul propriu al gazdei trebuie să rămână în interiorul tunelului. Excluderea destinației sau portului serviciului este cea mai mică schimbare. Rutarea pe politică după sursă sau marcă este cea mai precisă. Traducerea sursei este cea mai grosolană și cea mai ușor de explicat doi ani mai târziu.

Alegeți după ce trebuie să facă gazda, nu după fragmentul pe care l-ați găsit primul.

Excluderea unei destinații se potrivește unui serviciu cu o adresă publică stabilă, iar legarea daemonului de adresa fizică în loc de toate adresele face acea excludere mai sigură. O regulă de politică ce alege un tabel după sursă ține conexiunile proprii ale gazdei în interiorul tunelului și, în același timp, trimite răspunsurile serviciului înapoi prin gateway-ul WAN. Mascarea răspunsurilor pe interfața WAN ajunge pe același drum cu prețul ascunderii adresei clientului din jurnalele serviciului. O modificare ad hoc a rutei implicite este un diagnostic, nu o configurare, pentru că clientul rescrie rutele la fiecare reconectare.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Când gazda rutează și pentru o LAN din spatele ei

Un salt mai departe, aceeași asimetrie revine cu mai multe piese mobile. Traficul ajunge la router din internet, este redirecționat către un dispozitiv intern, iar singura cale de întoarcere a acelui dispozitiv este tunelul, așa că răspunsul ajunge la clientul original de la adresa furnizorului însuși. Urmărirea conexiunilor întâlnește atunci un răspuns pentru un flux pe care nu i-a văzut începutul și îl aruncă. Clientul, între timp, nu vede absolut nimic.

Două modificări repară asta: traducerea destinației pentru ca conexiunea de intrare să ajungă la dispozitivul intern, și traducerea sursei pentru ca răspunsul acelui dispozitiv să pară că vine de la routerul însuși.

În firmware-ul routerului expresia obișnuită este o regulă de politică ce fixează redirecționarea porturilor pe partea WAN, în timp ce traficul propriu al routerului merge prin tunel. Fără traducerea sursei, acel răspuns este adresat clientului extern, iar dispozitivul intern pur și simplu nu are rută către el. Testați trei lucruri separat, pentru că eșuează din motive diferite: o conexiune care vine din exterior, una pe care gazda o inițiază singură și o căutare de nume.