VPN-kliënt op 'n LAN-bediener: waarom antwoorde die verkeerde kant uit vertrek

Die simptome volg een patroon: 'n gasheer werk, dan koppel dit aan 'n VPN as kliënt, en nou bereik LAN-kliënte dit terwyl sy antwoorde verdwyn. 'n Vangs op die gasheer wys die antwoorde verlaat deur die tonneltoestel eerder as die LAN-koppelvlak. Niks aan die tonnel is stukkend nie, en die oplossing is 'n roete, nie 'n herverbinding nie. Werk deur die vier kontroles hieronder in volgorde en stop by die eerste een wat faal.

Die antwoord is 'n nuwe pakket, nie 'n omkering nie

Dit help om die idee te laat vaar dat 'n antwoord terugreis langs die pad wat 'n versoek gevolg het. Roetering word per pakket, per rigting, op die sturende gasheer besluit. 'n Versoek wat van 10.64.0.23 binne die tonnel gekom het, skep geen terugpad nie; wanneer die gasheer antwoord, word daardie antwoord as 'n nuwe pakket teen die tabel getoets en verlaat deur watter roete ook al wen.

Dit is waarom 'n voltonnel-kliënt op 'n masjien wat ook 'n LAN bedien, so 'n verwarrende fout veroorsaak. Die kliënt installeer 'n verstekroete, of die twee half-verstekroetes wat sommige kliënte verkies, en die antwoord aan 'n LAN-kliënt pas nou by die tonnel. Dit gaan na die verskaffer, wat geen rede het om dit aan te stuur nie, en die LAN-kliënt sien 'n tydsverloop ondanks 'n gasheer wat op is en plaaslik antwoord. Die vangs maak dit duidelik, en die roetertabel verduidelik dit.

Hou twee subnetwerke in jou kop terwyl jy die res lees. Een is die VPN-adrespoel waaruit die afgeleë kliënte kom, in hierdie voorbeeld 10.64.0.0/24. Die ander is die LAN wat moet bly werk, 172.16.24.0/24 met sy roeteerder by 172.16.24.1. Die fout is dat verkeer tussen hulle deur die verstekroete besluit word.

Bewys dit met die vangs en die opsoek

Voordat jy iets verander, bevestig watter toestel die antwoord sal gebruik. 'n Opsoek is vinniger as 'n vangs en beantwoord presies die vraag wat die kern sal beantwoord wanneer die pakket gebou word.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lees die antwoord in twee dele. As dit dev tun0 noem, sal die gasheer die antwoord inkapsel en aan die verskaffer oorhandig, en die LAN-kliënt sal dit nooit sien nie. As dit dev eth0 noem maar die kliënt nog steeds 'n tydsverloop kry, is die roete reeds reg en word die pakket later laat vaar, wat 'n ander probleem met 'n ander oplossing is.

Die vangs in dieselfde stap besleg die twyfel wat 'n ping nie kan nie. 'n Eggo-antwoord wat by die LAN-kliënt aankom, bewys dat een of ander pad werk, nie watter koppelvlak dit gedra het nie, so doen die vangs op die gasheer self en kyk waar die rame vertrek. 'n Drukker op dieselfde subnetwerk bly antwoord, want sy skakelroete is meer spesifiek as die tonnel se verstek. 'n Aangestuurde poort faal presies soos enige ander vloei, want die tabel kies die koppelvlak en die verbinding doen dit nie.

Installeer die nouste roete wat die tonnel oortref

Voorvoegsellengte besluit, nie metriek nie, so 'n roete vir die kliëntpoel deur die LAN-roeteerder wen teen enige verstek wat die VPN-kliënt installeer. Geen metriek-chirurgie is nodig nie, en die verstek kan presies bly waar die kliënt dit gesit het.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Gebruik replace eerder as add, want 'n kliënt wat weer koppel, sal sy eie inskrywing geïnstalleer het en 'n tweede add faal met 'n bestaande-roete-fout wat soos 'n toestemmingsprobleem lees. Op 'n Windows-gasheer is die ekwivalent route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, waar -p die inskrywing oor herstarts behou, aangesien die kliënt die tabel kan herbou wanneer die tonnel weer opkom. Op 'n huidige Windows-gasheer is die ondersteunde ekwivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, met die ouer route-opdrag wat as 'n legacy-vorm behou bly.

Een detail besluit of dit korrek of bloot geloofwaardig is: die volgende hop moet die roeteerder wees wat werklik die pad terug na die kliënte besit. Om die roete na 'n adres te rig wat self deur die tonnel bereik word, skep 'n lus wat as ongereelde verlies eerder as 'n skoon fout opduik. Bevestig dat die volgende hop op die LAN-subnetwerk is voordat jy die reël uitvoer.

Behou die antwoord ná 'n herverbinding

'n Roete wat met die hand bygevoeg is, oorleef op die beste tot die volgende herverbinding. As die kliëntpoel dinamies is, pen dit in die bedienerkonfigurasie vas sodat die voorvoegsel wat jy geroteer het, die voorvoegsel bly wat kliënte ontvang; anders wys die inskrywing na 'n leë reeks en die simptoom keer weke later terug sonder 'n ooglopende oorsaak. Om die roete in die kliënt se eie up-script te skryf, is die ander betroubare opsie, want dit loop nadat die kliënt die tabel herskryf het.

'n Toestandsbewuste vuurmuur kan 'n korrekte roete steeds verydel. As die vangs nou wys die antwoord verlaat eth0 en die kliënt kry nog steeds 'n tydsverloop, kyk of die gasheer die pakket laat vaar voordat dit gestuur word: streng omgekeerde-padfiltering, net.ipv4.conf.all.rp_filter gestel op 1, verwerp pakkette waarvan die bron nie terug deur die koppelvlak geroteer sou word waar hulle aangekom het nie, wat presies die asimmetriese geval is wat jy pas geskep en dan reggemaak het. Conntrack-toestand vertel dieselfde verhaal vir aangestuurde poorte.

Die laaste kontrole is die een wat mense oorslaan: herhaal die opsoek nadat die tonnel af en weer op was. Vier waardes moet ooreenstem met wat jy neergeskryf het, die bestemming, die volgende hop, die toestel en die gekose bron. As enige van hulle geskuif het, het die kliënt die tabel herskryf en hoort die oplossing in sy hooks eerder as in 'n shell-geskiedenis.