Zakaj klienti Access Serverja niso dosegljivi iz omrežja LAN

Prenosnik se poveže, tunel je vzpostavljen, zahteve do notranje storitve pa ob povezovanju obvisijo. V sami storitvi zahteva prispe z naslova, kot je 10.90.0.25, odgovor odide proti privzetim vratom in nič se ne vrne, ker ta vrata ne vedo, kje je 10.90.0.25. Z druge strani je ista napaka videti kot notranji gostitelj, ki ne more pingati povezanega klienta. Oboje je en manjkajoč objekt: povratna pot do bazena klientov VPN, ki jo lahko doda le zasebno omrežje.

Preberite naslov vira, ki ga vidi storitev

To eno polje odloči vse ostalo. Če notranja storitev vidi naslov bazena, Access Server usmerja, namesto da bi skrival promet klientov, in vsak odgovor mora biti usmerjen nazaj v bazen. Če pa vidi lastni zasebni naslov strežnika, strežnik maskira in povratna pot že deluje, a za ceno izgube vsake identitete posameznega klienta v dnevnikih in pravilih dostopa storitve.

Primerjajte oba konca, preden karkoli spremenite. Na strežniku naštejte vmesnike tunela in njihove naslove; na klientu potrdite, kateri od teh naslovov dejansko ima; na notranjem gostitelju poglejte aktivno povezavo.

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

Zadnji ukaz je tisti, ki v pokvarjenem primeru odpove: bodisi sporoči, da je predpona tunela nedosegljiva, bodisi, kar je slabše, vrne vaša privzeta vrata, in tako odgovori končajo na internetu.

Ne predpostavljajte samo enega bazena. Strežnik ima lahko dinamičen razpon in statične dodelitve za posamezne uporabnike, statični naslov pa je lahko povsem zunaj dinamične predpone. Če usmerjate le razpon, ki se ga spomnite, uporabniki s fiksnimi naslovi ostanejo pokvarjeni, vsi drugi pa poročajo, da je težava rešena.

Dodajte pot tam, kjer se odloči odgovor

Pot pripada vratom, ki jih notranja storitev že uporablja, ne storitvi, razen če ta sama usmerja svoj promet. Usmerite jo na dosegljiv zasebni naslov Access Serverja, ki se razlikuje od naslova tunela, ki ga ima klient.

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

V oblaku ista izjava postane vnos v usmerjevalni tabeli, katerega cilj je instanca ali omrežni vmesnik, na katerem teče strežnik, s prepovedjo preverjanja vira in cilja na tem vmesniku. Bodite pozorni, česa ta vnos ne naredi: pot ni podelitev dostopa, zato morajo varnostne skupine, omrežni ACL in požarni zid gostitelja promet še vedno dovoliti.

Naredite jo trajno in ohranite velikosti bazenov poštene. Dva nesosednja bazena potrebujeta dve poti, bazen, ki zraste čez konfigurirano predpono, pa tiho ustvari kliente, katerih odgovori nimajo kam iti. Če nadzirate obsege bazenov, izberite povzetek, ki ga lahko usmerite enkrat in ga pustite pri miru.

Posredovanje in filtri se morajo ujemati s potjo

Usmerjanje je le polovica poti. Strežniku mora biti dovoljeno posredovanje med tunelom in zasebnim vmesnikom, kar v Linuxu pomeni net.ipv4.ip_forward plus verigo posredovanja, ki dovoljuje par vmesnikov, na utrjenem gostitelju pa običajno ločeno izrecno pravilo za vsako smer.

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

Filtriranje s stanjem pojasni simptom, ki ljudi popelje na napačno pot. Odgovor znotraj vzpostavljenega toka ne potrebuje novega vhodnega pravila, zato povezava, ki obvisi po SYN-ACK, ni blokirana zaradi manjkajočega pravila accept; zavržena je ali napačno usmerjena. Ohranite to razliko, ker ločuje spremembo usmerjanja od spremembe požarnega zidu.

Asimetrične povratne poti so tišja različica iste težave. Če do bazena prideta dve poti in odgovor izbere tisto, ki odide skozi drug vmesnik od tistega, po katerem je prišla zahteva, strogo filtriranje povratne poti to zavrže in tok spodleti le pri nekaterih klientih.

Usmerjeno ali maskirano: izberite zavestno

Usmerjeni način ohrani naslov bazena klienta v storitvi, kar omogoča beleženje in politiko za posameznega klienta, v zameno pa vsako notranje omrežje, ki mora klientu odgovoriti, potrebuje pot bazena. Maskirani način odpravi to zahtevo, ker se odgovori vračajo na strežnik, a storitev ne more več ločiti enega klienta od drugega in ne more ničesar začeti proti določenemu klientu.

Sprememba tega vedenja na delujočem strežniku prekine obstoječe seje, zato najprej preizkusite z enim klientom in enim tokom. Če je preklop pravi odgovor, je to konfiguracijska odločitev na strežniku, ne pa nekaj, kar bi obšli z dodajanjem poti, ki bodo postale nepotrebne.

Podomrežje za klientom je ločena naloga

Doseganje naprave v lastnem omrežju LAN prenosnika ni isto kot doseganje naslova tunela prenosnika. Zahteva, da klient deluje kot prehod podomrežja: deklarirano omrežje na strani klienta, omogočeno posredovanje v operacijskem sistemu klienta in pot v tem omrežju LAN nazaj proti klientu. Dodajanje poti zasebnega omrežja za domači obseg prenosnika tega ne naredi in ustvari konflikte, ko imata dva uporabnika isti domači obseg.

Tudi smer je vprašanje politike. Dovoljenje, da klient odpre povezavo do notranje storitve, ne dovoli samodejno notranjemu gostitelju, da odpre povezavo do tega klienta. Preverite politiko dostopa strežnika in požarni zid gostitelja klienta, preden sklepate, da je pot pokvarjena.

Preverite z enim tokom in enim posnetkom

Dokažite pot z eno samo povezavo namesto s splošnim preizkusom dosegljivosti. Opazujte isti tok na obeh koncih: zahtevo, ki prispe v storitev, in odgovor, ki jo zapusti.

tcpdump -ni any host 10.90.0.25 and port 443

Pred popravkom posnetek pokaže odgovor, ki odhaja proti vratom, ki ga ne bodo usmerila. Po popravku odgovor odide proti strežniku in tok se dokonča. Nato potrdite pot, ki bi jo vrata uporabila za drugi naslov klienta, da se nepokriti bazen pokaže zdaj in ne čez teden dni.

Zaključite s štirimi preverjanji: naslov vira v storitvi ustreza želenemu načinu, vrata imajo pot do vsakega bazena v uporabi, posredovanje in filtri dovoljujejo obe smeri, in en resničen tok se zaključi od začetka do konca. Pogosta vprašanja o usmerjanju Access Serverja navaja isto načelo za nameščeno izdajo, katere podprti konfiguracijski vmesnik se lahko razlikuje od starejših vodnikov.