Pse klientët e Access Server nuk arrihen nga LAN-i

Laptopi lidhet, tuneli është aktiv dhe kërkesat drejt një shërbimi të brendshëm mbeten të varura në lidhje. Në vetë shërbimin kërkesa mbërrin nga një adresë si 10.90.0.25, përgjigja del drejt portës së parazgjedhur dhe asgjë nuk kthehet, sepse ajo portë nuk e ka idenë se ku ndodhet 10.90.0.25. Nga ana tjetër e njëjta defekt duket si një host i brendshëm që nuk mund të bëjë ping një klienti të lidhur. Të dyja janë një objekt i vetëm që mungon: një rrugë kthimi drejt grupit të klientëve VPN, të cilën vetëm rrjeti privat mund ta shtojë.

Lexoni adresën e burimit që sheh shërbimi

Ai fushë e vetme vendos gjithçka tjetër. Nëse shërbimi i brendshëm sheh adresën e grupit, Access Server rrugëton në vend që të fshehë trafikun e klientëve, dhe çdo përgjigje duhet të rrugëtohet përsëri drejt grupit. Nëse në vend të kësaj sheh adresën private të vetë serverit, serveri bën masquerade dhe rruga e kthimit funksionon tashmë, por me koston e humbjes së çdo identiteti për klient në regjistrat dhe rregullat e aksesit të shërbimit.

Krahasoni të dy skajet përpara se të ndryshoni çdo gjë. Në server, listoni ndërfaqet e tunelit dhe adresat e tyre; në klient, konfirmoni cilën prej këtyre adresave mban në të vërtetë; në hostin e brendshëm, shikoni një lidhje aktive.

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

Komanda e fundit është ajo që dështon në rastin e prishur: ose raporton prefiksin e tunelit si të paarritshëm ose, më keq, kthen portën tuaj të parazgjedhur, dhe kështu përgjigjet përfundojnë në internet.

Mos supozoni vetëm një grup. Një server mund të ketë një interval dinamik plus mapime statike për çdo përdorues, dhe adresa statike mund të qëndrojë plotësisht jashtë prefiksit dinamik. Nëse rrugëtoni vetëm intervalin që mbani mend, përdoruesit me adresa fikse mbeten të prishur dhe të gjithë të tjerët raportojnë se problemi është zgjidhur.

Shtoni rrugën atje ku vendoset përgjigja

Rruga i takon portës që shërbimi i brendshëm tashmë përdor, jo shërbimit, përveç nëse ai rrugëton vetë trafikun e vet. Drejtojeni drejt adresës private të arritshme të Access Server, e cila është një vlerë e ndryshme nga adresa e tunelit që mban një klient.

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

Në një rrjet cloud e njëjta deklaratë bëhet një zë i tabelës së rrugëve, objektivi i të cilit është instanca ose ndërfaqja e rrjetit ku ekzekutohet serveri, me kontrollin e burimit dhe destinacionit të çaktivizuar në atë ndërfaqe. Vini re çfarë nuk bën ai zë: një rrugë nuk është dhënie aksesi, ndaj grupet e sigurisë, ACL-të e rrjetit dhe firewalls i hostit duhet ende ta lejojnë trafikun.

Bëjeni të vazhdueshme dhe mbajini madhësitë e grupeve të ndershme. Dy grupe jo të njëpasnjëshme kërkojnë dy rrugë, dhe një grup që rritet përtej prefiksit të konfiguruar prodhon në heshtje klientë, përgjigjet e të cilëve nuk kanë ku të shkojnë. Nëse i kontrolloni intervalet e grupeve, zgjidhni një përmbledhje që mund ta rrugëtoni një herë dhe ta lini.

Përcjellja dhe filtrat duhet të pajtohen me rrugën

Rrugëtimi është vetëm gjysma e rrugës. Serverit duhet t'i lejohet të përcjellë mes tunelit dhe ndërfaqes private, që në Linux do të thotë net.ipv4.ip_forward plus një zinxhir përcjelljeje që lejon çiftin e ndërfaqeve, dhe në një host të forcëzuar zakonisht një rregull i qartë për çdo drejtim.

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

