Webbediener verdwyn wanneer die VPN-kliënt aansluit

’n Diens wat verdwyn op die oomblik dat ’n VPN-kliënt aansluit, word gewoonlik nie geblokkeer nie, dit antwoord deur die verkeerde koppelvlak. Die versoek kom op die fisiese netwerkkaart aan, die daemon skryf ’n antwoord, en die roetertabel gee daardie antwoord aan die tonnel, aangesien die tonnel die verstekroete oorgeneem het. Die afgeleë kliënt sien nooit ’n antwoord op ’n verbinding wat dit oopgemaak het nie, so dit wag en rapporteer dan ’n tydsverloop. Geen vuurmuurreël is enige plek in daardie reeks betrokke nie.

Die Simptoom: Versoeke In, Antwoorde Deur die Verkeerde Deur Uit

Die aanduiding is ’n inkomende verbinding wat misluk terwyl alles anders op die gasheer werk. Nog ’n aanduiding is ’n gasheer wat vanaf die LAN bereikbaar is maar nie vanaf die internet nie, of een wat werk totdat die tonnel weer aansluit en dan stop. In elke geval het die voorwaartse rigting gewerk en die terugrigting nie, wat op roeteringsasimetrie eerder as op beleid dui.

Bevestig dit deur te kyk waar die antwoord heen gaan, nie deur te kyk hoe die versoek aankom nie.

Vang gelyktydig op die fisiese koppelvlak en op die tonneltoestel. As die versoek op die fisiese koppelvlak verskyn en die antwoord op die tonnel, is die diagnose klaar. ’n Antwoord wat nêrens verskyn nie, beteken die diens het nooit die verbinding aanvaar nie, wat ’n aparte ondersoek met ’n aparte oorsaak is.

Twee Verstekroetes en Een Roeteringsbesluit

’n Kliënt wat ’n verstekroete installeer, voeg ’n tweede inskrywing by met ’n beter metriek as die LAN-gateway. Sommige kliënte installeer eerder twee halfreeksroetes, wat dieselfde ruimte meer spesifiek dek en die opsoek op dieselfde manier wen. Enige van die twee tegnieke laat gewone uitwaartse pakkette die tonnelkoppelvlak kies.

Daardie keuse word net deur die bestemming gemaak. Die kernel vra nie waar ’n pakket vandaan kom nie, tensy ’n beleidsreël dit sê. So word die antwoord na ’n openbare kliëntadres aan die tonnel gegee, wie se verre punt ’n pakket met ’n bronadres ontvang wat hy nie besit nie en dit weggooi of êrens nutteloos heen stuur. Op Linux kan streng tru-roete-filtering ook die oorspronklike versoek laat val voordat jou diens dit ooit sien, wat van buite identies lyk. Albei simptome kom van dieselfde ontbrekende assosiasie tussen ’n inkomende stroom en sy antwoord.

Die tonnel tree deurgaans korrek op. Daar is aan hom gesê om die verstekroete te dra en dit doen hy presies.

Herstel die Terugroete Sonder om die Tonnel te Breek

Daar bestaan drie blywende vorms van herstel, en die keuse hang daarvan af hoeveel van die gasheer se eie verkeer binne die tonnel moet bly. Die uitsluiting van die diens se bestemming of poort is die kleinste verandering. Beleidsroetering volgens bron of merk is die mees presiese. Bronvertaling is die bluntste en die maklikste om oor twee jaar te verduidelik.

Kies volgens wat die gasheer moet doen, nie volgens watter brokkie jy eerste gevind het nie.

Die uitsluiting van ’n bestemming pas by ’n diens met ’n stabiele openbare adres, en om die daemon aan die fisiese adres te bind eerder as aan elke adres maak daardie uitsluiting veiliger. ’n Beleidsreël wat ’n tabel volgens bron kies, hou die gasheer se eie verbindings binne die tonnel terwyl dit diensantwoorde deur die WAN-gateway terugstuur. Om antwoorde na die WAN-koppelvlak te masjineer bereik dieselfde pad ten koste daarvan dat die kliënt se adres uit die dienslogboeke verberg word. ’n Ad-hoc verandering van die verstekroete is ’n diagnostiek en nie ’n konfigurasie nie, want die kliënt herskryf roetes by elke heraansluiting.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Wanneer die Gasheer ook vir ’n LAN agter hom roeteer

Een hop verder uit kom dieselfde asimetrie terug met meer bewegende dele. Verkeer bereik die roeteerder vanaf die internet, word na ’n interne toestel deurgestuur, en daardie toestel se enigste pad terug is die tonnel, so die antwoord bereik die oorspronklike kliënt vanaf die verskaffer se eie adres. Verbindingsopsporing kry dan ’n antwoord vir ’n stroom wat hy nooit sien begin het nie, en gooi dit weg. Die kliënt sien intussen heeltemal niks.

Twee veranderinge herstel dit: bestemmingsvertaling sodat die inkomende verbinding die interne toestel bereik, en bronvertaling sodat daardie toestel se antwoord lyk of dit van die roeteerder self kom.

Op roeteerderfirmware is die gewone uitdrukking ’n beleidsreël wat die poortaanstuur aan die WAN-kant vaspen terwyl die roeteerder se eie verkeer op die tonnel ry. Sonder bronvertaling is daardie antwoord aan die eksterne kliënt gerig en die interne toestel het eenvoudig geen roete daarheen nie. Toets drie dinge afsonderlik, want hulle misluk om verskillende redes: ’n verbinding wat van buite kom, een wat die gasheer self begin, en ’n naamopsoek.