Zašto klijenti Access Servera nisu dostupni iz LAN-a

Prijenosnik se spaja, tunel je podignut, a zahtjevi prema internom servisu vise pri spajanju. Na samom servisu zahtjev dolazi s adrese poput 10.90.0.25, odgovor odlazi prema zadanom gatewayu i ništa se ne vraća jer taj gateway nema pojma gdje se nalazi 10.90.0.25. S druge strane ista se greška vidi kao interni host koji ne može pingati spojenog klijenta. Oboje je jedan objekt koji nedostaje: povratna ruta prema skupu VPN klijenata, koju samo privatna mreža može dodati.

Pročitajte izvornu adresu koju servis vidi

To jedno polje odlučuje o svemu ostalom. Ako interni servis vidi adresu iz skupa, Access Server usmjerava umjesto da skriva klijentski promet i svaki se odgovor mora usmjeriti natrag u skup. Ako pak vidi vlastitu privatnu adresu poslužitelja, poslužitelj maskira i povratni put već radi, ali po cijeni gubitka svakog identiteta pojedinog klijenta u zapisnicima i pravilima pristupa servisa.

Usporedite oba kraja prije nego što bilo što promijenite. Na poslužitelju izlistajte tunel sučelja i njihove adrese; na klijentu potvrdite koje od tih adresa doista drži; na internom hostu pogledajte živu vezu.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Posljednja je naredba ona koja pada u pokvarenom slučaju: ili javlja da je prefiks tunela nedostupan ili, još gore, vraća vaš zadani gateway, i tako odgovori završe na internetu.

Ne pretpostavljajte samo jedan skup. Poslužitelj može imati dinamički raspon plus statičke dodjele po korisniku, a statička adresa može stajati posve izvan dinamičkog prefiksa. Ako usmjerite samo raspon kojeg se sjećate, korisnici s fiksnim adresama ostaju pokvareni, a svi ostali prijavljuju da je problem riješen.

Dodajte rutu ondje gdje se odlučuje o odgovoru

Ruta pripada gatewayu koji interni servis već koristi, a ne servisu, osim ako servis sam usmjerava svoj promet. Usmjerite je na dostupnu privatnu adresu Access Servera, koja je različita vrijednost od adrese tunela koju klijent drži.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

U oblaku ista izjava postaje zapis u tablici ruta čiji je cilj instanca ili mrežno sučelje na kojem poslužitelj radi, s isključenom provjerom izvora i odredišta na tom sučelju. Obratite pozornost na to što taj zapis ne čini: ruta nije odobrenje pristupa, pa sigurnosne grupe, mrežni ACL-i i host vatrozid i dalje moraju dopustiti promet.

Učinite je trajnom i držite veličine skupova iskrenima. Dva nepovezana skupa trebaju dvije rute, a skup koji naraste izvan konfiguriranog prefiksa tiho stvara klijente čiji odgovori nemaju kamo otići. Ako kontrolirate raspone skupova, odaberite sažetak koji možete usmjeriti jednom i ostaviti.

Prosljeđivanje i filtri moraju se slagati s rutom

Usmjeravanje je samo pola puta. Poslužitelju se mora dopustiti prosljeđivanje između tunela i privatnog sučelja, što na Linuxu znači net.ipv4.ip_forward plus lanac prosljeđivanja koji dopušta par sučelja, a na očvrslom hostu obično izričito pravilo za svaki smjer.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Filtriranje sa stanjem objašnjava simptom koji ljude vodi na pogrešan put. Odgovor unutar uspostavljenog toka ne treba novo ulazno pravilo, pa veza koja visi nakon SYN-ACK-a nije blokirana pravilom accept koje nedostaje; ona se odbacuje ili pogrešno usmjerava. Zadržite tu razliku jer razdvaja promjenu usmjeravanja od promjene vatrozida.

Asimetrični povratni putevi tiša su verzija istog problema. Ako do skupa vode dvije rute i odgovor krene onom koja izlazi na drugom sučelju od onoga na kojem je zahtjev stigao, strogo filtriranje povratnog puta ga odbacuje i tok pada samo za neke klijente.

Usmjereno ili maskirano: odlučite namjerno

Usmjereni način čuva adresu skupa klijenta na servisu, što omogućuje zapisivanje i pravila po klijentu, a zauzvrat svaka interna mreža koja mora odgovoriti klijentu treba rutu skupa. Maskirani način uklanja taj zahtjev jer se odgovori vraćaju na poslužitelj, ali servis više ne razlikuje jednog klijenta od drugoga i ne može ništa pokrenuti prema određenom klijentu.

Promjena tog ponašanja na živom poslužitelju ruši postojeće sesije, pa prvo testirajte s jednim klijentom i jednim tokom. Ako je prebacivanje pravi odgovor, to je odluka o konfiguraciji na poslužitelju, a ne nešto što se zaobilazi dodavanjem ruta koje će postati nepotrebne.

Podmreža iza klijenta zaseban je zadatak

Dosezanje uređaja na vlastitom LAN-u prijenosnika nije isto što i dosezanje adrese tunela prijenosnika. Zahtijeva da klijent djeluje kao gateway podmreže: deklarirana mreža na strani klijenta, omogućeno prosljeđivanje u klijentovu operacijskom sustavu i ruta na tom LAN-u natrag prema klijentu. Dodavanje rute privatne mreže za domaći raspon prijenosnika to ne čini i stvara sukobe kada dva korisnika imaju isti domaći raspon.

Smjer je također pitanje politike. Dopuštenje klijentu da otvori vezu prema internom servisu ne daje automatski internom hostu dopuštenje da otvori vezu prema tom klijentu. Provjerite politiku pristupa poslužitelja i host vatrozid klijenta prije nego zaključite da je put pokvaren.

Provjerite jednim tokom i jednim snimkom

Dokažite put jednom vezom umjesto općim testom dostupnosti. Promatrajte isti tok na oba kraja: zahtjev koji dolazi na servis i odgovor koji ga napušta.

tcpdump -ni any host 10.90.0.25 and port 443

Prije popravka snimka pokazuje odgovor kako odlazi prema gatewayu koji ga neće usmjeriti. Nakon popravka odgovor odlazi prema poslužitelju i tok se dovršava. Zatim potvrdite rutu koju bi gateway upotrijebio za adresu drugog klijenta, da se nepokriveni skup pokaže sada, a ne za tjedan dana.

Završite s četiri provjere koje ovo zatvaraju: izvorna adresa na servisu odgovara načinu koji ste namjeravali, gateway ima rutu do svakog skupa u uporabi, prosljeđivanje i filtri dopuštaju oba smjera i jedan stvarni tok prolazi od početka do kraja. Česta pitanja o usmjeravanju Access Servera navodi isto načelo za instalirano izdanje, čije se podržano konfiguracijsko sučelje može razlikovati od starijih vodiča.