Kial klientoj de Access Server ne estas atingeblaj el la LAN

La tekkomputilo konektiĝas, la tunelo funkcias, kaj petoj al interna servo pendas ĉe konekto. Ĉe la servo mem la peto alvenas de adreso kiel 10.90.0.25, la respondo foriras al la implicita kluzo, kaj nenio revenas, ĉar tiu kluzo tute ne scias, kie loĝas 10.90.0.25. De la alia flanko la sama misfunkcio aspektas kiel interna gastiganto, kiu ne povas pingsendi al konektita kliento. Ambaŭ estas unu mankanta objekto: returna vojo al la klienta baseno de VPN, kiun nur la privata reto povas aldoni.

Legu la fontan adreson, kiun la servo vidas

Tiu sola kampo decidas ĉion alian. Se la interna servo vidas la basenan adreson, Access Server enkursigas anstataŭ kaŝi klientan trafikon, kaj ĉiu respondo devas esti enkursigita reen al la baseno. Se ĝi anstataŭe vidas la propran privatan adreson de la servilo, la servilo maskas kaj la responda vojo jam funkcias, je la kosto perdi ĉian identecon de unuopa kliento en la protokoloj kaj aliraj reguloj de la servo.

Komparu ambaŭ finojn antaŭ ol ŝanĝi ion ajn. Ĉe la servilo, listigu la tunelajn interfacojn kaj iliajn adresojn; ĉe la kliento, konfirmu kiun el tiuj adresoj ĝi vere tenas; ĉe la interna gastiganto, rigardu aktivan konekton.

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

La lasta komando estas tiu, kiu fiaskas en la rompita kazo: ĝi aŭ raportas la tunelan prefikson kiel neatingeblan aŭ, pli malbone, redonas vian implicitan kluzon, kaj tiel respondoj finiĝas en la interreto.

Ne supozu nur unu basenon. Servilo povas havi dinamikan amplekson plus statikajn asignojn por ĉiu uzanto, kaj la statika adreso povas kuŝi tute ekster la dinamika prefikso. Se vi enkursigas nur la amplekson, kiun vi memoras, uzantoj kun fiksaj adresoj restas rompitaj kaj ĉiuj aliaj raportas la problemon kiel solvitan.

Aldonu la vojon tie, kie oni decidas la respondon

La vojo apartenas al la kluzo, kiun la interna servo jam uzas, ne al la servo, krom se ĝi enkursigas sian propran trafikon. Direktu ĝin al la atingebla privata adreso de Access Server, kiu estas malsama valoro ol la tunela adreso de kliento.

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

En nuba reto la sama aserto fariĝas ero de enkursiga tabelo, kies celo estas la instanco aŭ reta interfaco, sur kiu funkcias la servilo, kun fonta kaj cela kontrolo malŝaltitaj sur tiu interfaco. Rimarku, kion tiu ero ne faras: vojo ne estas alira permeso, do sekurecaj grupoj, retaj ACL-oj kaj la gastiganta fajroŝirmilo ankoraŭ devas permesi la trafikon.

Faru ĝin daŭra kaj tenu la basenajn grandojn honestaj. Du neapudaj basenoj bezonas du vojojn, kaj baseno, kiu kreskas preter sia agordita prefikso, silente produktas klientojn, kies respondoj havas nenie irejon. Se vi regas la basenajn gamojn, elektu resumon, kiun vi povas enkursigi unufoje kaj postlasi.

Plusendo kaj filtriloj devas kongrui kun la vojo

Enkursigo estas nur duono de la vojo. La servilo devas rajtaji plusendi inter la tunelo kaj la privata interfaco, kio en Linux signifas net.ipv4.ip_forward plus plusenda ĉeno, kiu permesas la paron da interfacoj, kaj sur hardita gastiganto kutime eksplicitan regulon por ĉiu direkto.

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

Stata filtrado klarigas simptomon, kiu sendas homojn sur la malĝustan vojon. Respondo ene de establita fluo ne bezonas novan envenan regulon, do konekto, kiu pendas post la SYN-ACK, ne estas blokata de mankanta akcepta regulo; ĝi estas forĵetata aŭ mise enkursigata. Konservu tiun distingon, ĉar ĝi apartigas enkursigan ŝanĝon de fajroŝirmila ŝanĝon.

Malsimetriaj returnaj vojoj estas la pli kvieta versio de la sama problemo. Se du vojoj atingas la basenon kaj la respondo prenas tiun, kiu eliras per alia interfaco ol tiu, per kiu alvenis la peto, strikta returna voja filtrado forĵetas ĝin kaj la fluo fiaskas nur por iuj klientoj.

Enkursigita aŭ maskigita: elektu konscie

La enkursigita reĝimo konservas la basenan adreson de la kliento ĉe la servo, kio ebligas protokoladon kaj politikon por unuopa kliento, kaj kontraŭe ĉiu interna reto, kiu devas respondi al kliento, bezonas la basenan vojon. La maska reĝimo forigas tiun postulon, ĉar respondoj revenas al la servilo, sed la servo ne plu povas distingi unu klienton de alia kaj ne povas iniciati ion al difinita kliento.

Ŝanĝi tiun konduton sur aktiva servilo faligas ekzistantajn sesiojn, do testu unue per unu kliento kaj unu fluo. Se la ŝalto estas la ĝusta respondo, ĝi estas agorda decido ĉe la servilo, ne io, kion oni evitu aldonante vojojn, kiuj fariĝos nenecesaj.

Subreto malantaŭ la kliento estas aparta tasko

Atingi aparaton en la propra LAN de la tekkomputilo ne samas kiel atingi la tunelan adreson de la tekkomputilo. Ĝi postulas, ke la kliento agu kiel subreta kluzo: deklarita klienta reto, plusendo ŝaltita en la operaciumo de la kliento, kaj vojo en tiu LAN reen al la kliento. Aldoni privatan retan vojon por la hejma gamo de la tekkomputilo tion ne faras, kaj ĝi kreas konfliktojn, kiam du uzantoj havas la saman hejman gamon.

La direkto ankaŭ estas politika demando. Permeso al kliento malfermi konekton al interna servo ne aŭtomate permesas al interna gastiganto malfermi konekton al tiu kliento. Kontrolu la aliran politikon de la servilo kaj la gastigantan fajroŝirmilon de la kliento antaŭ ol konkludi, ke la vojo estas rompita.

Kontrolu per unu fluo kaj unu kaptaĵo

Pruvu la vojon per unu konekto anstataŭ per ĝenerala atingebleca testo. Observu la saman fluon ĉe ambaŭ finoj: la peto alvenanta al la servo kaj la respondo forlasanta ĝin.

tcpdump -ni any host 10.90.0.25 and port 443

Antaŭ la korekto la kaptaĵo montras la respondon forirantan al kluzo, kiu ne enkursigos ĝin. Post la korekto la respondo foriras al la servilo kaj la fluo kompletiĝas. Poste konfirmu la vojon, kiun la kluzo uzus por dua klienta adreso, por ke baseno, kiun vi ne kovris, aperu nun anstataŭ post semajno.

Finu per la kvar kontroloj, kiuj fermas la aferon: la fonta adreso ĉe la servo kongruas kun la reĝimo, kiun vi intencis, la kluzo havas vojon al ĉiu uzata baseno, plusendo kaj filtriloj permesas ambaŭ direktojn, kaj unu reala fluo kompletiĝas de komenco ĝis fino. Oftaj demandoj pri enkursigado de Access Server esprimas la saman principon por la instalita eldono, kies subtenata agorda interfaco povas malsami de pli malnovaj gvidiloj.