AWS Client VPN verbind, maar geen internettoegang: kontrole van roetes

Jy is aan die AWS Client VPN-eindpunt verbind, die privaat subnet antwoord, en elke openbare bladsy keer nog steeds uit. Daardie kombinasie vernou die probleem na een van drie objekte aan die bestuurde kant: die roete wat die kliënt installeer, die eindpunt se roete saam met sy magtigingsreël, of die geassosieerde subnet se volgende sprong. Ek kontroleer hulle in daardie volgorde, want elke fout lyk anders vanaf die kliënt. Hierdie prosedure dek die VPC-geassosieerde bestuurde eindpunt, nie ’n OpenVPN-bediener op ’n EC2-instansie nie, en ook nie ’n Cloud WAN- of Transit Gateway-aanhegting nie.

Begin met wat die kliënt werklik roeteer

’n Verbinde toestand bewys die TLS-sessie en die kliënt se CIDR-toewysing, niks meer nie. Vra die bedryfstelsel waar ’n openbare adres sou gaan terwyl die tonnel op is. Op Linux moet ip route get 1.1.1.1 die tonnelkoppelvlak noem; op macOS wys netstat -rn -f inet | head -5 die verstekinskrywing; op Windows druk Find-NetRoute -RemoteIPAddress 1.1.1.1 die gekose koppelvlak en volgende sprong.

Lees dan die split-tonnel-vlag, want dit bepaal of die eindpunt se gepubliseerde roetes die enigste bestemmings is wat die kliënt in die tonnel stuur:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

As SplitTunnel waar is, gebruik ’n openbare bestemming die tonnel net wanneer die eindpunt ’n roete publiseer wat dit dek, so ’n ontbrekende 0.0.0.0/0 laat daardie verkeer op die plaaslike koppelvlak. As dit onwaar is, vang die kliënt die verkeer, maar die eindpunt moet dit steeds roeteer en magtig; anders gaan pakkette die tonnel in en stop daar. Herverbind die kliënt nadat jy enige van die twee instellings verander het, want roetes en DNS-bediener word by verbindingstyd afgelewer en ’n lopende kliënt kan sy ou stel behou.

Lees die eindpuntroete en die magtigingsreël afsonderlik

Dit is twee objekte, en om een te skep skep nie die ander nie. Lys die eindpuntroetes en soek ’n verstek waarvan die teiken ’n geassosieerde subnet is:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Elke roete het presies een teikensubnet, dus drie assosiasies het elk ’n ooreenstemmende verstekroete nodig. AWS dokumenteer hierdie dekkingvereiste, en die praktiese simptoom van ’n gaping is ’n gebruiker wat van een subnet af werk en by ’n ander vasval, wat soos ’n onreëlmatige fout eerder as ’n ontbrekende roete lyk. Die amptelike Client VPN-scenario-dokumentasie beskryf die openbare-subnet-reëling waaraan hierdie roetes behoort.

Magtiging is die tweede objek. Wanneer geen reël die openbare bestemming dek nie, dra die tonnel die pakket en die diens verwerp dit, so privaat hulpbronne bly werk terwyl die internet dit nie doen nie:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

’n Reël vir die VPC CIDR sê niks oor 0.0.0.0/0. Om die ontbrekende stukke vir ’n volledige tonnel by te voeg, beteken een roete per geassosieerde subnet plus ’n magtigingsreël wat jy later kan nagaan:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all verleen die bestemming aan elke kliënt van die eindpunt, so hou dit net terwyl die tonnel bedoel is om volledig te wees; ’n reël wat aan ’n gidsgroep gebind is, is verkieslik wanneer jy groepe het om aan te bind.

Volg die pakket uit die geassosieerde subnet

Die eindpuntroete besluit dat AWS die pakket aan daardie subnet gee. Dit besluit nie die volgende sprong daarna nie, wat in die subnet se eie VPC-roetetabel leef:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

’n Bruikbare verstek wys na ’n internetpoort vir ’n openbare subnet, of na ’n NAT-poort vir ’n private een, en ’n toestand van blackhole beteken die teiken is uitgevee en die pad sterf nou stil. Dit is ander tabelle as die eindpunt se roetelys, en om een reg te maak maak nie die ander reg nie.

Twee filters sit op hierdie sprong. Die sekuriteitsgroep wat op die teikennetwerkassosiasie toegepas is, moet uitgaande verkeer na die openbare bestemming toelaat, en enige toepaslike netwerk-ACL moet die versoek en die terugkeerverkeer op efemere poorte toelaat. ’n Beperkende assosiasie-sekuriteitsgroep is ’n algemene rede waarom privaat toegang werk terwyl openbare toegang dit nie doen nie.

Kies die eerste laag op grond van die simptoom eerder as om al drie gelyktydig te verander:

Skei DNS-foute van ’n dooie roete

Naamresolusie faal anders as aanstuur, en volledige tonnel maak die verskil belangrik omdat die gestuurde resolver nou deur die tonnel bereik word. As die eindpunt VPC DNS-bediener spesifiseer, het hulle adresse roetedekking en magtiging nodig soos enige ander bestemming. Vra die resolver direk om te sien watter fout jy het: dig +short example.com @10.0.0.2, of nslookup example.com 10.0.0.2 op Windows.

Wanneer ’n numeriese URL antwoord en ’n genoemde een nie, stop om die verstekroete te redigeer en werk aan DNS. ’n Versoek na ’n IP-adres bewys niks oor ’n genoemde virtuele gasheer en sy sertifikaat nie, so hou een genoemde toets in die finale kontrole.

Tydsberekening help. ’n TCP-verbinding wat binne ’n paar sekondes geen antwoord kry nie, wys na roetering of ’n filter, terwyl ’n versoek wat binne naamsoektog hang na die resolver wys. Om die verstekroete te verander terwyl die resolver onbereikbaar is, maak gewoonlik een fout twee.

Draai skoon terug en verifieer dan die uitgangspad

Beide objekte was byvoegend, so terugdraai is uitvee eerder as herstel:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Herverbind en bevestig dan watter pad die verkeer verlaat. Vergelyk die waargenome openbare adres met die NAT-poort se elastiese IP-adres, of met die internetpoort wat jy wou gebruik, en kyk of ’n privaat hulpbron nog in dieselfde sessie antwoord.

Sluit af met ’n kort lys, en behandel die laaste item as deel van die verandering eerder as as dokumentasie:

• Een 0.0.0.0/0 eindpuntroete vir elke geassosieerde subnet.
• ’n Magtigingsreël wat 0.0.0.0/0 dek vir die kliënte wat jy bedoel om te bedien.
• ’n VPC-verstekroete wat nie blackhole is nie, op elke geassosieerde subnet.
• Uitgang van die assosiasie-sekuriteitsgroep, plus ACL-terugkeerverkeer.
• Resolveradresse geroteer en gemagtig, geverifieer met ’n genoemde versoek.
• ’n Opgetekende terugdraai vir die roete en die reël.

Een omvangsnota: dit is ’n IPv4-pad. ’n Dual-stack-kliënt behou watter IPv6-verbinding hy reeds het, so ’n IPv6-verstekroete is ’n aparte besluit met sy eie magtiging eerder as ’n newe-effek van hierdie een.