Breekt een VPN-client op je webserver de antwoorden?

De site laadt vanaf een laptop op hetzelfde netwerk en loopt vanaf elke andere plek vast, en de host draait ook een VPN-client voor zijn eigen uitgaande verkeer. Die combinatie levert een specifieke storing op: de inkomende verbinding komt aan, het antwoord vertrekt via het verkeerde pad, en de client buiten ziet nooit een antwoord. Beide helften verschijnen in dezelfde pakketopname, dus de volgorde van gebeurtenissen is het deel dat de moeite van het lezen waard is.

Een op bron gebaseerde routeringsregel lost vaak het symptoom op. Hij zondert ook meestal meer verkeer uit dan de site die hem heeft veroorzaakt, en dat is het deel dat je moet begrijpen voordat je de regel opslaat.

Het symptoom: lokaal antwoordt hij wel, van buiten niet

Binnen het netwerk hoeft het antwoord de tunnel niet te passeren, dus de pagina laadt en de dienst lijkt gezond. Van buiten bereikt het verzoek de host en wordt het antwoord de VPN in gerouteerd, waar de verre kant geen reden heeft om het te accepteren. De browser ziet een time-out in plaats van een weigering, en dat is het kenmerk van een eenrichtingspad en niet van een gesloten poort.

Bevestig de vorm voordat je de routering wijzigt: de listener is actief, het lokale verzoek slaagt en het externe verzoek levert helemaal geen antwoord op. Die drie waarnemingen wijzen samen naar het retourpad en niet naar de configuratie van de webserver. Zo'n schone asymmetrie is nuttiger dan welke logregel dan ook, omdat hij de listener uitsluit voordat je één foutmelding leest.

Houd een onafhankelijk beheerpad open terwijl je werkt. Een regel die je eigen SSH-sessie breekt, maakt van een reparatie van tien minuten een fysiek bezoek.

Wat een bronselector werkelijk matcht

In Linux-beleidsroutering matcht een regel als from 192.168.50.2 pakketten waarvan de bron dat adres is. Hij codeert niet dat het pakket een gesprek voortzet dat via de thuisrouter binnenkwam, en hij weet niet welk proces het heeft gemaakt. Het adres in dat voorbeeld is illustratief; vervang het door het adres dat je host werkelijk gebruikt. Behandel de regel als een uitspraak over adressen en niets meer.

Als de gekozen tabel een gewone standaardroute levert, kan elk pakket met die bron dezelfde uitzondering nemen. Een andere dienst die aan hetzelfde adres is gebonden, erft hem, en een toepassing die zich bewust aan dat adres bindt, erft hem ook. De referentie voor beleidsregels noemt bron, bestemming, protocol, poort, markering en prioriteit als afzonderlijke selectors, wat eraan herinnert dat de bron alleen de grofste is die beschikbaar is.

De prioriteit bepaalt de uitkomst. Opzoekingen verlopen op volgorde en de eerste tabel die een resultaat oplevert kan de zoektocht beëindigen, dus een regel die te vroeg staat kan een specifiekere route verbergen die een latere tabel zou hebben geleverd. Lees de hele geordende lijst in plaats van de ene regel die je hebt toegevoegd. Een regel die nooit matcht kost niets, terwijl een die te vroeg matcht stilzwijgend alles erachter verandert.

Controleer het retourpad en het verkeer dat je niet bedoelde

Lees de regels en de tabellen en vraag de kernel daarna welke route een bepaald paar van bron en bestemming zou nemen. Testen vanaf de host zelf is niet hetzelfde als testen van buiten, dus doe beide.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Accepteer dan een nieuwe externe verbinding en, apart, een verzoek dat nog steeds via de VPN naar buiten moet. Als het tweede nu rechtstreeks naar buiten gaat, is de uitzondering breder dan het probleem dat je oploste, en de test die ertoe doet, is degene die je niet van plan was te wijzigen.

Een controle van het openbare adres in een browser meldt alleen de verzoeken die die browser heeft gedaan. Hij zegt niets over de antwoorden van de webserver, over de bronkeuze van een andere lokale toepassing of over wat er met beheerverkeer gebeurt na de volgende VPN-herverbinding.

Bepaal hoe smal de uitzondering kan zijn

Twee ontwerpen zijn verdedigbaar en ze moeten bewust worden gekozen. Als de host bestaat om deze dienst te publiceren en zijn uitgaande verkeer onbelangrijk is, is een toegewijd lokaal adres met een beleid alleen voor WAN een redelijke regeling, mits je de volledige reikwijdte accepteert. Als alleen bepaalde inkomende verbindingen in aanmerking moeten komen, is de adreskeuze te grof en hoort er een verbindingsbewust ontwerp voor.

Noteer het contract waarop je vertrouwt: de openbare mapping, het hostadres waaraan het verzoek wordt afgeleverd en het pad dat het antwoord hoort te nemen. Een inkomende dienst die via een VPN-aanbieder wordt gepubliceerd is een ander contract dan een die via een thuisrouter wordt gepubliceerd, en een uitzondering die uit één voorbeeld is gekopieerd is vaak verkeerd voor het andere.

Bewaar het beleid in de component die de routering bezit in plaats van een commando in een opstartbestand te plakken. Regelvolgorde, opruimen na een netwerkwijziging en herhalen na een herstart moeten allemaal overleven, en een ongetest opstartbestand faalt meestal op het moment dat je niet kijkt. Sluit af met het acceptatieresultaat dat je kunt verdedigen: één gepubliceerde site hersteld en één niet-verwante stroom ongewijzigd.