Varför Access Server-klienter inte nås från LAN

Den bärbara datorn ansluter, tunneln är uppe och förfrågningar till en intern tjänst hänger vid anslutningen. På själva tjänsten kommer förfrågan från en adress som 10.90.0.25, svaret lämnar mot standardgatewayen och ingenting kommer tillbaka, eftersom den gatewayen inte har en aning om var 10.90.0.25 finns. Från andra änden ser samma fel ut som en intern värd som inte kan pinga en ansluten klient. Båda är ett enda saknat objekt: en returväg till VPN-klientpoolen, som bara det privata nätet kan lägga till.

Läs källadressen som tjänsten ser

Det enda fältet avgör allt annat. Om den interna tjänsten ser pooladressen routar Access Server i stället för att dölja klienttrafik, och varje svar måste routas tillbaka till poolen. Om den i stället ser serverns egen privata adress maskerar servern och returvägen fungerar redan, men till priset av att varje identitet per klient försvinner i tjänstens loggar och åtkomstregler.

Jämför båda ändarna innan du ändrar något. På servern, lista tunnelgränssnitten och deras adresser; på klienten, bekräfta vilken av dessa adresser den faktiskt har; på den interna värden, titta på en levande anslutning.

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

Det sista kommandot är det som misslyckas i det trasiga fallet: det rapporterar antingen tunnelprefixet som onåbart eller, värre, returnerar din standardgateway, och det är så svar hamnar på internet.

Anta inte att det bara finns en pool. En server kan ha ett dynamiskt intervall plus statiska mappningar per användare, och den statiska adressen kan ligga helt utanför det dynamiska prefixet. Om du bara routar intervallet du minns förblir användare med fasta adresser trasiga och alla andra rapporterar problemet som löst.

Lägg till vägen där svaret avgörs

Vägen hör till gatewayen som den interna tjänsten redan använder, inte till tjänsten, om den inte routar sin egen trafik. Peka den mot Access Servers nåbara privata adress, som är ett annat värde än tunneladressen en klient har.

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

I ett molnnätverk blir samma påstående en post i routingtabellen vars mål är instansen eller nätverksgränssnittet som kör servern, med käll- och destinationskontroll avstängd på det gränssnittet. Lägg märke till vad den posten inte gör: en väg är inte ett åtkomstbeviljande, så säkerhetsgrupper, nätverks-ACL:er och värdens brandvägg måste fortfarande tillåta trafiken.

Gör den beständig och håll poolstorlekarna ärliga. Två icke sammanhängande pooler kräver två vägar, och en pool som växer förbi sitt konfigurerade prefix producerar tyst klienter vars svar inte har någonstans att ta vägen. Om du kontrollerar poolintervallen, välj en sammanfattning du kan routa en gång och sedan lämna.

Vidarebefordran och filter måste stämma med vägen

Routing är bara halva vägen. Servern måste få tillåtelse att vidarebefordra mellan tunneln och det privata gränssnittet, vilket på Linux betyder net.ipv4.ip_forward plus en vidarebefordringskedja som tillåter gränssnittsparet, och på en härdad värd oftast en explicit regel för varje riktning.

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

Stateful filtrering förklarar ett symptom som leder folk in på fel väg. Ett svar inom ett etablerat flöde behöver ingen ny inkommande regel, så en anslutning som hänger efter SYN-ACK blockeras inte av en saknad accept-regel; den tappas eller felroutas. Behåll den skillnaden, eftersom den skiljer en routingändring från en brandväggsändring.

Asymmetriska returvägar är den tystare versionen av samma problem. Om två vägar når poolen och svaret tar den som lämnar via ett annat gränssnitt än det förfrågan kom in på, tappar strikt reverse-path-filtrering det och flödet misslyckas bara för vissa klienter.

Rutat eller maskerat: välj medvetet

Rutat läge bevarar klientens pooladress hos tjänsten, vilket gör loggning och policy per klient möjlig, och i gengäld behöver varje internt nätverk som ska svara en klient poolvägen. Maskerat läge tar bort det kravet eftersom svaren går tillbaka till servern, men tjänsten kan inte längre skilja en klient från en annan och kan inte initiera något mot en viss klient.

Att ändra det beteendet på en live-server bryter befintliga sessioner, så testa först med en klient och ett flöde. Om bytet är rätt svar är det ett konfigurationsbeslut på servern, inte något man kringgår genom att lägga till vägar som blir onödiga.

Ett subnät bakom klienten är en egen uppgift

Nå en enhet på den bärbara datorns eget LAN är inte samma sak som att nå den bärbara datorns tunneladress. Det kräver att klienten fungerar som en subnätgateway: ett deklarerat nätverk på klientsidan, vidarebefordran aktiverad i klientens operativsystem och en väg på det LAN:et tillbaka mot klienten. Att lägga till en privatnätsväg för den bärbara datorns hemintervall gör inte detta, och det skapar konflikter när två användare har samma hemintervall.

Riktningen är också en policyfråga. Tillstånd för en klient att öppna en anslutning till en intern tjänst ger inte automatiskt en intern värd rätt att öppna en anslutning till den klienten. Kontrollera serverns åtkomstpolicy och klientens värdbrandvägg innan du drar slutsatsen att vägen är trasig.

Verifiera med ett flöde och en avlyssning

Bevisa vägen med en enda anslutning i stället för ett allmänt nåbarhetstest. Följ samma flöde i båda ändarna: förfrågan som anländer till tjänsten och svaret som lämnar den.

tcpdump -ni any host 10.90.0.25 and port 443

Före rättelsen visar fångsten svaret lämna mot en gateway som inte kommer att routa det. Efter rättelsen lämnar svaret mot servern och flödet fullbordas. Bekräfta sedan vägen som gatewayen skulle använda för en andra klientadress, så att en pool du inte täckt upptäcks nu och inte om en vecka.

Avsluta med de fyra kontrollerna som stänger frågan: källadressen hos tjänsten stämmer med det avsedda läget, gatewayen har en väg till varje pool som används, vidarebefordran och filter tillåter båda riktningarna, och ett verkligt flöde går igenom från början till slut. Vanliga frågor om Access Server-routing anger samma princip för den installerade versionen, vars stödda konfigurationsgränssnitt kan skilja sig från äldre guider.