Geroteerde VPN-kliënt bereik die bediener maar nie die LAN-gashere nie

Die tonnel kom op, die kliënt ping die VPN-bediener, en ’n gedeelde map op ’n masjien een sprong verder antwoord nooit. Niks in die kliëntkonfigurasie verduidelik dit nie, want die versoek het wel die kliënt verlaat en het wel aangekom. Wat gefaal het, is die terugreis, en die toestel wat gefaal het, is gewoonlik die LAN-poort eerder as die VPN-gasheer. Om die antwoordpakket na te spoor verduidelik die hele klas simptome.

Volg die Antwoord, Nie die Versoek Nie

Die VPN-bediener ontsleutel die kliëntpakket en stuur dit na die LAN deur met die kliëntadres steeds in die bronveld. Die bestemmingsgasheer antwoord daardie adres, en nou bepaal sy eie roetetabel alles. Sy verstekpoort weet niks van die tonnelpoel nie, so die antwoord vertrek na die internetverskaffer en word êrens langs daardie pad weggegooi.

Op die kliënt is die simptoom ’n stil tydsverloop: geen weiering, geen herstel, net niks. ’n Gedeelde map se blaaie hang, ’n ping meld geen antwoord nie, en die bediener se logboeke lyk gesond omdat die bediener sy werk gedoen het.

Plaas die Terugroete Waar die Gashere Kyk

Elke LAN-gasheer raadpleeg sy verstekpoort, so die poort is die een toestel wat moet weet waar die tonnelpoel woon. Voeg daar ’n statiese roete by en elke gasheer erf die korrekte pad sonder om aangeraak te word.

As die poort sy eie adres as ’n DHCP-opsie uitdeel, versprei die roete op daardie manier sodat nuwe masjiene dit outomaties optel. Anders leef die roete in een konfigurasielêer en verdwyn by die volgende herbou.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Waarom Bron-NAT Dit Lyk of Dit Herstel

Om die kliëntpoel agter die VPN-bedieneradres te masjineer verwyder die probleem deur die kliëntadres uit die pakket te verwyder. Antwoorde kom dan terug na die bediener, wat reeds weet hoe om die tonnel te bereik, en alles werk. Die koste is dat interne gashere nie meer kan sien wie die kliënt is nie, en elke verbinding lyk of dit van een masjien afkomstig is.

Daardie ruil is soms korrek, byvoorbeeld wanneer ’n verskaffer se toestel nie ’n statiese roete gegee kan word nie. Maak die reël nie wyer as die huidige poel nie, want ’n reël geskryf vir ’n /24 hou op pas die dag wanneer die poel hernommer word na ’n /16, en die eerste teken is ’n klomp nuwe kliënte wat verbind en niks bereik nie.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Die Wolkepad Het Drie Instellings Nodig

In ’n VPC kom dieselfde gaping in ’n ander vorm terug, want die subnet het glad geen roete vir die kliëntreeks nie. Die roetetabel het ’n inskrywing nodig vir die tonnelpoel wat op die instansie se netwerkkoppelvlak mik, en die koppelvlak moet bron- en bestemmingskontrole laat afskakel sodat die platform pakkette aanvaar waarvan die bron nie sy eie adres is nie. Sekuriteitsgroepe en netwerk-ACL's moet ook die poel in beide rigtings toelaat.

Elke weglating lewer ’n afsonderlike gedeeltelike faling. Slaan die roetetabelinskrywing oor en private instansies antwoord in ’n subnet wat die antwoord nie terug na die poel kan dra nie. Met kontrole steeds geaktiveer, laat die platform die antwoord val nadat die instansie dit reeds gestuur het. Sonder die sekuriteitsgroepreël kom die versoek self nooit aan nie, en die kliënt sien die tydsverloop een laag vroeër.

Voer die Kontroles in Hierdie Orde Uit

Bevestig deurstuur en die filterbeleid voordat jy roetering blameer, want ’n gasheer wat nie sal deurstuur nie, faal op dieselfde stil manier. Lees dan die effektiewe terugpadinstelling op die koppelvlak wat die tonnel dra, want ’n streng filter kan antwoorde weggooi wat uit ’n onverwagte rigting kom.

Eindig met ’n opname op die LAN-gasheer terwyl die kliënt dit ping. ’n Versoek wat aankom sonder ’n ooreenstemmende antwoord bewys die terugpad, en ’n versoek wat nooit aankom nie skuif die fout terug na die bediener of die tonnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Die bron- en bestemmingskontrole word gedokumenteer in die gids vir elastiese netwerkkoppelvlakke. Stel dit op die koppelvlak wat werklik die tonnelverkeer dra, nie op ’n onverwante adapter wat aan dieselfde instansie gekoppel is nie.