Underbrutsen tagong mei AWS Client VPN: kontrolearje elk keppele subnet

In brûker makket ferbining, iepenet de ynterne app en krijt in antwurd; in kollega op itselde einpunt krijt in time-out fan in identike laptop op itselde Wi-Fi. Dat patroan is de hântekening fan in client VPN-einpunt mei mear as ien keppele subnet, wêrby’t de paden net gelykweardich binne. Ik rin dit fan de konsole nei bûten ta troch, om’t twa ljepblêden beslute oft de rest fan it ûndersyk de muoite wurdich is. Neat yn de kliïntkonfiguraasje ferklearret it.

Begjin by it einpunt en list de assosjaasjes op

Iepenje yn de VPC-konsole Client VPN endpoints, kies it einpunt en lês it ljepblêd Associations. Elke assosjaasje is in subnet yn in beskikberenssône, en in kliïnt lânet op dyjinge dy’t de tsjinst kiest as de ferbining boud wurdt. Notearje de subnet-ID’s en de rûtetabel dy’t elk eins brûkt, want dy twa listen binne de fergeliking dy’t jo op it punt steane te meitsjen.

As it einpunt mar ien assosjaasje toant, is dizze teory ferkeard en is de kliïnt de bettere fertochte.

Fergelykje de rûtetabel fan it einpunt mei elke assosjaasje

Iepenje it ljepblêd Route table op itselde einpunt. Elk bestimming-CIDR dêr hat in doel, en by in client VPN is it doel in assosjaasje ynstee fan in gateway. AWS easket in bestimmingsynfier foar elk keppele subnet, dus in rûte dy’t mar ien fan har rjochtet makket tagong ôfhinklik fan wêr’t de sesje lâne. Kontrolearje de bestimming dy’t jo eins wichtich fine, en dan de autorisaasjeregel dêrfan, want in rûte leveret it paad en in regel beslút wa’t it brûke mei.

As jo beide lagen tabulearje, is de flater dreech te missen.

Rige twa is de hiele bug yn de measte tickets. De rûte fan it einpunt is der, dus nimmen sjocht fierder, en it pakket stjert ien hop letter binnen de VPC.

Folgje elk subnet yn syn effektive rûtetabel

In subnet sûnder eksplisite rûtetabelassosjaasje erft de haadtabel fan de VPC. Lês de tabel dy’t eins jildt, net dy’t der goed út sjocht fan namme, en fergelykje bestimming en doel ynstee fan it label op de rige.

De AWS-gids foar underbrutsen tagong beskriuwt dit as rûte-dekking oer assosjaasjes, wat it juste model is. It einpunt bringt it pakket nei in subnet, en de tabel fan dat subnet moat noch witte wêr’t it applikaasjenetwurk wennet.

Reparearje de ûntbrekkende rige yn de tabel dy’t it besit. In hiele rûtetabel kopiearje fan in wurkjend subnet kopiearret ek ynternet-, apparaat- en isolaasjekeuzes dy’t nea foar dizze bedoeld wiene, en dy ruil is meastentiids slimmer as de steuring dêr’t jo mei begûn binne.

Kontrolearje autorisaasjeregeles, dan it paad werom

Autorisaasjeregeles binne per bestimming en per groep, en wurde apart fan rûtes beoardiele. In bestimming mei rûtes oeral mar sûnder regel foar de groep fan de brûker gedraacht har as in swart gat mei in rûtetabel dy’t sûn liket.

It paad werom fertsjinnet deselde oandacht. In peering-ferbining hat in rûte nedich yn de applikaasje-VPC dy’t werom wiist nei de CIDR fan de kliïnt, befeiligingsgroepregels dy’t it ferkear oan beide kanten tastean, en netwurk-ACL’s dy’t it net fuortsmite. Ienrjochting-berikberens, wêrby’t ping wurket en de TCP-hânskodding net, wiist meastentiids nei in ACL of in befeiligingsgroep ynstee fan de VPN.

De eigen befeiligingsgroepen fan it einpunt sitte op de elastyske netwurkynterfaces fan de assosjaasje, dus in regel dy’t de poarte fan de applikaasje fan de kliïnt-CIDR ôf tasteat moat oan de assosjaasje keppele wurde, net allinnich oan de ynstânsje.

Ferifiearje mei in werferbining, net mei ien gelokkich fersyk

Mei split tunnel wurde de rûtes fan it einpunt stjoerd as de ferbining ta stân komt, dus in feroare rûteset berikt nea in kliïnt dy’t ferbûn bliuwt. Ferbrek en ferbyn wer fia de stipe kliïnt, en befêstigje dan dat de nije rûtes op de masine oanwêzich binne.

Ta beslút, korrelearje it ferbiningslog mei it adres dat de kliïnt krige, en werhelje de test genôch kearen om mear as ien assosjaasje te reitsjen. Ien suksesfol fersyk nei in reparaasje bewiist dat ien paad wurket, en it ticket gie oer it oare.