Zašto VPN koji radi ipak istekne na odgovoru
Zahtjev koji stigne do privatnog servera tek je pola razmjene. Njegov odgovor mora pronaći klijenta tunela kroz predviđeni gateway, rutu ili prijevod.
Zahtjev stigne, server ga zabilježi u dnevnik, a klijent i dalje prijavljuje istek vremena. Ta kombinacija znači da odgovor nije našao put natrag, i to je jedan od rijetkih kvarova koji možete potvrditi s oba kraja istovremeno. Provjere radite po redu i zaustavite se kada jedna od njih ne prođe.
Počnite od mjesta na koje je zahtjev stigao
Potvrdite da je paket stigao do usluge prije nego što pregledate bilo šta drugo. Zapis na strani servera, brojač konekcija ili dopušteno snimanje na udaljenom kraju odgovaraju na isto pitanje, a njihovo odsustvo vas vraća na tunel, a ne naprijed prema odgovoru. To je provjera koja razdvaja problem prosljeđivanja od problema povratnog puta.
Ako zahtjev nikada nije stigao, zaustavite se ovdje. Tunel, rutiranje do privatnog prefiksa ili pravilo pristupa su tema, a povratni put još nije relevantan. Zabilježite i izvornu adresu koju je server vidio. To je ili adresa iz bazena koju je klijent dobio ili prevedena adresa, a ta razlika određuje koja od kasnijih provjera vrijedi.
Odgovoru je potrebna ruta do bazena
Klijent za daljinski pristup obično dobija adresu iz bazena, a privatna mreža treba rutu natrag do tog bazena. Server čija podrazumijevana ruta pokazuje na njegov vlastiti gateway predaje paket tom gatewayu, koji nema pojma gdje se bazen nalazi, pa odgovor tu umire. Klijent vidi istek jer se ništa nije vratilo, što se ne razlikuje od zahtjeva koji nikada nije otišao.
Provjerite rutu koju server bira za adresu klijenta, a ne rutu koju koristi za vlastitu podmrežu. Ta dva pretraživanja mogu dati različite odgovore, a drugo je ono koje je ovdje važno. Prijevod je alternativni dizajn i mijenja ono što server vidi. Može pojednostaviti povratni put, a uklanja i izvornu adresu klijenta iz serverovih dnevnika, što utiče na svako pravilo ili izvještaj izgrađen na tom polju.
Uporedite snimanje na serveru sa snimanjem na gatewayu
Uporedite šta izlazi sa servera sa onim što stiže na gateway. Snimanje na izlaznom interfejsu servera i snimanje na tunelskom gatewayu odgovaraju na različite polovine pitanja, a razmak između njih lokalizuje gubitak.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Zahtjev koji generiše sam gateway slab je zamjena za test klijenta, jer potiče sa druge adrese i susreće druga pravila. Zato uspješan ping sa gatewaya i neuspješan zahtjev sa klijenta mogu biti istovremeno tačni.
Kada je na putu više rutera, provjerite svaki kojem treba ruta do bazena. Dizajn lokacija-lokacija često zahtijeva da udaljeni prefiks bude poznat na više od jednog uređaja, a sam gateway mora prosljeđivati između tunela i LAN-a; strongSwan bilješke o prosljeđivanju pokrivaju sysctl i firewall stranu toga.
Zabilježite bazen, prefiks i vlasnika
Četiri činjenice pripadaju u bilješku: bazen koji je klijent dobio, privatni prefiks koji mu je trebao, ruter odgovoran za odgovor i pravilo prijevoda ako postoji. S njima je kasnija promjena gatewaya poređenje, a ne istraga.
Zatim ponovite test sa običnim klijentom i stvarnim računom aplikacije. Proširenje privilegija aplikacije ne može popraviti povratni put paketa, a promjena računa tokom ove dijagnostike zbuniti će sljedeće poređenje. Ako se dizajn oslanja na prijevod, dokumentujte ga tamo gdje se čitaju serverovi dnevnici. Osoba koja u revizijskom tragu vidi nepoznatu izvornu adresu ne bi trebala ponovo otkrivati mapiranje iz tiketa.