Filtrimi me gjendje shpjegon një simptomë që i çon njerëzit në rrugën e gabuar. Një përgjigje brenda një fluksi të vendosur nuk ka nevojë për një rregull të re hyrëse, ndaj një lidhje që var pas SYN-ACK nuk po bllokohet nga një rregull pranimi që mungon; po hidhet ose po rrugëtohet gabimisht. Mbajeni këtë dallim, sepse ndan një ndryshim rrugëtimi nga një ndryshim firewalls.

Rrugët e kthimit asimetrike janë versioni më i qetë i të njëjtit problem. Nëse dy rrugë arrijnë grupin dhe përgjigja merr atë që del nga një ndërfaqe tjetër nga ajo ku mbërrinte kërkesa, filtri i rreptë i rrugës së kthimit e hedh atë dhe fluksi dështon vetëm për disa klientë.

I rrugëtuar apo i maskuar: zgjidhni me qëllim

Mënyra e rrugëtuar ruan adresën e grupit të klientit te shërbimi, gjë që bën të mundshme regjistrimin dhe politikën për çdo klient, dhe në këmbim çdo rrjet i brendshëm që duhet t'i përgjigjet një klienti ka nevojë për rrugën e grupit. Mënyra e maskuar e heq atë kërkesë sepse përgjigjet kthehen te serveri, por shërbimi nuk mund të dallojë më një klient nga tjetri dhe nuk mund të nisë asgjë drejt një klienti të caktuar.

Ndryshimi i këtij sjelljeje në një server aktiv i ndërpret sesionet ekzistuese, ndaj provoni fillimisht me një klient dhe një fluks. Nëse ndryshimi është përgjigja e duhur, është një vendim konfigurimi në server, jo diçka që anashkalohet duke shtuar rrugë që do të bëhen të panevojshme.

Një nënrrjet pas klientit është detyrë më vete

Arritja e një pajisjeje në LAN-in e vetë laptopit nuk është e njëjta gjë si arritja e adresës së tunelit të laptopit. Kërkon që klienti të veprojë si portë nënrrjeti: një rrjet i deklaruar nga ana e klientit, përcjellja e aktivizuar në sistemin operativ të klientit, dhe një rrugë në atë LAN përsëri drejt klientit. Shtimi i një rrugë rrjeti privat për intervalin e shtëpisë së laptopit nuk e bën këtë, dhe krijon konflikte kur dy përdorues kanë të njëjtin interval shtëpie.

Drejtimi është gjithashtu një çështje politike. Leja që një klient të hapë një lidhje drejt një shërbimi të brendshëm nuk i lejon automatikisht një hosti të brendshëm të hapë një lidhje drejt atij klienti. Kontrolloni politikën e aksesit të serverit dhe firewalls e hostit të klientit përpara se të përfundoni se rruga është e prishur.

Verifikoni me një fluks dhe një kapje

Provojeni rrugën me një lidhje të vetme në vend të një testi të përgjithshëm arritshmërie. Vëzhgoni të njëjtin fluks në të dy skajet: kërkesën që mbërrin te shërbimi dhe përgjigjen që e lë.

tcpdump -ni any host 10.90.0.25 and port 443

Përpara rregullimit kapja tregon përgjigjen duke dalë drejt një porte që nuk do ta rrugëtojë. Pas rregullimit përgjigja del drejt serverit dhe fluksi përfundon. Më pas konfirmoni rrugën që porta do të përdorte për një adresë të dytë klienti, që një grup i pambuluar të shfaqet tani dhe jo pas një jave.

Përfundoni me katër kontrollet që e mbyllin çështjen: adresa e burimit te shërbimi përputhet me mënyrën e synuar, porta ka rrugë drejt çdo grupi në përdorim, përcjellja dhe filtrat lejojnë të dy drejtimet, dhe një fluks real përfundon nga fillimi në fund. Pyetje të shpeshta rreth rrugëtimit të Access Server shpreh të njëjtin parim për versionin e instaluar, ndërfaqja e konfigurimit e të cilit mund të ndryshojë nga udhëzuesit e vjetër.